Pod详解
本章主要介绍Pod资源的各种配置（yaml文件）和原理
1. Pod介绍
如上图所示，每个Pod中都可以包含一个或多个Container，这些Containers 可以分为2类：
- 用户程序所在的Container，数量可多可少
- Pause容器，这是每个Pod都会有的一个根容器，它的作用有2个：
- 可以以它为依据，评估整个Pod的健康状态
- 可以在跟容器上设置IP地址，其他容器都可以使用此IP（Pod IP）实现Pod内部的网络通信。这里Pod内部通讯是指完全的Pod内部，对于不同Pod之间的通讯则采用的是虚拟二层网络技术实现，例如Flannel
2. Pod 定义
可以通过kubectl explain命令查看每种资源的可配置项：
$ kubectl explain pod KIND: Pod VERSION: v1 FIELDS: apiVersion <string> kind <string> metadata <Object> spec <Object> status <Object> # 查看属性的子属性 $ kubectl explain pod.metadata KIND: Pod VERSION: v1 RESOURCE: metadata <Object> FIELDS: annotations <map[string]string> clusterName <string> …
在Kubernetes中基本所有资源的一级属性都是一样的，主要包含5部分：
- apiVersion <string>：版本，由kubernetes内部定义，版本号必须能在kubectl api-versions查询到
- kind <string>：类型，由kubernetes内部定义，版本号必须可以用kubectl api-resources 查询到
- metadata <Object> ：元数据，主要是资源标识和说明，常用的有name、namespace、labels等
- spec <Object> ：描述，这是配置中最重要的一部分，里面是对各种资源配置的详细描述
- status <Object>：状态信息，里面的内容不需要定义，由kubernetes自动生成
在上面的属性中，spec是接下来研究的重点对象，它常见的子属性有：
- containers <[]Object>：容器列表，用于定义容器的详细信息
- nodeName <String>：根据nodeName的值将pod调度到指定Node节点上
- nodeSelector <map[]>：根据NodeSelector中定义的信息选择将该Pod调度到包含这些label的Node上
- hostNetwork <boolean>：是否使用主机网络模式，默认为false，如果设置为true，表示使用宿主机网络。默认用的是Pod IP。若是主机网络模式下，若是有多个Pod均用同一端口的话，则会有冲突，所以很少改动此配置
- volumes <[]Object>：存储卷，用于定义Pod上面挂载的存储信息
- restartPolicy <String>：重启策略，表示Pod在遇到故障时的处理策略
3. Pod 配置
本小节主要研究 pod.spec.containers 属性，这也是pod属性中最关键的一项配置
$ kubectl explain pod.spec.containers KIND: Pod VERSION: v1 RESOURCE: containers <[]Object> FIELDS: args <[]string> # 容器的启动命令需要的参数列表 command <[]string> # 容器的启动命令列表，如不指定，使用打包时的启动命令 env <[]Object> # 容器环境变量的配置 image <string> # 容器需要的镜像地址 imagePullPolicy <string> # 镜像拉取策略 name <string> -required- # 容器名称 ports <[]Object> # 容器需要暴露的端口号列表 resources <Object> # 资源限制和资源请求的设置
3.1. 基本配置
创建 pod-base.yaml 文件，内容为：
$ cat yamls/pod-base.yaml apiVersion: v1 kind: Pod metadata: name: pod-base namespace: dev labels: user: zack spec: containers: - name: nginx image: nginx:1.17.1 - name: busybox image: busybox:1.30
上面定义了1个简单的Pod，里面有2个containers：
- nginx：用1.17.1版本的nginx创建镜像
- busybox：用1.30版本的busybox镜像创建（busybox是一个小巧的linux命令集合）
# 创建pod $ kubectl apply -f yamls/pod-base.yaml pod/pod-base created # 查看pod状态 $ kubectl get pod -n dev NAME READY STATUS RESTARTS AGE pod-base 1/2 CrashLoopBackOff 1 12s => 这里ready 1/2 表示，一共有2个containers，当前已经ready的只有1个 => restarts 表示重启了 1 次 # 再次查看pod状态 $ kubectl get pod -n dev NAME READY STATUS RESTARTS AGE pod-base 1/2 NotReady 3 58s => 可以看到restart 有3 次，说明重启次数增加，且pod状态为NotReady，说明 pod 启动出现问题 # 使用describe 查看详细状态 $ kubectl describe pod pod-base -n dev Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 5m8s default-scheduler Successfully assigned dev/pod-base to ip-10-0-1-217.cn-north-1.compute.internal Normal Pulled 5m7s kubelet Container image "nginx:1.17.1" already present on machine Normal Created 5m7s kubelet Created container nginx Normal Started 5m6s kubelet Started container nginx Normal Pulling 5m6s kubelet Pulling image "busybox:1.30" Normal Pulled 5m kubelet Successfully pulled image "busybox:1.30" Normal Started 4m21s (x4 over 5m) kubelet Started container busybox Normal Created 3m39s (x5 over 5m) kubelet Created container busybox Normal Pulled 3m39s (x4 over 5m) kubelet Container image "busybox:1.30" already present on machine Warning BackOff 3s (x24 over 4m59s) kubelet Back-off restarting failed container => 可以看到nginx 是没问题的，但是busybox一直在尝试重启。此问题是测试环境中故意制造的问题，为了方便展示pod的配置与启动。
3.2. 镜像拉取
imagePullPolicy 用于设置镜像拉取策略，kubernetes支持配置3种拉取策略：
- Always：总是从远程拉取镜像
- IfNotPresent：本地有则使用本地镜像，本地没有则从远程仓库拉取镜像
- Never：只是用本地镜像，从不去远程仓库拉取，本地没有就报错
默认值说明：
- 如果镜像tag为具体版本号，默认策略是：IfNotPresent
- 如果镜像tag为：latest，默认策略是：Always
一个示例Pod配置文件：
$ cat yamls/pod-base.yaml apiVersion: v1 kind: Pod metadata: name: pod-base namespace: dev labels: user: zack spec: containers: - name: nginx image: nginx:1.17.1 imagePullPolicy: Always - name: busybox image: busybox:1.30
3.3. Pod启动命令
在之前的例子中，busybox的pod会一直重试并失败。这是因为busybox并不是一个程序，而是类似于一个工具的集合，kubernetes集群启动管理后，它会自动关闭。解决方法就是让它一直处于运行状态，这就用到了command配置。
创建pod-command.yaml 文件，内容如下：
$ cat yamls/pod-command.yaml apiVersion: v1 kind: Pod metadata: name: pod-command namespace: dev labels: user: zack spec: containers: - name: nginx image: nginx:1.17.1 imagePullPolicy: Always - 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;"]
运行并检查：
$ kubectl apply -f yamls/pod-command.yaml pod/pod-command created $ kubectl get pods -n dev NAME READY STATUS RESTARTS AGE pod-base 1/2 CrashLoopBackOff 8 20m pod-command 2/2 Running 0 6s
可以看到pod-command 中2个container均是running 状态。
在busybox中，我们运行的command 内容是将日期输入到一个临时文件中，若是需要进入container检查此文件，可以执行：
# 进入pod中的busybox container 查看文件内容 # 命令格式：kubectl exec <pod_name> -n <namespace> -it -c <container_name> -- <command> $ kubectl exec pod-command -n dev -it -c busybox -- /bin/sh / # tail /tmp/hello.txt 07:19:40 07:19:43 07:19:46 07:19:49 07:19:52 07:19:55 07:19:58 07:20:01 07:20:04 07:20:07 / # exit
从这个例子中可以看到，command的功能可以完成启动命令和传递参数的功能，但是pod中仍提供了一个args选项用于传递参数。这点和docker有些关系，kubernetes中的command、args两项其实是实现覆盖Dockerfile中的ENTRYPOINT的功能：
- 如果command和args均没有写，则用Dockerfile的配置
- 如果command写了，但args没有写，则Dockerfile的默认配置会被忽略，执行输入的command
- 如果command没写，但args写了，则Dockerfile中配置的ENTRYPOINT的命令会被执行，使用当前的args参数
- 如果command和args都写了，则Dockerfile的配置被忽略，执行command并追加上args参数
3.4. 环境变量
env主要用于传递container环境变量，主要格式是key-value 方式。生产环境使用较少，也并不推荐使用这种方式配置环境变量。下面仅举例：
创建pod-env.yaml：
$ cat yamls/pod-env.yaml apiVersion: v1 kind: Pod metadata: name: pod-command namespace: dev labels: user: zack spec: containers: - 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;"] env: - name: "username" value: "admin" - name: "password" value: "123"
部署后验证：
$ kubectl exec pod-command -it -n dev -- /bin/sh / # echo $username admin / # echo $password 123 / #
此方式配置环境并非推荐方式，推荐将这些配置单独存储在配置文件中。
3.5. 端口设置
ports支持的子选项：
$ kubectl explain pod.spec.containers.ports KIND: Pod VERSION: v1 RESOURCE: ports <[]Object> FIELDS: containerPort <integer> # 容器要监听的端口（0 < x < 65536） hostIP <string> # 要将外部端口绑定到的主机IP（一般省略） hostPort <integer> # 容器要在主机上公开的端口，如果设置，主机上只能运行容器的一个副本（一般省略） name <string> # 端口名称，如果指定，必须保证name在pod中是唯一的 protocol <string> # 端口协议。必须是UDP、TCP或SCTP，默认为TCP
创建 pod-ports.yaml：
$ cat yamls/pod-ports.yaml apiVersion: v1 kind: Pod metadata: name: pod-ports namespace: dev labels: user: zack spec: containers: - name: nginx image: nginx:1.17.1 imagePullPolicy: Always ports: - name: nginx-port containerPort: 80 protocol: TCP
$ kubectl apply -f yamls/pod-ports.yaml
pod/pod-ports created
这里是定义containerPort，要访问此服务，需要通过 Pod IP + Container 端口。
3.6. 资源配额
容器中的程序要运行，肯定是要占用一定的资源，比如cpu和内存等。如果不对某个容器的资源做限制，那么它可能会用掉大量资源，而导致其他containers无法运行。对于这种情况，kubernetes 提供了对内存和cpu的资源进行配额的机制。这种机制主要通过resources选项实现，有2个子选项：
- limits：用于限制运行时容器的最大占用资源，当容器占用资源超过limits时会被终止，并进行重启
- requests：用于设置容器需要的最小资源，如果环境资源不够，容器将无法启动
可以通过这两个选项分别设置资源的上下限。
如下pod-resources.yaml 所示的例子：
$ cat yamls/pod-resources.yaml apiVersion: v1 kind: Pod metadata: name: pod-resources namespace: dev spec: containers: - name: nginx image: nginx:1.17.1 resources: limits: cpu: "2" memory: "10Gi" requests: cpu: "1" memory: "10Mi"
这里对cpu和memory的单位做一个说明：
- cpu：core数，可以为整数或是小数
- memory：内存大小，可以使用Gi、Mi、G或M等形式
4. Pod 生命周期
我们将pod对象从创建至终的这段时间范围称为pod的生命周期，它主要包含以下过程：
- Pod创建过程
- 运行初始化容器（init container）过程
- 运行主容器（mian container）过程
- 容器启动后钩子（post start）、容器终止前钩子（pre stop）
- 容器的存活性探测（liveness probe）、就绪性探测（readiness probe）
- Pod终止过程
如下所示：
在整个生命周期中，pod会出现5种状态（相位）：
- 挂起（Pending）：apiserver已经创建了pod资源对象，但它尚未被调度完成或者仍处于下载镜像的过程中
- 运行中（Running）：pod已经被调度至某节点，并且所有容器都已经被kubelet创建完成
- 成功（Succeeded）：pod中的所有容器都已经成功终止，且不会被容器
- 失败（Failed）：所有容器都已经终止，但至少有一个容器终止失败，即容器返回了非0值的退出状态
- 未知（Unknown）：apiServer无法正常获取到pod对象的状态信息，通常由网络通信失败导致
4.1. Pod的创建与终止
Pod创建过程：
- 用户通过kubectl 或其他api客户端提交需要创建的pod信息给apiServer
- apiServer开始生成pod对象的信息，并将信息存入etcd，然后返回确认信息至客户端
- apiServer开始反映etcd中的pod对象的变化，其他组件使用watch机制来跟踪检查apiServer上的变动
- scheduler发现有新的pod对象要创建，开始为pod分配主机并将结果信息更新至apiServer
- node节点上的kubelet发现有pod调度过来，尝试调用docker启动容器，并将结果回送至apiServer
- apiServer将接收到的pod状态信息存入etcd中
整个过程中基本上是各个组件监听ApiServer的变动来触发自身的工作。例如scheduler 发现有新的pod要创建后，会分配主机并将结果信息更新给ApiServer。此时kubelet由于在watch ApiServer，所以会感知到这个变动，继而开始启动container，并将结果返回给ApiServer。
Pod的终止过程：
- 用户向apiServer发送删除pod对象的命令
- apiServer中的pod对象信息会随着时间的推移而更新，在宽限期内（默认30s），pod被视为dead
- 将pod标记为terminating状态
- kubelet 在监控到pod对象转为terminating状态的同时启动pod关闭过程
- 端点控制器监控到pod对象的关闭行为时将其从所有匹配到此端点的service资源的端点列表中移除
- 如果当前pod对象中定义了preStop钩子，则在其标记为terminating后即会以同步的方式启动执行
- Pod对象中的容器进程收到停止信号
- 宽限期结束后，若pod中还存在仍在运行的进程，那么pod对象会收到立即终止的信号
- kubelet请求apiServer将此pod资源的宽限期设置为0从而完成删除操作，此时pod对于用户已不可见
过程如下图所示：
4.2. 初始化容器
初始化容器是在pod的主容器启动之前要运行的容器，主要是做一些容器的前置工作，具有2大特征：
- 初始化容器必须运行完成至结束，若某初始化容器运行失败，那么kubernetes需要重启它直到成功完成
- 初始化容器必须按照定义的顺序执行，当且仅当一个成功后，后面的一个才能运行
初始化容器有很多的应用场景，常见的有：
- 提供主容器镜像中不具备的工具程序或自定义代码
- 初始化容器要先于应用容器串行启动并运行完成，因此可用于延后应用容器的启动直至其依赖的条件得到满足
假设有这么一个需求：要以主容器来运行nginx，但是要求在运行nginx之前要能够连接上mysql和redis所在的服务器。为了简化测试，ping的目标服务的地址为测试地址。
创建pod-initcontainer.yaml：
$ cat yamls/pod-initcontainer.yaml apiVersion: v1 kind: Pod metadata: name: pod-initcontainer namespace: dev spec: containers: - name: main-container image: nginx:1.17.1 ports: - name: nginx-port containerPort: 80 initContainers: - name: test-mysql image: busybox:1.30 command: ['/bin/sh', '-c', 'until ping 10.0.1.217 -c 1 ; do echo waiting for mysql...; sleep 2; done;'] - name: test-redis image: busybox:1.30 command: ['/bin/sh', '-c', 'until ping 10.0.1.217 -c 1 ; do echo waiting for mysql...; sleep 2; done;']
使用kubectl get pods -n dev -o wide -w 命令进行持续监控（-w 参数进行监控）：
$ kubectl get pods -n dev -o wide -w NAME READY STATUS RESTARTS AGE IP NODE nginx 1/1 Running 0 102m 10.0.1.84 ip-10-0-1-217.cn-north-1.compute.internal pod-initcontainer 0/1 Init:0/2 0 1s <none> ip-10-0-1-217.cn-north-1.compute.internal pod-initcontainer 0/1 Init:1/2 0 2s 10.0.1.31 ip-10-0-1-217.cn-north-1.compute.internal pod-initcontainer 0/1 PodInitializing 0 3s 10.0.1.31 ip-10-0-1-217.cn-north-1.compute.internal pod-initcontainer 1/1 Running 0 4s 10.0.1.31 ip-10-0-1-217.cn-north-1.compute.internal
可以看到在Init阶段启动了2个container，然后再启动的main container
4.3. 钩子函数
钩子函数能够感知自身生命周期中的事件，并在相应的时刻到来时运行用户指定的程序代码。
Kubernetes 在main container 的启动之后和停止之前提供了2个钩子函数：
- post start：容器创建之后执行，如果失败了会重启容器
- pre stop：容器终止之前执行，执行完成后容器将成功终止，在其完成之前会阻塞删除容器的操作
钩子处理器支持使用以下3种方式定义动作：
- Exec命令：在容器内执行1次命令
- TCPSocket：在当前容器尝试访问指定socket
- HTTPGet：在当前容器中向某url发起http请求
以exec方式举例：
$ cat yamls/pod-hook-exec.yaml apiVersion: v1 kind: Pod metadata: name: pod-hook-exec namespace: dev spec: containers: - name: main-container image: nginx:1.17.1 ports: - name: nginx-port containerPort: 80 lifecycle: postStart: exec: command: ["/bin/sh", "-c", "echo postStart... > /usr/share/nginx/html/index.html"] preStop: exec: command: ["/usr/sbin/nginx", "-s", "quit"]
# 验证： $ curl 10.0.1.45 postStart...
4.4. 容器探测
容器探测用于检测容器中的应用实例是否正常工作，是保障业务可用性的一种传统机制。如果经过探测，实例的状态不符合预期，那么kubernetes就会把问题实例“摘除”，不承担业务流量。Kubernetes提供了2种探针来实现容器探测，分别是：
- liveness probes：存活性探针，用于检测应用实例当前是否处于正常运行状态，如果不是k8s会重启容器
- readiness probes：就绪性探针，用于检测应用实例当前是否可以接收请求，如果不能，ks不会转发流量
livenessProbe决定是否重启容器，readinessProbe决定是否将请求转发给容器
上面2种探针均支持3种探测方式：
- Exec命令：在容器内执行1次命令，如果命令执行的退出码为0，则认为程序正常，否则不正常
- TCPSocket：将会尝试访问一个用户容器的端口，如果能够建立这条连接，则认为程序正常，否则不正常
- HTTPGet：调用容器内Web应用的URL，如果返回的状态码在200和399之间，则认为程序正常，否则不正常
以 liveness probe为例：
Exec方式：
$ cat yamls/pod-liveness-exec.yaml apiVersion: v1 kind: Pod metadata: name: pod-liveness-exec namespace: dev spec: containers: - name: main-container image: nginx:1.17.1 ports: - name: nginx-port containerPort: 80 livenessProbe: exec: command: ["/bin/cat", "/tmp/hello.txt"]
检查：
Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 70s default-scheduler Successfully assigned dev/pod-liveness-exec to ip-10-0-1-217.cn-north-1.compute.internal Normal Pulled 9s (x3 over 69s) kubelet Container image "nginx:1.17.1" already present on machine Normal Created 9s (x3 over 69s) kubelet Created container main-container Normal Started 9s (x3 over 69s) kubelet Started container main-container Warning Unhealthy 9s (x6 over 59s) kubelet Liveness probe failed: /bin/cat: /tmp/hello.txt: No such file or directory Normal Killing 9s (x2 over 39s) kubelet Container main-container failed liveness probe, will be restarted
可以看到main-container 的liveness probe 检测失败，会自动重启。也可以通过kubectl get 进行检查：
$ kubectl get pods -n dev -w NAME READY STATUS RESTARTS AGE pod-liveness-exec 1/1 Running 4 2m15s pod-liveness-exec 0/1 CrashLoopBackOff 4 2m32s pod-liveness-exec 1/1 Running 5 3m13s pod-liveness-exec 0/1 CrashLoopBackOff 5 3m41s …
livenessProbe 的子属性还有其他配置项，如下所示：
$ kubectl explain pod.spec.containers.livenessProbe KIND: Pod VERSION: v1 RESOURCE: livenessProbe <Object> FIELDS: exec <Object> failureThreshold <integer> # 连续探测失败多少次才被认定为失败。默认为3，最小为1 httpGet <Object> initialDelaySeconds <integer> # 容器启动后等待多少秒执行第1次探测 periodSeconds <integer> # 执行探测的频率。默认是10秒，最小1秒 successThreshold <integer> # 连续探测多少次才被认定成功。默认为3，最小为1 tcpSocket <Object> timeoutSeconds <integer> # 探测超时时间。默认1秒，最小1秒
4.5. 重启策略
在探测容器出现问题时，kubernetes会对容器所在的Pod进行重启，这是由pod的重启策略决定的，pod的重启策略有3种，分别为：
- Always：容器失效时，自动重启该容器；默认值
- OnFailure：容器终止运行且退出码不为0时重启
- Never：无论状态为何，都不重启该容器
重启策略适用于pod对象中所有的容器，首次需要重启的容器，将在其需要时立即进行重启，随后再次需要重启的操作将由kubelet延迟一段时间后进行。且反复重启操作的延时以10s、20s、40s、80s、160s和300s 进行递增。300s为最大延迟时长。
5. Pod 调度
默认情况下，一个Pod在哪个Node上运行，是由Scheduler组件采用相应的算法计算出来的，这个过程不受人工控制。不过在实际使用中，仍有需要控制Pod调度到某些节点。Kubernetes提供了4大类调度方式：
- 自动调度：运行在哪个节点上完全由Scheduler经过一系列的算法计算得出
- 定向调度：NodeName、NodeSelector
- 亲和性调度：NodeAffinity、PodAffinity、PodAntiAffinity
- 污点（容忍）调度：Taints、Toleration
5.1. 定向调度
定向调度，是指利用Pod上声明nodeName 或是nodeSelector的方式，将Pod调度到指定节点上。此方式是强制性的，也就是说，即使Node节点不存在，也会强行调度，只是pod运行会失败。
NodeName
强制约束将Pod调度到指定Name的Node节点上。此方式会直接跳过Scheduler的调度逻辑，直接将Pod调度到指定名称的节点。
例如：
$ cat yamls/pod-nodename.yaml apiVersion: v1 kind: Pod metadata: name: pod-nodename namespace: dev spec: containers: - name: nginx image: nginx:1.17.1 nodeName: ip-10-0-1-217.cn-north-1.compute.internal
$ kubectl get pods -n dev -o wide NAME READY STATUS RESTARTS AGE IP NODE pod-nodename 1/1 Running 0 10s 10.0.1.84 ip-10-0-1-217.cn-north-1.compute.internal
可以看到pod被调度到此node 上。
如果强制指定一个不存在的nodeName：
$ kubectl get pods -n dev -o wide NAME READY STATUS RESTARTS AGE IP NODE pod-nodename 0/1 Pending 0 9s <none> node1
NodeSelector
NodeSelector用于将pod调度到添加了指定标签的node节点上。它是通过kubernetes 的label-selection机制实现。也就是说，在pod创建之前，会由scheduler使用MatchNodeSelector调度策略进行label匹配，找到目标node进行调度。该匹配规则是强制约束。
例如：
# 给node打标签 $ kubectl label node ip-10-0-1-217.cn-north-1.compute.internal nodeenv=pro node/ip-10-0-1-217.cn-north-1.compute.internal labeled $ cat yamls/pod-nodelabel.yaml apiVersion: v1 kind: Pod metadata: name: pod-nodename namespace: dev spec: containers: - name: nginx image: nginx:1.17.1 nodeSelector: nodeenv: pro $ kubectl apply -f yamls/pod-nodelabel.yaml pod/pod-nodename created $ kubectl get pods -n dev -o wide NAME READY STATUS RESTARTS AGE IP NODE pod-nodename 1/1 Running 0 18s 10.0.1.216 ip-10-0-1-217.cn-north-1.compute.internal
5.2. 亲和性调度
在强制调度下，如果没有符合条件的节点，pod就会pending，无法正常运行。所以kubernetes还提供了一种亲和性调度（Affinity）。它在NodeSelector的基础上进行了扩展，可以通过配置的方式，实现优先选择满足条件的Node进行调度。如果没有合适节点，则也可以调度到不满足条件的节点上，使调度更加灵活。
Affinity主要分为3类：
- nodeAffinity（node亲和性）：以node为目标，解决pod可以调度到哪些node的问题
- podAffinity（pod亲和性）：以pod为目标，解决pod可以和哪些已存在的pod部署在同一个拓扑域中的问题
- podAntiAffinity（pod反亲和性）：以pod为目标，解决pod不能和哪些已存在pod部署在同一个拓扑域中的问题
关于亲和性（与反亲和性）使用场景的说明：
- 亲和性：如果2个应用频繁交互，那就有必要利用亲和性让2个应用尽可能地靠近，这样可以减少因网络通信而带来的性能损耗
- 反亲和性：当应用采用多副本部署时，有必要采用反亲和性让各个应用实例打散分布在各个node上，这样可以提高服务的高可用性
nodeAffinity亲和性配置：
pod.spec.affinity.nodeAffinity requiredDuringSchedulingIgnoredDuringExecution # Node 节点必须满足指定所有规则才可以，相当于硬限制 nodeSelectorTerms 节点选择列表 matchFields 按节点字段列出的节点选择器要求列表 matchExpression 按节点标签列出的节点选择器要求列表（推荐） key value operator 关系符，支持Exists、DoesNotExists、In、NotIn、Gt、Lt preferredDuringSchedulingIgnoredDuringExecution # 优先调度到满足指定规则的Node，相当于软限制（倾向） preference 一个节点选择器项，与相应的权重相关联 matchFields 按节点字段列出的节点选择器要求列表 matchExpression 按节点标签列出的节点选择器要求列表（推荐） key value operator 关系符，支持Exists、DoesNotExists、In、NotIn、Gt、Lt weight 倾向权重，范围1-100
关系符的使用说明：
- matchExpressions: - key: nodeenv # 匹配存在标签的key为nodeenv的节点 operator: Exitsts - key: nodeenv # 匹配标签的key为nodeenv，且value是xxx或yyy的节点 operator: In values: ["xxx", "yyy"] - key: nodeenv # 匹配标签的key 为nodeenv，且value大于xxx的节点 operator: Gt values: "xxx"
requiredDuringSchedulingIgnoredDuringExecution
下面演示requiredDuringSchedulingIgnoredDuringExecution
$ cat yamls/pod-nodeaffinity-required.yaml apiVersion: v1 kind: Pod metadata: name: pod-nodeaffinity-required namespace: dev spec: containers: - name: nginx image: nginx:1.17.1 affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: nodeenv operator: In values: ["xxx", "yyy"]
在部署后，可以看到Pod 是pending状态。原因是：
Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning FailedScheduling 33s (x4 over 3m28s) default-scheduler 0/2 nodes are available: 2 node(s) didn't match node selector.
由于没有label符合条件，所以pod无法正常启动。使用能启动的方式：
#为节点打上标签 kubectl label nodes ip-10-0-1-217.cn-north-1.compute.internal nodeenv=pro # 修改调度策略 - matchExpressions: - key: nodeenv operator: In values: ["pro", "yyy"] # 可以正常启动 $ kubectl get pods -n dev NAME READY STATUS RESTARTS AGE pod-nodeaffinity-required 1/1 Running 0 14s
preferredDuringSchedulingIgnoredDuringExecution
$ cat yamls/pod-nodeaffinity-preferred.yaml apiVersion: v1 kind: Pod metadata: name: pod-nodeaffinity-preferred namespace: dev spec: containers: - name: nginx image: nginx:1.17.1 affinity: nodeAffinity: preferredDuringSchedulingIgnoredDuringExecution: - weight: 1 preference: matchExpressions: - key: nodeenv operator: In values: ["xxx", "yyy"]
由于是软限制，所以pod能正常启动：
$ kubectl get pods -n dev NAME READY STATUS RESTARTS AGE pod-nodeaffinity-preferred 1/1 Running 0 27s
NodeAffinity规则设置的注意事项：
- 如果同时定义了nodeSelector和nodeAffinity，那么必须2个条件都得到满足，Pod才能运行在指定的Node上
- 如果nodeAffinity指定了多个nodeSelectorTerms，则只需匹配到其中1个成功即可
- 如果一个nodeSelectorTerms中有多个matchExpressions，则1个节点必须满足所有条件才能匹配成功
- 如果一个pod所在的Node在Pod运行期间标签发生了改变，不再符合该Pod的节点亲和性需求，则系统将忽略此变化
PodAffinity
以正在运行的pod作为参照，决定新pod的调度。
PodAffinity的可配置项：
$ kubectl explain pod.spec.affinity.podAffinity KIND: Pod VERSION: v1 RESOURCE: podAffinity <Object> FIELDS: requiredDuringSchedulingIgnoredDuringExecution <[]Object> # 硬限制 namespaces # 指定参照pod的namespace topologyKey # 指定调度作用域 labelSelector # 标签选择器 matchExpressions # 按节点标签列出节点选择器要求列表（推荐） key value operator # 关系符，支持In、NotIn、Exists、DoesNotExist matchLabels # 指多个matchExpression 映射的内容 preferredDuringSchedulingIgnoredDuringExecution <[]Object> # 软限制 namespaces # 指定参照pod的namespace topologyKey # 指定调度作用域 labelSelector # 标签选择器 matchExpressions # 按节点标签列出节点选择器要求列表（推荐） key value operator # 关系符，支持In、NotIn、Exists、DoesNotExist matchLabels # 指多个matchExpression 映射的内容 weight # 倾向权重，范围为1-100
topologyKey 用于指定调度时作用域，例如：
- 如果指定为kubernetes.io/hostname，那就是以Node节点为区分范围
- 如果指定为beta.kubernetes.io/os 则以Node节点的操作系统类型来区分
演示requiredDuringSchedulingIgnoredDuringExecution
# 首先启动一个目标pod $ kubectl get pods -n dev -o wide --show-labels NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES LABELS nginx 1/1 Running 0 111s 10.0.2.186 ip-10-0-2-30.cn-north-1.compute.internal <none> <none> tier=production,version=3.0
$ cat yamls/pod-podaffinity-required.yaml apiVersion: v1 kind: Pod metadata: name: pod-podaffinity-required namespace: dev spec: containers: - name: nginx image: nginx:1.17.1 affinity: podAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: tier operator: In values: ["production", "yyy"] topologyKey: kubernetes.io/hostname
成功启动，可以看到调度到了与target pod同一节点：
$ kubectl get pods -n dev -o wide --show-labels NAME READY STATUS RESTARTS AGE IP NODE LABELS nginx 1/1 Running 0 12m 10.0.2.186 ip-10-0-2-30.cn-north-1.compute.internal tier=production,version=3.0 pod-podaffinity-required 1/1 Running 0 46s 10.0.2.124 ip-10-0-2-30.cn-north-1.compute.internal <none>
Pod反亲和性
$ cat yamls/pod-podantiaffinity-required.yaml apiVersion: v1 kind: Pod metadata: name: pod-podantiaffinity-required namespace: dev spec: containers: - name: nginx image: nginx:1.17.1 affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: tier operator: In values: ["production", "yyy"] topologyKey: kubernetes.io/hostname
成功启动，可以看到调度到了与target node 不同的节点上：
$ kubectl get pods -n dev -o wide NAME READY STATUS RESTARTS AGE IP NODE GATES nginx 1/1 Running 0 28m 10.0.2.186 ip-10-0-2-30.cn-north-1.compute.internal pod-podantiaffinity-required 1/1 Running 0 12s 10.0.1.216 ip-10-0-1-217.cn-north-1.compute.internal
5.3. 污点和容忍
污点（Tiants）
可以通过在Node上添加污点属性，来决定是否允许Pod调度过来。
Node在被设置上污点之后，就和Pod之间存在了一种相斥的关系，进而拒绝Pod调度进来，甚至可以将已经存在的Pod驱逐出去。
污点的格式为：key=value:effect。Key和value是污点的标签，effect描述污点的作用，支持如下3个选项：
- PreferNoSchedule：kubernetes将尽量避免把Pod调度到具有该污点的Node上，除非没有其他节点可调度
- NoSchedule：kubernetes将不会把Pod调度到具有该污点的Node上，但不会影响当前Node上已存在的Pod
- NoExecute：kubernetes将不会把Pod调度到具有该污点的Node上，同时也会将Node上已存在的Pod驱离
设置&去除污点的常规写法：
# 设置污点 kubectl taint nodes node1 key=value:effect # 去除污点 kubectl taint nodes node1 key:effect- # 去除所有污点 kubectl taint nodes node1 key-
演示：
# 为节点设置污点： $ kubectl taint nodes ip-10-0-2-30.cn-north-1.compute.internal tag=wever:PreferNoSchedule # 启动pod 后的结果： $ kubectl get pods -n dev -o wide NAME READY STATUS RESTARTS AGE IP NODE nginx 1/1 Running 0 2d19h 10.0.2.186 ip-10-0-2-30.cn-north-1.compute.internal taint1 1/1 Running 0 15s 10.0.1.216 ip-10-0-1-217.cn-north-1.compute.internal taint2 1/1 Running 0 8s 10.0.1.84 ip-10-0-1-217.cn-north-1.compute.internal # 去除污点，并设置NoExcuete级别： $ kubectl taint nodes ip-10-0-2-30.cn-north-1.compute.internal tag=wever:PreferNoSchedule- node/ip-10-0-2-30.cn-north-1.compute.internal untainted $ kubectl get pods -n dev -o wide NAME READY STATUS RESTARTS AGE IP NODE nginx 0/1 Terminating 0 2d20h 10.0.2.186 ip-10-0-2-30.cn-north-1.compute.internal taint1 1/1 Running 0 9m27s 10.0.1.216 ip-10-0-1-217.cn-north-1.compute.internal taint2 1/1 Running 0 9m20s 10.0.1.84 ip-10-0-1-217.cn-north-1.compute.internal => 可以看到此节点上的pod立即开始关闭
对于master节点，默认打了NoSchedule级别污点，所以不会调度pods在master节点上。
容忍（Toleration）
在node上可以通过污点来拒绝pod调度上来。但是如果想将一个pod调度到一个有污点的node上，仍可以通过容忍的机制实现。如下图所示：
污点就是拒绝，容忍就是忽略。Node通过污点拒绝pod调度上去，Pod通过容忍忽略拒绝。
演示：
# 给pod打上NoExecute污点 $ kubectl taint nodes ip-10-0-2-30.cn-north-1.compute.internal tag=wever:NoExecute node/ip-10-0-2-30.cn-north-1.compute.internal tainted # 创建pod定义 $ cat yamls/pod-toleration.yaml apiVersion: v1 kind: Pod metadata: namespace: dev name: pod-toleration spec: containers: - name: nginx image: nginx:1.17.1 tolerations: # 添加容忍 - key: "tag" # 要容忍的污点key operator: "Equal" # 操作符 value: "wever" # 容忍的污点value effect: "NoExcude" # 添加容忍的规则，这里必须和标记的污点规则相同 # 可以看到pod被正常调度到NoExecute节点 $ kubectl get pods -n dev -o wide NAME READY STATUS RESTARTS AGE IP NODE pod-toleration 1/1 Running 0 37s 10.0.2.186 ip-10-0-2-30.cn-north-1.compute.internal taint2 1/1 Running 0 24m 10.0.1.84 ip-10-0-1-217.cn-north-1.compute.internal