写在前面：如有问题，以你为准，
目前24年应届生，各位大佬轻喷，部分资料与图片来自网络
内容较长，页面右上角目录方便跳转
Pod 理论基础
概述
Pod 可以认为是容器的封装，一个Pod中可以存在一个或者多个容器
kubernetes 启动时候，各个核心unschedulable组件也是以Pod方式运行的
Pod 结构
自主式pod：kubernetes直接创建出来的Pod，这种pod删除后就没有了，也不会重建
控制器创建的pod：kubernetes通过控制器创建的pod，这种pod删除了之后还会自动重建
资源类型为 deployment（pod控制器中的一种）Pod 控制器 解析
端口与pod IP
访问pod里面容器其实就是 pod IP:container port
此时将多个pod的同端口映射到主机上来，就有端口冲突问题，使用deployment控制创建的pod，有多个pod副本，如果都映射到主机上就会导致冲突，就要使用services来进行类似于haproxy / lvs 的操作
Pod 生命周期
Pod创建过程
- ① 用户通过kubectl或其他的api客户端提交需要创建的Pod信息给API Server。
- ② API Server开始生成Pod对象的信息，并将信息存入etcd，然后返回确认信息至客户端。
- ③ API Server开始反映etcd中的Pod对象的变化，其它组件使用watch机制（etcd提供）来跟踪检查API Server上的变动。
- ④ Scheduler发现有新的Pod对象要创建，开始为Pod分配主机并将结果信息更新至API Server。
- ⑤ Node节点上的kubelet发现有Pod调度过来，尝试调度Docker启动容器，并将结果回送至API Server。
- ⑥ API Server将接收到的Pod状态信息存入到etcd中
Pod终止过程
- ① 用户向API Server发送删除Pod对象的命令。
- ② API Server中的Pod对象信息会随着时间的推移而更新，在宽限期内（默认30s），Pod被视为dead。
- ③ 将Pod标记为terminating状态。
- ④ kubelet在监控到Pod对象转为terminating状态的同时启动Pod关闭过程。
- ⑤ 端点控制器监控到Pod对象的关闭行为时将其从所有匹配到此端点的service资源的端点列表中移除(不让外部访问)。
- ⑥ 如果当前Pod对象定义了preStop钩子处理器，则在其标记为terminating后会以同步的方式启动执行。
- ⑦ Pod对象中的容器进程收到停止信号。
- ⑧ 宽限期结束后，如果Pod中还存在运行的进程，那么Pod对象会收到立即终止的信号。
- ⑨ kubectl请求API Server将此Pod资源的宽限期设置为0从而完成删除操作，此时Pod对于用户已经不可用了
Pod初始化容器
- 初始化容器是在Pod的主容器启动之前要运行的容器，主要是做一些主容器的前置工作，它具有两大特征：
- 初始化容器有很多的应用场景，下面列出的是最常见的几个：
- 接下来做一个案例，模拟下面这个需求：
- 具体示例yaml查看下面的Pod yaml 编写中的 spec.initContainers
ifconfig ens160:1 192.168.100.103 netmask 255.255.255.0 up
^C[root@master k8s]# kubectl get pod -n study -w
NAME READY STATUS RESTARTS AGE
pod-initcontainer 0/1 Init:0/2 0 2m22s
pod-initcontainer 0/1 Init:1/2 0 3m2s
pod-initcontainer 0/1 Init:1/2 0 3m3s
ifconfig ens160:2 192.168.100.104 netmask 255.255.255.0 up
^C[root@master k8s]# kubectl get pod -n study -w
NAME READY STATUS RESTARTS AGE
pod-initcontainer 0/1 Init:0/2 0 2m22s
pod-initcontainer 0/1 Init:1/2 0 3m2s
pod-initcontainer 0/1 Init:1/2 0 3m3s
pod-initcontainer 0/1 PodInitializing 0 3m38s
pod-initcontainer 1/1 Running 0 3m39s钩子函数
钩子函数能够感知自身生命周期中的事件，并在相应的时刻到来时运行用户指定的程序代码
具体示例和整yaml示例查看，Pod yaml 编写中 spec.containers 钩子函数
活性探测
- 容器探测用于检测容器中的应用实例是否正常工作，是保障业务可用性的一种传统机制。如果经过探测，实例的状态不符合预期，那么kubernetes就会把该问题实例“摘除”，不承担业务流量。kubernetes提供了两种探针来实现容器探测，分别是：
livenessProbe：存活性探测，决定是否重启容器。
yaml示例查看，Pod yaml 编写中 spec.containers 活性探测
上面这三个跟钩子函数基本一样，就是上一级字段改成了livenessProbe或readinessProbe
kubectl explain pod.spec.containers.livenessProbeFIELDS:
exec
tcpSocket
httpGet
initialDelaySeconds # 容器启动后等待多少秒执行第一次探测
timeoutSeconds # 探测超时时间。默认1秒，最小1秒 注意：新版本可能会忽略这个参数
periodSeconds # 执行探测的频率。默认是10秒，最小1秒
failureThreshold # 连续探测失败多少次才被认定为失败。默认是3。最小值是1
successThreshold # 连续探测成功多少次才被认定为成功。默认是1重启策略
- 在容器探测中，一旦容器探测出现了问题，kubernetes就会对容器所在的Pod进行重启，其实这是由Pod的重启策略决定的，Pod的重启策略有3种，分别如下：
- 重启策略适用于Pod对象中的所有容器，首次需要重启的容器，将在其需要的时候立即进行重启，随后再次重启的操作将由kubelet延迟一段时间后进行，且反复的重启操作的延迟时长以此为10s、20s、40s、80s、160s和300s，300s是最大的延迟时长。
示例查看，Pod yaml 编辑中 spec.restartPolicy
临时容器（ EphemeralContainer ）
临时容器是一种特殊的容器，该容器可以在现有的 Pod 中临时运行，以便完成我们发起的操作，比如故障排查。我们应该使用临时容器来检查服务，而不是用临时容器来构建应用程序
现在安全要求越来越高，所以很多容器时不能启动sh，然后只能用临时容器来进行调试pod
Pod 是 Kubernetes 集群进行管理的最小单元，由于 Pod 是一次性且可以替换的，因此 Pod 一旦被创建，就无法将容器加入到Pod 中。而且，我们通常使用 Deployment 来删除并替换Pod。但是，有的时候我们需要检查现有 Pod 的状态，比如对难以复现的故障进行排查。在这些场景中，可以在现有 Pod 中运行临时容器来检查其状态并运行任意命令
临时容器与其他容器的不同之处在于，它们缺少对资源或执行的保证，并且永远不会自动重启， 因此不适用于构建应用程序。 临时容器使用与常规容器相同的 ContainerSpec 节来描述，但许多字段是不兼容和不允许的。
- 有关允许字段的完整列表，请参见 EphemeralContainer 参考文档。
临时容器是使用 API 中的一种特殊的 ephemeralcontainers 处理器进行创建的， 而不是直接添加到 pod.spec 段，因此无法使用 kubectl edit 来添加一个临时容器。
与常规容器一样，将临时容器添加到 Pod 后，将不能更改或删除临时容器
示例
debug用于起一个临时容器，来对容器进行调试，当退出的时候会自动删除这个临时容器
kubectl run ephemeral-demo --image=registry.aliyuncs.com/google_containers/pause:3.9 --restart=Never
kubectl exec -it ephemeral-demo -- sh
# OCI runtime exec failed: exec failed: container_linux.go:346: starting container process caused "exec: \"sh\": executable file not found in $PATH": unknown
kubectl debug -it ephemeral-demo --image=busybox:1.28 --target=ephemeral-demo
Defaulting debug container name to debugger-6wv4n.
If you don't see a command prompt, try pressing enter.
/ # ps -a
PID USER TIME COMMAND
1 65535 0:00 /pause #这是要调试容器中的进程
20 root 0:00 sh
27 root 0:00 ps -a
[root@master DashBoard]# kubectl run ephemeral-demo --image=nginx:1.17.1
pod/ephemeral-demo created
[root@master DashBoard]# kubectl get pod
NAME READY STATUS RESTARTS AGE
ephemeral-demo 1/1 Running 0 5s
[root@master DashBoard]# kubectl debug -it ephemeral-demo --image=busybox:1.30 --target=ephemeral-demo
Targeting container "ephemeral-demo". If you don't see processes from this container it may be because the container runtime doesn't support this feature.
Defaulting debug container name to debugger-ctdld.
If you don't see a command prompt, try pressing enter.
/ # ps -a
PID USER TIME COMMAND
1 root 0:00 nginx: master process nginx -g daemon off;
7 101 0:00 nginx: worker process
8 root 0:00 sh
14 root 0:00 ps -a复制新Pod来调试Pod
kubectl run myapp --image=busybox:1.30 --restart=Never -- sleep 1d
kubectl debug myapp -it --image=ubuntu --share-processes --copy-to=myapp-debugPod 调度
- 在默认情况下，一个Pod在哪个Node节点上运行，是由Scheduler组件采用相应的算法计算出来的，这个过程是不受人工控制的。但是在实际使用中，这并不满足需求，因为很多情况下，我们想控制某些Pod到达某些节点上，那么应该怎么做？这就要求了解kubernetes对Pod的调度规则，kubernetes提供了四大类调度方式。
定向调度
定向调度，指的是利用在Pod上声明的nodeName或nodeSelector，以此将Pod调度到期望的Node节点上。
注意，这里的调度是强制的，这就意味着即使要调度的目标Node不存在，也会向上面进行调度，只不过Pod运行失败而已（会先显示ping然后不显示然后资源）。
nodeName：直接指定调度到哪个node上（示例看 yaml编写中spec.nodeName）
nodeSelector：通过selector标签选择器来调度（示例看 yaml编写中spec.selector）
- 用于将Pod调度到添加了指定标签的Node节点上，它是通过kubernetes的label-selector机制实现的，会由Scheduler使用MatchNodeSelector调度策略进行label匹配，找出目标node，然后将Pod调度到目标节点，该匹配规则是强制约束
亲和性调度
- 虽然定向调度的两种方式，使用起来非常方便，但是也有一定的问题，那就是如果没有满足条件的Node，那么Pod将不会被运行，即使在集群中还有可用的Node列表也不行，这就限制了它的使用场景。
- 基于上面的问题，kubernetes还提供了一种亲和性调度（Affinity）。它在nodeSelector的基础之上进行了扩展，可以通过配置的形式，实现优先选择满足条件的Node进行调度，如果没有，也可以调度到不满足条件的节点上，使得调度更加灵活。
- Affinity主要分为三类：
关于亲和性和反亲和性的使用场景的说明：
亲和性：如果两个应用频繁交互，那么就有必要利用亲和性让两个应用尽可能的靠近，这样可以较少因网络通信而带来的性能损耗。
反亲和性：当应用采用多副本部署的时候，那么就有必要利用反亲和性让各个应用实例打散分布在各个Node上，这样可以提高服务的高可用性
污点和容忍
污点是在node角度上，对于有污点的pod，拒绝pod调度到该node
容忍是在pod角度上，对于有污点的node，容忍node的污点，就去这个node
污点就是拒绝，容忍就是忽略，Node通过污点拒绝Pod调度上去，Pod通过容忍忽略拒绝。
污点Taints（理论实操）
可以站在Node的角度上，通过在Node上添加污点属性，来决定是否运行Pod调度过来
Node被设置了污点之后就和Pod之间存在了一种相斥的关系，进而拒绝Pod调度进来，甚至可以将已经存在的Pod驱逐出去
命令行操作（增删改查）
# 设置污点
kubectl taint node <node-name> key=value:effect
# 去除污点
kubectl taint node <node-name> key:effect-
# 去除所有污点
kubectl taint node xxx key-
# 修改就是去除现有，设置新的# 查询
# 查看指定节点上的污点
kubectl describe node <node-name>
[root@master k8s]# kubectl describe node node1 | grep -i taints
Taints: tag=snj:NoExecute# 列出所有节点
# 下载安装 jq
wget -O jq https://github.com/stedolan/jq/releases/download/jq-1.6/jq-linux64
chmod +x ./jq
cp jq /usr/bin
# 列出所有节点的污点方式一
kubectl get nodes -o json | jq '.items[].spec'
# 列出所有节点的污点方式二
kubectl get nodes -o json | jq '.items[].spec.taints'示例
① 准备节点k8s-node1（为了演示效果更加明显，暂时停止k8s-node2节点）。
② 为k8s-node1节点设置一个污点：
tag=xudaxian:PreferNoSchedule，然后创建Pod1（Pod1可以）。
③ 修改k8s-node1节点的污点为：
tag=xudaxian:NoSchedule，然后创建Pod2（Pod1可以正常运行，Pod2失败）。
④ 修改k8s-node1节点的污点为：
tag=xudaxian:NoExecute，然后创建Pod3（Pod1、Pod2、Pod3失败）
# 第一步，关机 node2
连接node2，执行 init 0
# 第二步，对 node1 设置污点（PreferNoSchedule：pod尽量不要来，除非没办法）
[root@master k8s]# kubectl taint node node1 tag=snj:PreferNoSchedule
node/node1 tainted
[root@master k8s]# kubectl describe node node1 | grep -i taints
Taints: tag=snj:PreferNoSchedule
# 运行 pod
[root@master k8s]# kubectl run taint1 --image=nginx:1.17.1 -n default
pod/taint1 created
[root@master k8s]# kubectl get pod -n default
NAME READY STATUS RESTARTS AGE
taint1 1/1 Running 0 25s
# 第三步，为k8s-node1取消污点（PreferNoSchedule）
# 并设置污点（NoSchedule：新的不要来，在这的就别动了）
[root@master k8s]# kubectl taint node node1 tag:PreferNoSchedule-
node/node1 untainted
[root@master k8s]# kubectl taint node node1 tag=snj:NoSchedule
node/node1 tainted
[root@master k8s]# kubectl describe node node1 | grep -i taints
Taints: tag=snj:NoSchedule
# 运行新pod
[root@master k8s]# kubectl run taint2 --image=nginx:1.17.1 -n default
pod/taint2 created
[root@master k8s]# kubectl get pod -n default
NAME READY STATUS RESTARTS AGE
taint1 1/1 Running 0 7m40s
taint2 0/1 Pending 0 18s
# 从上面可以看到，老的pod没问题，新的启动失败
# 第四步，为k8s-node1取消污点（NoSchedule），并设置污点（NoExecute：一个pod都别在我这）
[root@master k8s]# kubectl taint node node1 tag:NoSchedule-
node/node1 untainted
[root@master k8s]# kubectl taint node node1 tag=snj:NoExecute
node/node1 tainted
[root@master k8s]# kubectl describe node node1 | grep -i taints
Taints: tag=snj:NoExecute
# 查看pod，前面的taint1和taint2都没有了
[root@master k8s]# kubectl get pod -n default
No resources found in default namespace.
# 运行新pod
[root@master k8s]# kubectl run taint3 --image=nginx:1.17.1 -n default
pod/taint3 created
[root@master k8s]# kubectl get pod -n default
NAME READY STATUS RESTARTS AGE
taint3 0/1 Pending 0 17s
# 从上面可以看到，老的新的pod都没办法在该node上运行容忍Toleration（理论）
我们可以在Node上添加污点用来拒绝Pod调度上来，但是如果就是想让一个Pod调度到一个有污点的Node上去，这时候应该怎么做？这就需要使用到容忍
污点就是拒绝，容忍就是忽略，Node通过污点拒绝Pod调度上去，Pod通过容忍忽略拒绝。
（示例看 yaml编写中 spec.tolerations）
logs 与 pods 的关系
命令行实操（增删改查）
创建
kubectl run <pod-name> <parameter>
# <parameter>
# --image 指定镜像
# --port 指定开放端口
# --image-pull-policy='' 指定拉取策略
# Always 总是拉取镜像 （默认）
# IfNotPresent 本地有则使用本地镜像,不拉取
# Never 只使用本地镜像，从不拉取，即使本地没有
# 默认值说明：
# 如果镜像tag为具体的版本号，默认策略是IfNotPresent。
# 如果镜像tag为latest（最终版本），默认策略是Always。
# -n 指定命名空间，不指定默认在 default
# 不使用pod控制器
# --replicas=1 1.18以上已经被弃用，变成了使用create进行创建带控制器的pod
kubectl run nginx-test --image=nginx:1.17.1 --port=80
# 使用pod控制器，资源类型为 deployment
# --replicas 如果不指定则默认为 1
kubectl create deployment nginx-test --image=nginx:1.17.1 --port=80[root@master k8s]# kubectl create deployment nginx-test --image=nginx:1.17.1 --port=80
deployment.apps/nginx-test created
[root@master k8s]# kubectl get deployment
NAME READY UP-TO-DATE AVAILABLE AGE
nginx-test 1/1 1 1 27s
[root@master k8s]# kubectl get pod
NAME READY STATUS RESTARTS AGE
nginx-test-64b9b6cf85-nwc9j 1/1 Running 0 31s
[root@master k8s]# kubectl delete pod nginx-test-64b9b6cf85-nwc9j
pod "nginx-test-64b9b6cf85-nwc9j" deleted
[root@master k8s]# kubectl get pod
NAME READY STATUS RESTARTS AGE
nginx-test-64b9b6cf85-vj5w5 0/1 ContainerCreating 0 1s
[root@master k8s]# kubectl get pod
NAME READY STATUS RESTARTS AGE
nginx-test-64b9b6cf85-vj5w5 1/1 Running 0 2s
# 真正删除需要
[root@master k8s]# kubectl delete deployment nginx-test
deployment.apps "nginx-test" deleted
[root@master k8s]# kubectl get deployment
No resources found in default namespace.
[root@master k8s]# kubectl get pod
No resources found in default namespace.查看
# 查看所有命名空间的pod
kubectl get pods -A
# 查看指定命名空间的pod,下面是递进详细的
kubectl get pods -n <namespace>
kubectl get pods -n <namespace> -o wide
名字 容器数量 状态 重启次数 存在时间 ip地址 所在节点
snj-nginx-test 1/1 Running 0 26s 10.244.166.132 node1
kubectl describe pod -n <namespace> <pod-name>
# 非常详细的信息，并且包括pod里面的容器，最下面信息是pod日志
# 一般当pod启动不上来的时候，会用这条命令查看启动日志来排错删除
kubectl delete pod <pod-name> -n <namespace>Pod yaml 编写 示例
查看运行中Pod yaml配置
kubectl get pod -n study nginx-busybox -o yamlyaml字段整体详解
https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#metadata
kubectl explain pod
# 会出现第一层级的内容，大部分资源第一层级基本都是如 apiVersion kind metadata spec status
# 可以通过点的形式查询下一层级的内容
kubectl explain pod.metadata | less
具体可以查看 kubectl 命令解析中的 exposeapiVersion: v1 #必选，版本号，例如v1，kubectl explain pod 可以看到version
kind: Pod #必选，资源类型，例如 Pod
metadata: #必选，元数据
name: string #必选，Pod名称
namespace: string #Pod所属的命名空间,默认为"default"
labels: #自定义标签列表
- name: string
spec: #必选，Pod中容器的详细定义
containers: #必选，Pod中容器列表
- name: string #必选，容器名称
image: string #必选，容器的镜像名称
imagePullPolicy: [ Always|Never|IfNotPresent ] #获取镜像的策略
command: [string] #容器的启动命令列表，如不指定，使用打包时使用的启动命令
args: [string] #容器的启动命令参数列表
workingDir: string #容器的工作目录
volumeMounts: #挂载到容器内部的存储卷配置
- name: string #引用pod定义的共享存储卷的名称，需用volumes[]部分定义的的卷名
mountPath: string #存储卷在容器内mount的绝对路径，应少于512字符
readOnly: boolean #是否为只读模式
ports: #需要暴露的端口库号列表
- name: string #端口的名称
containerPort: int #容器需要监听的端口号
hostPort: int #容器所在主机需要监听的端口号，默认与Container相同
protocol: string #端口协议，支持TCP和UDP，默认TCP
env: #容器运行前需设置的环境变量列表
- name: string #环境变量名称
value: string #环境变量的值
resources: #资源限制和请求的设置
limits: #资源限制的设置
cpu: string #Cpu的限制，单位为core数，将用于docker run --cpu-shares参数
memory: string #内存限制，单位可以为Mib/Gib，将用于docker run --memory参数
requests: #资源请求的设置
cpu: string #Cpu请求，容器启动的初始可用数量
memory: string #内存请求,容器启动的初始可用数量
lifecycle: #生命周期钩子
postStart: #容器启动后立即执行此钩子,如果执行失败,会根据重启策略进行重启
preStop: #容器终止前执行此钩子,无论结果如何,容器都会终止
livenessProbe: #对Pod内各容器健康检查的设置，当探测无响应几次后将自动重启该容器
exec: #对Pod容器内检查方式设置为exec方式
command: [string] #exec方式需要制定的命令或脚本
httpGet: #对Pod内个容器健康检查方法设置为HttpGet，需要制定Path、port
path: string
port: number
host: string
scheme: string
HttpHeaders:
- name: string
value: string
tcpSocket: #对Pod内个容器健康检查方式设置为tcpSocket方式
port: number
initialDelaySeconds: 0 #容器启动完成后首次探测的时间，单位为秒
timeoutSeconds: 0 #对容器健康检查探测等待响应的超时时间，单位秒，默认1秒
periodSeconds: 0 #对容器监控检查的定期探测时间设置，单位秒，默认10秒一次
successThreshold: 0
failureThreshold: 0
securityContext:
privileged: false
restartPolicy: [Always | Never | OnFailure] #Pod的重启策略
nodeName: <string> #设置NodeName表示将该Pod调度到指定到名称的node节点上
nodeSelector: obeject #设置NodeSelector表示将该Pod调度到包含这个label的node上
imagePullSecrets: #Pull镜像时使用的secret名称，以key：secretkey格式指定
- name: string
hostNetwork: false #是否使用主机网络模式，默认为false，如果设置为true，表示使用宿主机网络
volumes: #在该pod上定义共享存储卷列表
- name: string #共享存储卷名称 （volumes类型有很多种）
emptyDir: {} #类型为emtyDir的存储卷，与Pod同生命周期的一个临时目录。为空值
hostPath: string #类型为hostPath的存储卷，表示挂载Pod所在宿主机的目录
path: string #Pod所在宿主机的目录，将被用于同期中mount的目录
secret: #类型为secret的存储卷，挂载集群与定义的secret对象到容器内部
scretname: string
items:
- key: string
path: string
configMap: #类型为configMap的存储卷，挂载预定义的configMap对象到容器内部
name: string
items:
- key: string
path: stringspec.containers（容器）
pod.spec.containers 属性，这也是Pod配置中最为关键的一项配置
# 返回的重要属性
KIND: Pod
VERSION: v1
RESOURCE:
containers <[]Object> # 数组，代表可以有多个容器FIELDS:
- name <string> # 容器名称
image <string> # 容器需要的镜像地址
imagePullPolicy <string> # 镜像拉取策略
command <[]string> # 容器的启动命令列表，如不指定，使用打包时使用的启动命令
args <[]string> # 容器的启动命令需要的参数列表
env <[]Object> # 容器环境变量的配置
ports <[]Object> # 容器需要暴露的端口号列表
resources <Object> # 资源限制和资源请求的设置基本配置
---
apiVersion: v1
kind: Namespace
metadata:
name: study
---
apiVersion: v1
kind: Pod
metadata:
name: nginx-busybox
namespace: study
labels:
user: snj
spec:
containers:
- name: nginx
image: nginx:1.17.1
- name: busybox
image: busybox:1.30出现问题：不是持续运行的pod需要设置启动命令 ，可以看下面的章节中的启动命令
[root@master k8s]# kubectl get pod -n study
NAME READY STATUS RESTARTS AGE
nginx-busybox 1/2 CrashLoopBackOff 4 (52s ago) 2m31s拉取镜像（imagepullpolicy）
上面已经拉取过这个两个镜像了，如果改成 Always，也不会重复拉取，本地不会多出来一个同版本的镜像
如果设置了成这个，使用 kubectl describe pod -n study 查看pod创建过程会看到
Container image "nginx:1.17.1" already present on machine #表示本地有这个镜像
apiVersion: v1
kind: Pod
metadata:
name: pod-imagepullpolicy
namespace: dev
labels:
user: xudaxian
spec:
containers:
- name: nginx # 容器名称
image: nginx:1.17.1 # 容器需要的镜像地址
imagePullPolicy: IfNotPresent # 用于设置镜像的拉取策略
- name: busybox # 容器名称
image: busybox:1.30 # 容器需要的镜像地址启动命令（command）
command 用于在Pod中的容器初始化完毕之后执行一个命令
有一些容器是必须解决启动命令的，比如 busybox并不是一个程序，而是类似于一个工具类的集合，kubernetes集群启动管理后，它会自动关闭。解决方法就是让其一直在运行，这就用到了command的配置。
apiVersion: v1
kind: Pod
metadata:
name: pod-command
namespace: dev
labels:
user: xudaxian
spec:
containers:
- name: nginx # 容器名称
image: nginx:1.17.1 # 容器需要的镜像地址
imagePullPolicy: IfNotPresent # 设置镜像拉取策略
- name: busybox # 容器名称
image: busybox:1.30 # 容器需要的镜像地址
command: ["/bin/sh","-c","touch /tmp/hello.txt;while true;do /bin/echo $(date +%T) >> /tmp/hello.txt;sleep 3;done;"]command：用于在Pod中的容器初始化完毕之后执行一个命令。
这里稍微解释下command中的命令的意思：
"/bin/sh","-c"：使用sh执行命令。
touch /tmp/hello.txt 创建一个/tmp/hello.txt的文件。
; 分隔符 (每行命令的结尾,作用类似于回车)
while true;do /bin/echo $(date +%T) >> /tmp/hello.txt;sleep 3;done;
每隔3秒，向文件写入当前时间
# 在容器中执行命令
# kubectl exec -it pod的名称 -n 命名空间 -c 容器名称 /bin/sh
[root@master k8s]# kubectl exec -it -n study nginx-busybox -c busybox -- tail -f /tmp/hello.txt
14:09:32
14:09:35command 和 args 区别
特别说明：通过上面发现command已经可以完成启动命令和传递参数的功能，为什么还要提供一个args选项，用于传递参数？其实和Docker有点关系，kubernetes中的command和args两个参数其实是为了实现覆盖Dockerfile中的ENTRYPOINT的功能：
- 如果command和args均没有写，那么用Dockerfile的配置。
- 如果command写了，但是args没有写，那么Dockerfile默认的配置会被忽略，执行注入的command。
- 如果command没有写，但是args写了，那么Dockerfile中配置的ENTRYPOINT命令会被执行，使用当前args的参数。（重要）
- 如果command和args都写了，那么Dockerfile中的配置会被忽略，执行command并追加上args参数。
只写 args 使用dockerfile配置中的命令，传入不同的参数
只写 command 会覆盖掉Dockerfile的command和args
环境变量（不推荐）
---
apiVersion: v1
kind: Namespace
metadata:
name: study
---
apiVersion: v1
kind: Pod
metadata:
name: nginx-busybox
namespace: study
labels:
user: snj
spec:
containers:
- name: nginx
image: nginx:1.17.1
imagePullPolicy: IfNotPresent
- name: busybox
image: busybox:1.30
imagePullPolicy: IfNotPresent
command: ["/bin/sh","-c","touch /tmp/hello.txt;while true;do /bin/echo $(date +%T) >> /tmp/hello.txt;sleep 3;done;"]
env: # 设置环境变量列表
- name: "username"
value: "admin"
- name: "password"
value: "123456"[root@master k8s]# kubectl exec -it -n study nginx-busybox -c busybox /bin/sh
kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl exec [POD] -- [COMMAND] instead.
/ # echo $username
admin端口设置（ports）
RESOURCE: ports <[]Object>
name <string> # 端口名称，如果指定，必须保证name在pod中是唯一的，如果只暴露一个端口可以不写
containerPort <integer> # 容器要监听的端口(0<x<65536)，也就是容器和pod打开的端口
hostPort <integer> # 容器要在主机上公开的端口，如果设置，主机上只能运行容器的一个副本(一般省略）
hostIP <string> # 要将外部端口绑定到的主机IP(一般省略)
protocol <string> # 端口协议。必须是UDP、TCP或SCTP。默认为“TCP”---
apiVersion: v1
kind: Namespace
metadata:
name: study
---
apiVersion: v1
kind: Pod
metadata:
name: nginx-busybox
namespace: study
labels:
user: snj
spec:
containers:
- name: nginx
image: nginx:1.17.1
imagePullPolicy: IfNotPresent
ports: # 设置映射端口
- name: nginx-port
protocol: TCP
containerPort: 80 # 映射到pod上
- name: busybox
image: busybox:1.30
imagePullPolicy: IfNotPresent
command: ["/bin/sh","-c","touch /tmp/hello.txt;while true;do /bin/echo $(date +%T) >> /tmp/hello.txt;sleep 3;done;"]
env:
- name: "username"
value: "admin"[root@master k8s]# kubectl get pod -n study -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx-busybox 2/2 Running 0 14s 10.244.166.159 node1 <none> <none>
[root@master k8s]# curl 10.244.166.159:80资源配置（resources）
容器中的程序要运行，肯定会占用一定的资源，比如CPU和内存等，如果不对某个容器的资源做限制，那么它就可能吃掉大量的资源，导致其他的容器无法运行。针对这种情况，kubernetes提供了对内存和CPU的资源进行配额的机制，这种机制主要通过resources选项实现，它有两个子选项：
- limits：用于限制运行的容器的最大占用资源，当容器占用资源超过limits时会被终止，并进行重启。
- requests：用于设置容器需要的最小资源，如果环境资源不够，容器将无法启动。
- 可以通过上面的两个选项设置资源的上下限。
---
apiVersion: v1
kind: Namespace
metadata:
name: study
---
apiVersion: v1
kind: Pod
metadata:
name: nginx-busybox
namespace: study
labels:
user: snj
spec:
containers:
- name: nginx
image: nginx:1.17.1
imagePullPolicy: IfNotPresent
ports:
- name: nginx-port
protocol: TCP
containerPort: 80
resources: # 资源配额
limits: # 限制资源的上限
cpu: 2 # CPU限制，单位是core数
memory: 10Gi # 内存限制
requests: # 限制资源的下限
cpu: 1 # CPU限制，单位是core数
memory: 10Mi # 内存限制
- name: busybox
image: busybox:1.30
imagePullPolicy: IfNotPresent
command: ["/bin/sh","-c","touch /tmp/hello.txt;while true;do /bin/echo $(date +%T) >> /tmp/hello.txt;sleep 3;done;"]
env:
- name: "username"
value: "admin"钩子函数（lifecycle）
- 钩子处理器支持使用下面的三种方式定义动作：
- ① exec命令：在容器内执行一次命令
- command跟上面启动命令的command是一样的
…… lifecycle: postStart: exec: command: - cat - /tmp/healthy …… lifecycle: postStart: exec: command: ["/bin/sh","-c","echo postStart ... > /usr/share/nginx/html/index.html"] - ② tcpSocket：在当前容器尝试访问指定的socket。
…… lifecycle: postStart: tcpSocket: port: 8080 …… - ③ httpGet：在当前容器中向某url发起HTTP请求。
…… lifecycle: postStart: httpGet: path: / #URI地址 port: 80 #端口号 host: 192.168.109.100 #主机地址 scheme: HTTP #支持的协议，http或者https ……
- command跟上面启动命令的command是一样的
- ① exec命令：在容器内执行一次命令
，以exec方式为例，演示下钩子函数的使用，整体yaml，内容如下-
--
apiVersion: v1
kind: Namespace
metadata:
name: study
---
apiVersion: v1
kind: Pod
metadata:
name: pod-hook-exec
namespace: study
labels:
user: snj
spec:
containers: # 容器配置
- name: nginx
image: nginx:1.17.1
imagePullPolicy: IfNotPresent
ports:
- name: nginx-port
containerPort: 80
protocol: TCP
lifecycle: # 生命周期配置
postStart: # 容器创建之后执行，如果失败会重启容器
exec: # 在容器启动的时候，执行一条命令，修改掉Nginx的首页内容
command: ["/bin/sh","-c","echo postStart ... > /usr/share/nginx/html/index.html"]
preStop: # 容器终止之前执行，执行完成之后容器将成功终止，在其完成之前会阻塞删除容器的操作
exec: # 在容器停止之前停止Nginx的服务
command: ["/usr/sbin/nginx","-s","quit"][root@master k8s]# kubectl get pod -n study
NAME READY STATUS RESTARTS AGE
pod-hook-exec 1/1 Running 0 14s
[root@master k8s]# kubectl get pod -n study -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
pod-hook-exec 1/1 Running 0 26s 10.244.166.163 node1 <none> <none>
[root@master k8s]# curl 10.244.166.163
postStart ...活性探测（livenessProbe）
（1）exec
apiVersion: v1
kind: Pod
metadata:
name: pod-liveness-exec
namespace: dev
labels:
user: xudaxian
spec:
containers: # 容器配置
- name: nginx
image: nginx:1.17.1
imagePullPolicy: IfNotPresent
ports:
- name: nginx-port
containerPort: 80
protocol: TCP
livenessProbe: # 存活性探针
exec:
command: ["/bin/cat","/tmp/hello.txt"] # 执行一个查看文件的命令，没有这个文件必须失败，因为根本没有这个文件，如果这个命令能执行，哪探测是成功的
- 观察上面的信息就会发现nginx容器启动之后就进行了健康检查。
- 检查失败之后，容器被kill掉，然后尝试进行重启，这是重启策略的作用。
- 稍等一会之后，再观察Pod的信息，就会看到RESTARTS不再是0，而是一直增长。
（2）tcpSocket
apiVersion: v1
kind: Pod
metadata:
name: pod-liveness-tcpsocket
namespace: dev
labels:
user: xudaxian
spec:
containers: # 容器配置
- name: nginx
image: nginx:1.17.1
imagePullPolicy: IfNotPresent
ports:
- name: nginx-port
containerPort: 80
protocol: TCP
livenessProbe: # 存活性探针
tcpSocket:
port: 8080 # 尝试访问8080端口，必须失败，因为Pod内部只有一个Nginx容器，而且只是监听了80端口
稍等一会之后，再观察Pod的信息，就会看到RESTARTS不再是0，而是一直增长。
（3）httpGet
apiVersion: v1
kind: Pod
metadata:
name: pod-liveness-httpget
namespace: dev
labels:
user: xudaxian
spec:
containers: # 容器配置
- name: nginx
image: nginx:1.17.1
imagePullPolicy: IfNotPresent
ports:
- name: nginx-port
containerPort: 80
protocol: TCP
livenessProbe: # 存活性探针
httpGet: # 其实就是访问http://127.0.0.1:80/hello
port: 80 # 端口号
scheme: HTTP # 支持的协议，HTTP或HTTPS
path: /hello # URI地址
host: 127.0.0.1 # 主机地址
补充
startupProbe，判断容器内应用程序是否已经启动。如果配置了startupProbe探针，就会先禁止其他的探针，直到startupProbe探针成功为止，一旦成功将不再进行探测（k8s在1.16版本之后新增）注意这个与livenessProbe，readinessProbe是一个层级
kubectl explain pod.spec.containers.livenessProbe
FIELDS:
exec
tcpSocket
httpGet
initialDelaySeconds # 容器启动后等待多少秒执行第一次探测
timeoutSeconds # 探测超时时间。默认1秒，最小1秒 注意：新版本可能会忽略这个参数
periodSeconds # 执行探测的频率。默认是10秒，最小1秒
failureThreshold # 连续探测失败多少次才被认定为失败。默认是3。最小值是1
successThreshold # 连续探测成功多少次才被认定为成功。默认是1卷挂载（volumeMounts）
volumeMounts:
- name: sec-ctx-vol #卷名，指定vloumes中的卷名，进行绑定
mountPath: /data/demo # 挂载到容器中目录
apiVersion: v1
kind: Pod
metadata:
name: security-context-demo
spec:
volumes:
- name: sec-ctx-vol
emptyDir: {} # 卷类型
containers:
- name: sec-ctx-demo
image: busybox:1.28
command: [ "sh", "-c", "sleep 1h" ]
volumeMounts:
- name: sec-ctx-vol
mountPath: /data/demo安全上下文（securityContext）
下面的示例就是设置pod中容器所使用的是指定的用户，这样所有额外创建的文件，包括运行的程序，和登入到容器中的用户都不是root，没办法对容器中系统文件进行修改，大大调高了安全性
apiVersion: v1
kind: Pod
metadata:
name: security-context-demo
spec:
securityContext:
runAsUser: 1000 # 指定 Pod 中的所有容器内的进程都使用用户 ID 1000 来运行
# 如果忽略此字段，则容器的主组 ID 将是 root（0）
runAsGroup: 3000 # 指定所有容器中的进程都以主组 ID 3000 来运行
# 如果 runAsGroup 被忽略，则 gid 会取值 0（root）
# 而进程就能够与 root 用户组所拥有以及要求 root 用户组访问权限的文件交互
fsGroup: 2000 # 容器中所有进程也会是附组 ID 2000 的一部分
# 卷 /data/demo 及在该卷中创建的任何文件的属主都会是组 ID 2000
volumes:
- name: sec-ctx-vol
emptyDir: {}
containers:
- name: sec-ctx-demo
image: busybox:1.28
command: [ "sh", "-c", "sleep 1h" ]
volumeMounts:
- name: sec-ctx-vol
mountPath: /data/demo
securityContext:
allowPrivilegeEscalation: false[root@master DashBoard]# kubectl get pod
NAME READY STATUS RESTARTS AGE
security-context-demo 1/1 Running 0 8m1s
[root@master DashBoard]# kubectl exec -it security-context-demo -- sh
/ $ ps -h
PID USER TIME COMMAND
1 1000 0:00 sleep 1h
7 1000 0:00 sh
14 1000 0:00 ps -a
/ $ cd /data/
/data $ ls -l
total 0
drwxrwsrwx 2 root 2000 6 Feb 28 02:35 demo
# 输出显示 /data/demo 目录的组 ID 为 2000，即 fsGroup 的设置值
/data/demo $ id
uid=1000 gid=3000 groups=2000,3000
# 从输出中你会看到 gid 值为 3000，也就是 runAsGroup 字段的值spec.initContainers（初始化容器）
下面示例是模拟：nginx容器启动前，判断是否能连上mysql和redis
使用方法小型linux busybox 使用ping命令来测试Pod与其的网络连接
两者都能连上则启动nginx主容器，如果ping不通，pod会一直init状态
initContainers 该字段配置跟containers没有区别就是字段名字上加了一个init
---
apiVersion: v1
kind: Namespace
metadata:
name: study
---
apiVersion: v1
kind: Pod
metadata:
name: pod-initcontainer
namespace: study
labels:
user: snj
spec:
containers: # 容器配置
- name: nginx
image: nginx:1.17.1
imagePullPolicy: IfNotPresent
ports:
- name: nginx-port
containerPort: 80
protocol: TCP
initContainers: # 初始化容器配置
- name: test-mysql
image: busybox:1.30
command: ["sh","-c","until ping 192.168.100.103 -c 1;do echo waiting for mysql ...;sleep 2;done;"]
securityContext:
privileged: true # 使用特权模式运行容器
- name: test-redis
image: busybox:1.30
command: ["sh","-c","until ping 192.168.100.104 -c 1;do echo waiting for redis ...;sleep 2;done;"][root@master k8s]# kubectl get pod -n study
NAME READY STATUS RESTARTS AGE
pod-initcontainer 0/1 Init:0/2 0 24s
kubectl describe pod -n study pod-initcontainer
ifconfig ens160:1 192.168.100.103 netmask 255.255.255.0 up
^C[root@master k8s]# kubectl get pod -n study -w
NAME READY STATUS RESTARTS AGE
pod-initcontainer 0/1 Init:0/2 0 2m22s
pod-initcontainer 0/1 Init:1/2 0 3m2s
pod-initcontainer 0/1 Init:1/2 0 3m3s
ifconfig ens160:2 192.168.100.104 netmask 255.255.255.0 up
^C[root@master k8s]# kubectl get pod -n study -w
NAME READY STATUS RESTARTS AGE
pod-initcontainer 0/1 Init:0/2 0 2m22s
pod-initcontainer 0/1 Init:1/2 0 3m2s
pod-initcontainer 0/1 Init:1/2 0 3m3s
pod-initcontainer 0/1 PodInitializing 0 3m38s
pod-initcontainer 1/1 Running 0 3m39sspec.restartPolicy（重启策略）
---
apiVersion: v1
kind: Namespace
metadata:
name: study
---
apiVersion: v1
kind: Pod
metadata:
name: pod-restart-policy
namespace: study
labels:
user: snj
spec:
containers: # 容器配置
- name: nginx
image: nginx:1.17.1
imagePullPolicy: IfNotPresent
ports:
- name: nginx-port
containerPort: 80
protocol: TCP
livenessProbe: # 存活性探测
httpGet:
port: 80
path: /hello
host: 127.0.0.1
scheme: HTTP
restartPolicy: Never # 重启策略
调度
spec.nodeName（定向调度：node）
---
apiVersion: v1
kind: Namespace
metadata:
name: study
---
apiVersion: v1
kind: Pod
metadata:
name: nginx-nodename
namespace: study
labels:
user: snj
spec:
containers: # 容器配置
- name: nginx
image: nginx:1.17.1
imagePullPolicy: IfNotPresent
ports:
- name: nginx-port
containerPort: 80
protocol: TCP
nodeName: node2 # 指定调度到node2节点上
[root@master k8s]# kubectl get pod -n study -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx-scheduler 1/1 Running 0 12s 10.244.166.164 node2 <none> <none>spec.nodeSelector（定向调度：Selector）
kubectl label node node1 nodeenv=pro
kubectl label node node2 nodeenv=testapiVersion: v1
kind: Pod
metadata:
name: pod-nodeselector
namespace: study
spec:
containers: # 容器配置
- name: nginx
image: nginx:1.17.1
imagePullPolicy: IfNotPresent
ports:
- name: nginx-port
containerPort: 80
protocol: TCP
nodeSelector:
nodeenv: pro # 指定调度到具有nodeenv=pro的Node节点上spec.affinity.nodeAffinity
spec
affinity
nodeAffinity
requiredDuringSchedulingIgnoredDuringExecution
# Node节点必须满足指定的所有规则才可以，相当于硬限制
nodeSelectorTerms 节点选择列表
matchFields 按节点字段列出的节点选择器要求列表
matchExpressions 按节点标签列出的节点选择器要求列表(推荐)
key 键
values 值
operator 关系符 支持Exists, DoesNotExist, In, NotIn, Gt, Lt
# 上面跟spec.nodeSelector很一样，强制性但匹配规则更多，下面这个才是亲和性
preferredDuringSchedulingIgnoredDuringExecution
# 优先调度到满足指定的规则的Node，相当于软限制 (倾向)
preference 一个节点选择器项，与相应的权重相关联
matchFields 按节点字段列出的节点选择器要求列表
matchExpressions 按节点标签列出的节点选择器要求列表(推荐)
key 键
values 值
operator 关系符 支持In, NotIn, Exists, DoesNotExist, Gt, Lt
weight 倾向权重，在范围1-100。nodeAffinity的注意事项：
如果同时定义了nodeSelector和nodeAffinity，那么必须两个条件都满足，Pod才能运行在指定的Node上。
如果nodeAffinity指定了多个nodeSelectorTerms，那么只需要其中一个能够匹配成功即可。
如果一个nodeSelectorTerms中有多个matchExpressions，则一个节点必须满足所有的才能匹配成功。
如果一个Pod所在的Node在Pod运行期间其标签发生了改变，不再符合该Pod的nodeAffinity的要求，则系统将忽略此变化。operator 关系符 支持In, NotIn, Exists, DoesNotExist, Gt, Lt
In：label 的值在某个列表中
NotIn：label 的值不在某个列表中
Gt：label 的值大于某个值
Lt：label 的值小于某个值
Exists：某个 label 存在
DoesNotExist：某个 label 不存在
示例
- matchExpressions:
- key: nodeenv # 匹配存在标签的key为nodeenv的节点
operator: Exists
- key: nodeenv # 匹配标签的key为nodeenv,且value是"xxx"或"yyy"的节点
operator: In
values: ["xxx","yyy"]
- key: nodeenv # 匹配标签的key为nodeenv,且value大于"xxx"的节点
operator: Gt
values: "xxx"硬限制示例
apiVersion: v1
kind: Pod
metadata:
name: pod-nodeaffinity-required
namespace: study
labels:
user: snj
spec:
containers: # 容器配置
- name: nginx
image: nginx:1.17.1
imagePullPolicy: IfNotPresent
ports:
- name: nginx-port
containerPort: 80
protocol: TCP
affinity: # 亲和性配置
nodeAffinity: # node亲和性配置
requiredDuringSchedulingIgnoredDuringExecution:
# Node节点必须满足指定的所有规则才可以，相当于硬规则，类似于定向调度
nodeSelectorTerms: # 节点选择列表
- matchExpressions:
- key: nodeenv # 匹配存在标签的key为nodeenv的节点，并且value是"xxx"或"yyy"的节点
operator: In
values:
- "xxx"
- "yyy"
软限制示例
apiVersion: v1
kind: Pod
metadata:
name: pod-nodeaffinity-preferred
namespace: study
labels:
user: snj
spec:
containers: # 容器配置
- name: nginx
image: nginx:1.17.1
imagePullPolicy: IfNotPresent
ports:
- name: nginx-port
containerPort: 80
protocol: TCP
affinity: # 亲和性配置
nodeAffinity: # node亲和性配置
preferredDuringSchedulingIgnoredDuringExecution: # 优先调度到满足指定的规则的Node，相当于软限制 (倾向)
- preference: # 一个节点选择器项，与相应的权重相关联
matchExpressions:
- key: nodeenv
operator: In
values:
- "xxx"
- "yyy"
weight: 1spec.affinity.podAffinity
podAffinity主要实现以运行的Pod为参照，实现让新创建的Pod和参照的Pod在一个区域的功能。
spec
affinity
podAffinity
requiredDuringSchedulingIgnoredDuringExecution 硬限制
namespaces 指定参照pod的namespace
topologyKey 指定调度作用域
labelSelector 标签选择器
matchExpressions 按节点标签列出的节点选择器要求列表(推荐)
key 键
values 值
operator 关系符 支持In, NotIn, Exists, DoesNotExist.
matchLabels 指多个matchExpressions映射的内容
preferredDuringSchedulingIgnoredDuringExecution 软限制
podAffinityTerm 选项
namespaces
topologyKey
labelSelector
matchExpressions
key 键
values 值
operator
matchLabels
weight 倾向权重，在范围1-1如果指定为kubernetes.io/hostname，那就是以Node节点为区分范围。
如果指定为beta.kubernetes.io/os，则以Node节点的操作系统类型来区分。硬限制示例
apiVersion: v1
kind: Pod
metadata:
name: pod-podaffinity-target
namespace: study
labels:
podstudy: snj # 设置标签
spec:
containers: # 容器配置
- name: nginx
image: nginx:1.17.1
imagePullPolicy: IfNotPresent
ports:
- name: nginx-port
containerPort: 80
protocol: TCP
nodeName: node2 # 将目标pod定向调度到node2 节点
[root@master k8s]# kubectl get pod -n study -o wide --show-labels
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES LABELS
pod-podaffinity-target 1/1 Running 0 47s 10.244.104.17 node2 <none> <none> podstudy=snjapiVersion: v1
kind: Pod
metadata:
name: pod-podaffinity-requred
namespace: study
spec:
containers: # 容器配置
- name: nginx
image: nginx:1.17.1
imagePullPolicy: IfNotPresent
ports:
- name: nginx-port
containerPort: 80
protocol: TCP
affinity: # 亲和性配置
podAffinity: # Pod亲和性
requiredDuringSchedulingIgnoredDuringExecution: # 硬限制
- labelSelector:
matchExpressions: # 该Pod必须和拥有标签podenv=xxx或者podenv=yyy的Pod在同一个Node上，显然没有这样的Pod
- key: podstudy
operator: In
values:
- "snj"
- "yyy"
topologyKey: kubernetes.io/hostname[root@master k8s]# kubectl get pod -n study -o wide --show-labels
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES LABELS
pod-podaffinity-requred 1/1 Running 0 3s 10.244.104.18 node2 <none> <none> <none>
pod-podaffinity-target 1/1 Running 0 102s 10.244.104.17 node2 <none> <none> podstudy=snj
spec.affinity.podAntiAffinity
硬限制示例
使用上面 spec.affinity.podAffinity 的硬限制示例
apiVersion: v1
kind: Pod
metadata:
name: pod-podantiaffinity-requred
namespace: study
spec:
containers: # 容器配置
- name: nginx
image: nginx:1.17.1
imagePullPolicy: IfNotPresent
ports:
- name: nginx-port
containerPort: 80
protocol: TCP
affinity: # 亲和性配置
podAntiAffinity: # Pod反亲和性
requiredDuringSchedulingIgnoredDuringExecution: # 硬限制
- labelSelector:
matchExpressions:
- key: podstudy
operator: In
values:
- "snj"
topologyKey: kubernetes.io/hostname现有环境，上面yaml就是让创建的pod对标签为podstudy=snj具有反亲和性（硬限制）
[root@master k8s]# kubectl get pod -n study -o wide --show-labels
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES LABELS
pod-podaffinity-target 1/1 Running 0 8m25s 10.244.104.17 node2 <none> <none> podstudy=snj[root@master k8s]# kubectl apply -f nginx-2.yaml
pod/pod-podantiaffinity-requred created
[root@master k8s]# kubectl get pod -n study -o wide --show-labels
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES LABELS
pod-podaffinity-target 1/1 Running 0 10m 10.244.104.17 node2 <none> <none> podstudy=snj
pod-podantiaffinity-requred 1/1 Running 0 3s 10.244.166.168 node1 <none> <none> <none>spec.tolerations（容忍）
kubectl explain pod.spec.tolerations
......
FIELDS:
key # 对应着要容忍的污点的键，空意味着匹配所有的键
value # 对应着要容忍的污点的值
operator # key-value的运算符，支持Equal和Exists（默认）
effect # 对应污点的effect，空意味着匹配所有影响
tolerationSeconds # 容忍时间, 当effect为NoExecute时生效，表示pod在Node上的停留时间当operator为Equal的时候，如果Node节点有多个Taint，那么Pod每个Taint都需要容忍才能部署上去。
当operator为Exists的时候，不用配value，有如下的三种写法：
tolerations: # 容忍
- key: "tag" # 要容忍的污点的key
operator: Exists # 操作符
effect: NoExecute # 添加容忍的规则，这里必须和标记的污点规则相同 tolerations: # 容忍
- key: "tag" # 要容忍的污点的key
operator: Exists # 操作符 tolerations: # 容忍
- operator: Exists # 操作符# 连接node2，执行 init 0
# node1 设置污点（NoExecute：一个pod都别在我这）
[root@master k8s]# kubectl taint node node1 tag=snj:PreferNoSchedule
node/node1 tainted
[root@master k8s]# kubectl describe node node1 | grep -i taints
Taints: tag=snj:NoExecute
apiVersion: v1
kind: Pod
metadata:
name: pod-toleration
namespace: study
spec:
containers: # 容器配置
- name: nginx
image: nginx:1.17.1
imagePullPolicy: IfNotPresent
ports:
- name: nginx-port
containerPort: 80
protocol: TCP
tolerations: # 容忍
- key: "tag" # 要容忍的污点的key
operator: Equal # 操作符
value: "snj" # 要容忍的污点的value
effect: NoExecute # 添加容忍的规则，这里必须和标记的污点规则相同[root@master k8s]# kubectl get pods -n study -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
pod-toleration 1/1 Running 0 28s 10.244.166.174 node1 <none> <none
扫一扫
354
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
