Kubernetes（四）Pod详解

Pod详解

本章主要介绍Pod资源的各种配置（yaml文件）和原理

1. Pod介绍

如上图所示，每个Pod中都可以包含一个或多个Container，这些Containers 可以分为2类：

1. 用户程序所在的Container，数量可多可少
2. 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：

1. nginx：用1.17.1版本的nginx创建镜像
2. 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的功能：

1. 如果command和args均没有写，则用Dockerfile的配置
2. 如果command写了，但args没有写，则Dockerfile的默认配置会被忽略，执行输入的command
3. 如果command没写，但args写了，则Dockerfile中配置的ENTRYPOINT的命令会被执行，使用当前的args参数
4. 如果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个子选项：

1. limits：用于限制运行时容器的最大占用资源，当容器占用资源超过limits时会被终止，并进行重启
2. 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的单位做一个说明：

1. cpu：core数，可以为整数或是小数
2. memory：内存大小，可以使用Gi、Mi、G或M等形式

4. Pod 生命周期

我们将pod对象从创建至终的这段时间范围称为pod的生命周期，它主要包含以下过程：

1. Pod创建过程
2. 运行初始化容器（init container）过程
3. 运行主容器（mian container）过程
   • 容器启动后钩子（post start）、容器终止前钩子（pre stop）
   • 容器的存活性探测（liveness probe）、就绪性探测（readiness probe）
4. Pod终止过程

如下所示：

在整个生命周期中，pod会出现5种状态（相位）：

1. 挂起（Pending）：apiserver已经创建了pod资源对象，但它尚未被调度完成或者仍处于下载镜像的过程中
2. 运行中（Running）：pod已经被调度至某节点，并且所有容器都已经被kubelet创建完成
3. 成功（Succeeded）：pod中的所有容器都已经成功终止，且不会被容器
4. 失败（Failed）：所有容器都已经终止，但至少有一个容器终止失败，即容器返回了非0值的退出状态
5. 未知（Unknown）：apiServer无法正常获取到pod对象的状态信息，通常由网络通信失败导致

4.1. Pod的创建与终止

Pod创建过程：

1. 用户通过kubectl 或其他api客户端提交需要创建的pod信息给apiServer
2. apiServer开始生成pod对象的信息，并将信息存入etcd，然后返回确认信息至客户端
3. apiServer开始反映etcd中的pod对象的变化，其他组件使用watch机制来跟踪检查apiServer上的变动
4. scheduler发现有新的pod对象要创建，开始为pod分配主机并将结果信息更新至apiServer
5. node节点上的kubelet发现有pod调度过来，尝试调用docker启动容器，并将结果回送至apiServer
6. apiServer将接收到的pod状态信息存入etcd中

整个过程中基本上是各个组件监听ApiServer的变动来触发自身的工作。例如scheduler 发现有新的pod要创建后，会分配主机并将结果信息更新给ApiServer。此时kubelet由于在watch ApiServer，所以会感知到这个变动，继而开始启动container，并将结果返回给ApiServer。

Pod的终止过程：

1. 用户向apiServer发送删除pod对象的命令
2. apiServer中的pod对象信息会随着时间的推移而更新，在宽限期内（默认30s），pod被视为dead
3. 将pod标记为terminating状态
4. kubelet 在监控到pod对象转为terminating状态的同时启动pod关闭过程
5. 端点控制器监控到pod对象的关闭行为时将其从所有匹配到此端点的service资源的端点列表中移除
6. 如果当前pod对象中定义了preStop钩子，则在其标记为terminating后即会以同步的方式启动执行
7. Pod对象中的容器进程收到停止信号
8. 宽限期结束后，若pod中还存在仍在运行的进程，那么pod对象会收到立即终止的信号
9. kubelet请求apiServer将此pod资源的宽限期设置为0从而完成删除操作，此时pod对于用户已不可见

过程如下图所示：

4.2. 初始化容器

初始化容器是在pod的主容器启动之前要运行的容器，主要是做一些容器的前置工作，具有2大特征：

1. 初始化容器必须运行完成至结束，若某初始化容器运行失败，那么kubernetes需要重启它直到成功完成
2. 初始化容器必须按照定义的顺序执行，当且仅当一个成功后，后面的一个才能运行

初始化容器有很多的应用场景，常见的有：

1. 提供主容器镜像中不具备的工具程序或自定义代码
2. 初始化容器要先于应用容器串行启动并运行完成，因此可用于延后应用容器的启动直至其依赖的条件得到满足

假设有这么一个需求：要以主容器来运行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个钩子函数：

1. post start：容器创建之后执行，如果失败了会重启容器
2. pre stop：容器终止之前执行，执行完成后容器将成功终止，在其完成之前会阻塞删除容器的操作

钩子处理器支持使用以下3种方式定义动作：

1. Exec命令：在容器内执行1次命令
2. TCPSocket：在当前容器尝试访问指定socket
3. 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种探针来实现容器探测，分别是：

1. liveness probes：存活性探针，用于检测应用实例当前是否处于正常运行状态，如果不是k8s会重启容器
2. readiness probes：就绪性探针，用于检测应用实例当前是否可以接收请求，如果不能，ks不会转发流量

livenessProbe决定是否重启容器，readinessProbe决定是否将请求转发给容器

上面2种探针均支持3种探测方式：

1. Exec命令：在容器内执行1次命令，如果命令执行的退出码为0，则认为程序正常，否则不正常
2. TCPSocket：将会尝试访问一个用户容器的端口，如果能够建立这条连接，则认为程序正常，否则不正常
3. 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种，分别为：

1. Always：容器失效时，自动重启该容器；默认值
2. OnFailure：容器终止运行且退出码不为0时重启
3. Never：无论状态为何，都不重启该容器

重启策略适用于pod对象中所有的容器，首次需要重启的容器，将在其需要时立即进行重启，随后再次需要重启的操作将由kubelet延迟一段时间后进行。且反复重启操作的延时以10s、20s、40s、80s、160s和300s 进行递增。300s为最大延迟时长。

5. Pod 调度

默认情况下，一个Pod在哪个Node上运行，是由Scheduler组件采用相应的算法计算出来的，这个过程不受人工控制。不过在实际使用中，仍有需要控制Pod调度到某些节点。Kubernetes提供了4大类调度方式：

1. 自动调度：运行在哪个节点上完全由Scheduler经过一系列的算法计算得出
2. 定向调度：NodeName、NodeSelector
3. 亲和性调度：NodeAffinity、PodAffinity、PodAntiAffinity
4. 污点（容忍）调度：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类：

1. nodeAffinity（node亲和性）：以node为目标，解决pod可以调度到哪些node的问题
2. podAffinity（pod亲和性）：以pod为目标，解决pod可以和哪些已存在的pod部署在同一个拓扑域中的问题
3. 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规则设置的注意事项：

1. 如果同时定义了nodeSelector和nodeAffinity，那么必须2个条件都得到满足，Pod才能运行在指定的Node上
2. 如果nodeAffinity指定了多个nodeSelectorTerms，则只需匹配到其中1个成功即可
3. 如果一个nodeSelectorTerms中有多个matchExpressions，则1个节点必须满足所有条件才能匹配成功
4. 如果一个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 用于指定调度时作用域，例如：

1. 如果指定为kubernetes.io/hostname，那就是以Node节点为区分范围
2. 如果指定为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个选项：

1. PreferNoSchedule：kubernetes将尽量避免把Pod调度到具有该污点的Node上，除非没有其他节点可调度
2. NoSchedule：kubernetes将不会把Pod调度到具有该污点的Node上，但不会影响当前Node上已存在的Pod
3. 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