Hedon

# Pod

Pod 是可以在 Kubernetes 中创建和管理的、最小的可部署的计算单元。

# 一、Pod 简介

# 1. Pod 结构

image-20210705093808217

每个Pod中都包含一个或者多个容器，这些容器可以分为两类：

  • 用户程序所在的容器，数量可多可少

  • Pause 容器，这是每个 Pod 都会有的一个根容器，它的作用有两个：

    • 可以以它为依据，评估整个 Pod 的健康状况。

    • 可以在根容器上设置 IP 地址，其它容器都共享此 IP（Pod 的 IP），以实现Pod内部的网络通信

      这里是 Pod 内部的通讯。

      Pod 之间的通讯采用虚拟二层网络技术来实现，我们当前环境使用的是 Flannel。

# 2. Pod 模板

apiVersion: v1     #必选，版本号，例如v1
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: string

❓记不住怎么办？

# 查看某种资源可以配置的一级配置
kubectl explain 资源类型 
# 查看属性的子属性
kubectl explain 资源类型.属性

示例：查看资源类型为 pod 的可配置项

[root@k8s-master ~]# kubectl explain pod
KIND:     Pod
VERSION:  v1

DESCRIPTION:
     Pod is a collection of containers that can run on a host. This resource is
     created by clients and scheduled onto hosts.

FIELDS:
   apiVersion	<string>
   kind	<string>
   metadata	<Object>
   spec	<Object>
   status	<Object>

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，表示使用宿主机网络。
  • volumes <[]Object> ：存储卷，用于定义 Pod 上面挂载的存储信息。
  • restartPolicy <string>：重启策略，表示 Pod 在遇到故障的时候的处理策略。

# 二、查看 Pod

# 1. 查看所有 Pod

kubectl get pods

# 2. 查看指定的 Pod

kubectl get pods podName

# 3. 查看指定 namespace 的 Pod

kubectl get pods -n ns名称

# 4. 查看 Pod 详细信息

kubectl describe pods [podName] [-n ns名称]

# 三、运行 Pod

Kubernetes 没有提供单独运行 Pod 的命令，都是通过 Pod 的控制器来实现的。

kubectl run [pod控制层名称] [参数]

参数：

  • --image：指定 Pod 的镜像
  • --port：指定端口
  • --namespace：指定 namespace

举例：

[root@k8s-master ~]# kubectl run nginx --image=nginx:1.17.1 --port=80 --namespace=dev
pod/nginx created

# 四、访问 Pod

  • 获取 Pod 的 IP

    [root@k8s-master ~]# kubectl get pods -n dev -o wide
NAME    READY   STATUS    RESTARTS   AGE   IP           NODE        NOMINATED NODE   READINESS GATES
nginx   1/1     Running   0          81s   10.244.1.3   k8s-node1   <none>           <none>

  • 访问 Pod

    curl 10.244.1.3:80

# 五、创建 Pod

前面「运行 Pod」 的时候就是创建 Pod 的一种方式。

另外一种是通过配置文件来创建的：

kubectl create -f 配置文件路径

# 六、删除 Pod

# 1. 通过命令行删除

kubectl delete pod [pod名称] [-n 命名空间]

删除 Pod，可以直接删除 Pod，也可以直接删除 Pod 对应的控制器。

# 2. 通过配置文件删除

kubectl delete pod -f 配置文件路径

# 七、Pod 配置

本小节主要来研究 pod.spec.containers 属性，这也是 Pod 配置中最为关键的一项配置。

# 1. 查看配置项

[root@k8s-master ~]# kubectl explain pod.spec.containers
# 下面只展现出重要属性
KIND:     Pod
VERSION:  v1
RESOURCE: containers <[]Object>   # 数组，代表可以有多个容器 FIELDS:
  - name  <string>     # 容器名称
    image <string>     # 容器需要的镜像地址
    imagePullPolicy  <string> # 镜像拉取策略 
    command  <[]string> # 容器的启动命令列表，如不指定，使用打包时使用的启动命令
    args   <[]string> # 容器的启动命令需要的参数列表 
    env    <[]Object> # 容器环境变量的配置
    ports  <[]Object>  # 容器需要暴露的端口号列表
    resources <Object> # 资源限制和资源请求的设置

# 2. 基本配置

  • 创建一个 pod-base.yaml 文件，内容如下

    apiVersion: v1
kind: Pod
metadata:
	name: pod-base
	namespace: default
	labels:
		user: hedon
spec:
	containers:
	- name: nginx #容器名称
	  image: nginx:1.17.1 #镜像名称
	- name: busybox
    image: busybox:1.30

    上面定义了一个比较简单的 Pod 的配置，里面有两个容器：

    • nginx：用的是 1.17.1 版本的 nginx 镜像创建（nginx 是一个轻量级的 web 容器）。

    • busybox：用的是 1.30 版本的 busybo 镜像创建（busybox 是一个小巧的 linux 命令集合）。

  • 创建 Pod

    [root@k8s-master pod]# kubectl apply -f pod-base.yaml 
pod/pod-base created

  • 查看 Pod 状况

    [root@k8s-master pod]# kubectl get pod pod-base
NAME       READY   STATUS             RESTARTS   AGE
pod-base   1/2     CrashLoopBackOff   2          77s

    我们会发现它已经起来了，但是有问题。

  • 查看 Pod 详情

    [root@k8s-master pod]# kubectl describe pod pod-base
Events:
  Type     Reason     Age              From                Message
  ----     ------     ----             ----                -------
  Normal   Scheduled  <unknown>        default-scheduler   Successfully assigned default/pod-base to k8s-node1
  Normal   Pulled     86s              kubelet, k8s-node1  Container image "nginx:1.17.1" already present on machine
  Normal   Created    86s              kubelet, k8s-node1  Created container nginx
  Normal   Started    85s              kubelet, k8s-node1  Started container nginx
  Normal   Pulling    85s              kubelet, k8s-node1  Pulling image "busybox:1.30"
  Normal   Pulled     9s               kubelet, k8s-node1  Successfully pulled image "busybox:1.30"
  Normal   Created    8s (x2 over 9s)  kubelet, k8s-node1  Created container busybox
  Normal   Started    8s (x2 over 9s)  kubelet, k8s-node1  Started container busybox
  Normal   Pulled     8s               kubelet, k8s-node1  Container image "busybox:1.30" already present on machine
  Warning  BackOff    6s (x2 over 7s)  kubelet, k8s-node1  Back-off restarting failed container

# 3. 镜像拉取策略

imagePullPolicy：用于设置镜像拉取的策略。

k8s 支持配置三种拉取策略：

  • Always：总是从远程仓库拉取镜像
  • IfNotPresent：本地有则使用本地镜像，本地没有则从远程仓库拉取镜像
  • Never：只使用本地镜像，从不去远程仓库拉取，本地没有就报错

默认值说明：

  • 如果镜像 tag 为具体的版本号，默认策略是 IfNotPresent
  • 如果镜像 tag 为 latest（最终版本），默认策略是 Always

# 4. 启动命令

command：用于在Pod中的容器初始化完毕之后执行一个命令。

在前面的案例中，一直有一个问题没有解决，就是 busybox 容器一直没有成功运行，那么到底是什么原因导致这个容器的故障的呢？

  • 原来 busybox 并不是一个程序，而是类似于一个工具类的集合，k8s 集群启动管理后，它会自动关闭。解决方法就是让其一直在运行，这就用到了 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;"]
  • "/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 秒，向文件写入当前时间

特别说明：通过上面发现 command 已经可以完成启动命令和传递参数的功能，为什么还要提供一个 args 选项，用于传递参数？

其实和 Docker 有点关系，k8s 中的 command 和 args 两个参数其实是为了实现覆盖 Dockerfile 中的 ENTRYPOINT 的功能：

  • 如果 command 和 args 均没有写，那么用 Dockerfile 的配置。
  • 如果 command 写了，但是 args 没有写，那么 Dockerfile 默认的配置会被忽略，执行注入的 command。
  • 如果 command 没有写，但是 args 写了，那么 Dockerfile 中配置的 ENTRYPOINT 命令会被执行，使用当前 args 的参数。
  • 如果 command 和 args 都写了，那么 Dockerfile 中的配置会被忽略，执行 command 并追加上 args 参数。

一句话：command 和 args 优先于 Dockerfile。

# 5. 环境变量

env：环境变量，用于在 Pod 中的容器设置环境变量。

apiVersion: v1
kind: Pod
metadata:
  name: pod-env
  labels:
    user: hedon
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: "123456"

进入容器查看环境变量：

[root@k8s-master pod]# kubectl exec pod-env -c busybox -it /bin/sh
kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl kubectl exec [POD] -- [COMMAND] instead.
/ # echo $username
admin
/ # echo $password
123456
/ # exit

语法：

kubectl exec pod名称 [-n 命名空间] -c 容器名称 -it /bin/sh
  • exec：执行命令
  • -n：指定命名空间，默认为 default
  • -c：指定容器名称
  • -it：前台交互运行
  • /bin/sh：进入容器后要执行的命令

# 6. 端口设置

ports：配置容器的端口信息。

[root@k8s-master pod]# kubectl explain pod.spec.containers.ports
FIELDS:
  name <string> # 端口名称，如果指定，必须保证 name 在 pod 中是唯一的
  containerPort <integer> # 容器要监听的端口(0<x<65536)
  hostPort <integer> # 容器要在主机上公开的端口，如果设置，主机上只能运行容器的一个副本(一般省略）
  hostIP <string>  # 要将外部端口绑定到的主机IP(一般省略)
  protocol <string>  # 端口协议。必须是UDP、TCP或SCTP。默认为“TCP”
  • 访问Pod中的容器中的程序使用的是 PodIp:containerPort
image-20210705104412416

# 7. 资源配额

容器中的程序要运行，肯定会占用一定的资源，比如 CPU 和内存等，如果不对某个容器的资源做限制，那么它就可能吃掉大量的资源，导致其他的容器无法运行。针对这种情况，k8s 提供了对内存和 CPU 的资源进行配额的机制，这种机制主要通过 resources 选项实现，它有两个子选项：

  • limits：用于限制运行的容器的最大占用资源，当容器占用资源超过 limits 时会被终止，并进行重启。
  • requests：用于设置容器需要的最小资源，如果环境资源不够，容器将无法启动。
apiVersion: v1
kind: Pod
metadata:
  name: pod-resoures
  namespace: dev
  labels:
    user: xudaxian
spec:
  containers:
    - name: nginx # 容器名称
      image: nginx:1.17.1 # 容器需要的镜像地址
      imagePullPolicy: IfNotPresent # 设置镜像拉取策略
      ports: # 端口设置
        - name: nginx-port # 端口名称，如果执行，必须保证name在Pod中是唯一的
          containerPort: 80 # 容器要监听的端口 （0~65536）
          protocol: TCP # 端口协议
      resources: # 资源配额
        limits: # 限制资源的上限
          cpu: "2" # CPU限制，单位是core数
          memory: "10Gi" # 内存限制
        requests: # 限制资源的下限
          cpu: "1" # CPU限制，单位是core数 
          memory: "10Mi" # 内存限制
  • cpu：core 数，可以为整数或小数
  • memory：内存大小，可以使用 Gi、Mi、G、M 等形式

# 八、Pod 生命周期

我们一般将 Pod 对象从创建到终止的这段时间范围称为 Pod 的生命周期，它主要包含下面的过程：

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

# 1. Pod 阶段

取值 描述
Pending（悬决） Pod 已被 Kubernetes 系统接受，但有一个或者多个容器尚未创建亦未运行。此阶段包括等待 Pod 被调度的时间和通过网络下载镜像的时间。
Running（运行中） Pod 已经绑定到了某个节点，Pod 中所有的容器都已被创建。至少有一个容器仍在运行，或者正处于启动或重启状态。
Succeeded（成功） Pod 中的所有容器都已成功终止，并且不会再重启。
Failed（失败） Pod 中的所有容器都已终止，并且至少有一个容器是因为失败终止。也就是说，容器以非 0 状态退出或者被系统终止。
Unknown（未知） 因为某些原因无法取得 Pod 的状态。这种情况通常是因为与 Pod 所在主机通信失败。

如果某节点死掉或者与集群中其他节点失联，Kubernetes 会实施一种策略，将失去的节点上运行的所有 Pod 的 phase 设置为 Failed。

# 2. Pod 状况

Pod 有一个 PodStatus 对象，其中包含一个 PodConditions (opens new window) 数组。Pod 可能通过也可能未通过其中的一些状况测试。

  • PodScheduled：Pod 已经被调度到某节点；
  • ContainersReady：Pod 中所有容器都已就绪；
  • Initialized：所有的 Init 容器 (opens new window) 都已成功启动；
  • Ready：Pod 可以为请求提供服务，并且应该被添加到对应服务的负载均衡池中。
字段名称 描述
type Pod 状况的名称
status 表明该状况是否适用，可能的取值有 "True", "False" 或 "Unknown"
lastProbeTime 上次探测 Pod 状况时的时间戳
lastTransitionTime Pod 上次从一种状态转换到另一种状态时的时间戳
reason 机器可读的、驼峰编码（UpperCamelCase）的文字，表述上次状况变化的原因
message 人类可读的消息，给出上次状态转换的详细信息

# 3. 容器状态

一旦 Kube Scheduler 将 Pod 分派给某个节点，kubelet 就通过 Container Runtime 开始为 Pod 创建容器。

容器的状态有三种：

  • Waiting（等待）
  • Running（运行中）
  • Terminated（已终止）

# 4. Pod 创建

  1. 用户通过 kubectl 或其他的 API 客户端提交需要创建的 Pod 信息给 API Server

  2. API Server 开始生成 Pod 对象的信息，并将信息存入 etcd，然后返回确认信息至客户端

  3. API Server 开始反映 etcd 中的 Pod 对象的变化，其它组件使用 watch 机制来跟踪检查 API Server上 的变动

    3.1 Scheduler 发现有新的 Pod 对象要创建，开始为 Pod 分配主机并将结果信息更新至 API Server

    3.2 Node 节点上的 kubelet 发现有 Pod 调度过来，尝试调度 Docker 启动容器，并将结果回送至 API Server

  4. API Server 将接收到的 Pod 状态信息存入到 etcd 中

image-20210705112122258

# 5. Pod 终止

  1. 用户向 API Server 发送删除 Pod 对象的命令
  2. API Server 中的 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. kubectl 请求 API Server 将此 Pod 资源的宽限期设置为 0 从而完成删除操作，此时Pod对于用户已经不可用了

# 6. init 容器

init 容器是在 Pod 的主容器启动之前要运行的容器，主要是做一些主容器的前置工作，它具有两大特征：

  • 必须成功：初始化容器必须运行完成直至结束，如果某个初始化容器运行失败，那么 k8s 需要重启它直至成功完成
  • 顺序执行：初始化容器必须按照定义的顺序执行，当且仅当前一个成功之后，后面的一个才能运行

init 容器有很多的应用场景，下面列出的是最常见的几个：

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

下面做一个案例，来感受一下 init 容器的作用。

  • 假设要以主容器来运行 Nginx，但是要求在运行 Nginx 之前要能够连接上 MySQL 和 Redis 所在的服务器
  • 为了简化测试，事先规定好 MySQL 和 Redis 所在的 IP 地址分别为 172.16.58.203 和 172.16.58.204，能 ping 通就表示我们能连接上。

6.1 创建 pod-initcontainer.yaml 文件

apiVersion: v1
kind: Pod
metadata:
	name: pod-initcontainer
	labels:
		user: hedon
spec:
	containers:
		- name: nginx
			image: nginx:1.17.1
			imagePullPolicy: IfNotPresent
			ports:
				- name: nginx-port
					containerPort: 80
					protocol: TCP
			resources:
				limits:
					cpu: "2"
					memory: "10Gi"
				requests:
					cpu: "1"
					memory: "10Mi"
	initContainers:  # init 容器配置：跟 containers 平级
		- name: test-mysql
			image: busybox:1.30
			command: ["sh","-c","until ping 172.16.58.203 -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 172.16.58.204 -c 1;do echo waiting for redis ....;sleep 2;done;"]

6.2 创建 Pod

[root@k8s-master pod]# kubectl apply -f pod-initconatiner.yaml 
pod/pod-initcontainer created

6.3 查看 Pod 状态

[root@k8s-master pod]# kubectl get pod pod-initcontainer
NAME                READY   STATUS     RESTARTS   AGE
pod-initcontainer   0/1     Init:0/2   0          93s

发现 Init:0/2，说明我们的 init 容器 并没有执行成功，需要一直重试。这里失败的原因是我们并没有 172.16.58.203 和 172.16.58.204 这两个地址，所以必然是失败的。

6.4 动态监听 Pod 状态

[root@k8s-master pod]# kubectl get pod pod-initcontainer -w
NAME                READY   STATUS     RESTARTS   AGE
pod-initcontainer   0/1     Init:0/2   0          3m31s
#监听中

6.5 新增 IP

我们新开一个 Shell 来为当前服务器新增 172.16.58.203 和 172.16.58.204 这两个 IP。

ifconfig ens33:1 172.16.58.203 netmask 255.255.255.0 up

ifconfig ens33:2 172.16.58.204 netmask 255.255.255.0 up

可以查看：

[root@k8s-master ~]# ifconfig
# 刚刚新增的两个 IP
ens33:1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 172.16.58.203  netmask 255.255.255.0  broadcast 172.16.58.255
        ether 00:0c:29:da:d1:91  txqueuelen 1000  (Ethernet)
ens33:2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 172.16.58.204  netmask 255.255.255.0  broadcast 172.16.58.255
        ether 00:0c:29:da:d1:91  txqueuelen 1000  (Ethernet)

同时监控到 pod-initcontainer 的变化：

[root@k8s-master pod]# kubectl get pod pod-initcontainer -w
NAME                READY   STATUS     RESTARTS   AGE
pod-initcontainer   0/1     Init:0/2   0          3m31s
pod-initcontainer   0/1     Init:1/2   0          6m38s
pod-initcontainer   0/1     PodInitializing   0          6m39s
pod-initcontainer   1/1     Running           0          6m40s

这就是 init 容器的简单演示了。

# 7. 钩子函数

钩子函数能够感知自身生命周期中的事件，并在相应的时刻到来时运行用户指定的程序代码。

k8s 在主容器启动之后和停止之前提供了两个钩子函数：

  • postStart：容器创建之后执行，如果失败会重启容器
  • preStop：容器终止之前执行，执行完成之后容器将成功终止，在其完成之前会阻塞删除容器的操作

钩子处理器支持使用下面的三种方式定义动作：

  • exec 命令：在容器内执行一次的命令

    ……
  lifecycle:
     postStart: 
        exec:
           command:
             - cat
             - /tmp/healthy
……

  • tcpSocket：当前容器尝试访问指定的 socket

    …… 
   lifecycle:
      postStart:
         tcpSocket:
            port: 8080
……

  • httpGet：在当前容器中向某 url 发起 HTTP 请求

    …… 
   lifecycle:
      postStart:
         httpGet:
            path: / #URI地址
            port: 80 #端口号
            host: 172.16.58.200 #主机地址  
            scheme: HTTP #支持的协议，http或者https
……

接下来，以 exec 方式为例，演示下钩子函数的使用。

7.1 创建 pod-hook-exec.yaml 文件

apiVersion: v1
kind: Pod
metadata:
	name: pod-hook-exec
	labels:
		user: hedon
spec:
	containers:
		- name: nginx
		  image: nginx:1.17.1
			imagePullPolicy: IfNotPresent
			ports:
				- name: nginx-port
					containerPort: 80
					protocol: TCP
			resources:
				limits:
					cpu: "2"
					memory: "10Gi"
				requests:
					cpu: "1"
					memory: "10Mi"
			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"]

7.2 创建 Pod

[root@k8s-master pod]# kubectl apply -f pod-hook-exec.yaml 
pod/pod-hook-exec created

7.3 查看 Pod 状况

[root@k8s-master pod]# kubectl get pod pod-hook-exec -o wide
NAME            READY   STATUS    RESTARTS   AGE     IP            NODE        NOMINATED NODE   READINESS GATES
pod-hook-exec   1/1     Running   0          3m31s   10.244.1.14   k8s-node1   <none>           <none>

7.4 访问 Nginx 首页，看看 postStart 是否成功

[root@k8s-master pod]# curl 10.244.1.14
postStart ...

# 8. 容器探测

容器探测用于检测容器中的应用实例是否正常工作，是保障业务可用性的一种传统机制。如果经过探测，实例的状态不符合预期，那么k8s 就会把该问题实例“摘除”，不承担业务流量。

k8s 提供了两种探针来实现容器探测，分别是：

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

k8s 在 1.16 版本之后新增了 startupProbe 探针，用于判断容器内应用程序是否已经启动。如果配置了 startupProbe 探针，就会先禁止其他的探针，直到 startupProbe 探针成功为止，一旦成功将不再进行探测。

上述探针目前均支持三种探测方式：

  • exec 命令：在容器内支线一次命令，如何命令执行的退出吗为 0，则认为程序正常，否则异常

    ……
  livenessProbe:
     exec:
        command:
          - cat
          - /tmp/healthy
……

  • tcpSocket：将会尝试访问一个用户容器的端口，如果能够建立这条连接，则认为程序正常，否则异常

    ……
   livenessProbe:
      tcpSocket:
         port: 8080
……

  • httpGet：调用容器内 web 应用的 URL，如果返回的状态码在 200 和 399 之间，则认为程序正常，否则异常

    ……
   livenessProbe:
      httpGet:
         path: / #URI地址
         port: 80 #端口号
         host: 127.0.0.1 #主机地址
         scheme: HTTP #支持的协议，http或者https
……

限制探测条件：

[root@k8s-master ~]# kubectl explain pod.spec.containers.livenessProbe
FIELDS:
   exec	<Object>

   failureThreshold	<integer>     #探测多少次被认定为失败，默认是3个，最小值是1

   httpGet	<Object>

   initialDelaySeconds	<integer> #容器启动后等待多少秒执行第一次探测

   periodSeconds	<integer>       #执行探测的评率，默认是10秒每次，最小1秒每次

   successThreshold	<integer>     #连续成功探测多少次才被认定为成功，默认是1

   tcpSocket	<Object>
   
   timeoutSeconds	<integer>        #探测超时时间，默认是1秒，最小1秒

# 9. 重启策略

Pod 的 spec 中包含一个 restartPolicy 字段，其可能取值包括：

  • Always（默认）
  • OnFailure
  • Never

restartPolicy 适用于 Pod 中的所有容器。restartPolicy 仅针对同一节点上 kubelet的容器重启动作。

首次需要重启的容器，将在其需要的时候立即进行重启，随后再次重启的操作将由 kubelet 延迟一段时间后进行，且反复的重启操作的延迟时长以此为 10s、20s、40s、80s、160s 和 300s，300s 是最大的延迟时长。

一旦某容器执行了 10 分钟并且没有出现问题，kubelet 对该容器的重启回退计时器执行重置操作。

apiVersion: v1
kind: Pod
metadata:
  name: pod-restart-policy
  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:
          port: 80
          path: /hello
          host: 127.0.0.1
          scheme: HTTP
  restartPolicy: Never # 重启策略

# 九、Pod 调度

在默认情况下，一个 Pod 在哪个 Node 节点上运行，是由 Scheduler 组件采用相应的算法计算出来的，这个过程是不受人工控制的。但是在实际使用中，这并不满足需求，因为很多情况下，我们想控制某些 Pod 到达某些节点上，那么应该怎么做？这就要求了解k8s 对 Pod的调度规则，ks8 提供了四大类调度方式：

  • 自动调度：运行在哪个 Node 节点上完全由 Scheduler 经过一系列的算法计算得出
  • 定向调度：NodeName、NodeSelector
  • 亲和性调度：NodeAffinity、PodAffinity、PodAntiAffinity
  • 污点（容忍）调度：Taints、Toleration

# 1. 定向调度

定向调度，指的是利用在 Pod 上声明的 nodeName 或 nodeSelector，以此将 Pod 调度到期望的 Node 节点上。

‼️​注意，这里的调度是强制的，这就意味着即使要调度的目标 Node 不存在，也会向上面进行调度，只不过 Pod 运行失败而已。

  • nodeName

    nodeName 用于强制约束将 Pod 调度到指定的 name 的 Node 节点上。这种方式，其实是直接跳过 Scheduler 的调度逻辑，直接将Pod 调度到指定名称的节点。

    • 创建 pod-nodename.yaml 文件

      apiVersion: v1
kind: Pod
metadata:
  name: pod-nodename
  labels:
    user: hedon
spec:
  containers: # 容器配置
    - name: nginx
      image: nginx:1.17.1
      imagePullPolicy: IfNotPresent
      ports:
        - name: nginx-port
          containerPort: 80
          protocol: TCP
  nodeName: k8s-node1 # 指定调度到k8s-node1节点上

    • 创建 Pod

      [root@k8s-master pod]# kubectl apply -f pod-nodename.yaml 
pod/pod-nodename created

    • 查看 Pod 信息

      [root@k8s-master pod]# kubectl get pod pod-nodename -o wide
NAME           READY   STATUS    RESTARTS   AGE   IP            NODE        NOMINATED NODE   READINESS GATES
pod-nodename   1/1     Running   0          59s   10.244.1.15   k8s-node1   <none>           <none>

      可以看到 Pod 被调度到 k8s-node1 节点了。

  • nodeSelector

    nodeSelector 用于将 Pod 调度到添加了指定标签的 Node 节点上，它是通过 k8s 的 label-selector 机制实现的，换言之，在 Pod 创建之前，会由 Scheduler 使用 MatchNodeSelector 调度策略进行 Label 匹配，找出目标 node，然后将 Pod 调度到目标节点，该匹配规则是强制约束。

    • 首先给 node 添加标签

      [root@k8s-master pod]# kubectl label node k8s-node1 nodeevn=pro
node/k8s-node1 labeled
[root@k8s-master pod]# kubectl label node k8s-node2 nodeevn=test
node/k8s-node2 labeled

    • 查看 node 标签

      [root@k8s-master pod]# kubectl get nodes --show-labels
NAME         STATUS   ROLES    AGE     VERSION   LABELS
k8s-master   Ready    master   3d23h   v1.18.0   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=k8s-master,kubernetes.io/os=linux,node-role.kubernetes.io/master=
k8s-node1    Ready    <none>   3d23h   v1.18.0   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=k8s-node1,kubernetes.io/os=linux,nodeevn=pro
k8s-node2    Ready    <none>   3d23h   v1.18.0   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=k8s-node2,kubernetes.io/os=linux,nodeevn=test

    • 创建 pod-nodeselector.yaml 文件

      apiVersion: v1
kind: Pod
metadata:
  name: pod-nodeselector
  labels:
  	user: hedon
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 节点上

    • 创建 Pod

      [root@k8s-master pod]# kubectl apply -f pod-nodeselector.yaml 
pod/pod-nodeselector created

    • 查看 Pod 信息

      [root@k8s-master pod]# kubectl get pod pod-nodeselector -o wide
NAME               READY   STATUS    RESTARTS   AGE   IP            NODE        NOMINATED NODE   READINESS GATES
pod-nodeselector   1/1     Running   0          12s   10.244.1.16   k8s-node1   <none>           <none>

      因为 k8s-node1 有 nodeevn=pro 这个标签，所以被调度到了 k8s-node1 节点上了。

# 2. 亲和性调度

虽然定向调度的两种方式，使用起来非常方便，但是也有一定的问题，那就是如果没有满足条件的 Node，那么 Pod 将不会被运行，即使在集群中还有可用的 Node 列表也不行，这就限制了它的使用场景。

基于上面的问题，k8s 还提供了一种亲和性调度（Affinity）。它在 nodeSelector 的基础之上进行了扩展，可以通过配置的形式，实现优先选择满足条件的 Node 进行调度，如果没有，也可以调度到不满足条件的节点上，使得调度更加灵活。

Affinity 主要分为三类：

  • nodeAffinity（node 亲和性）：站在 Pod 的角度上，设置 Pod 希望调度到什么 Node 上
  • podAffinity（pod 亲和性）：站在 Pod 的角度上，设置 Pod 希望和哪些已经运行的 Pod 在一起运行
  • podAntiAffinity（pod 反亲和性）：站在 Pod 的角度上，设置 Pod 不希望和哪些 Pod 在一起运行

关于亲和性和反亲和性的使用场景的说明：

  • 亲和性：如果两个应用频繁交互，那么就有必要利用亲和性让两个应用尽可能的靠近，这样可以较少因网络通信而带来的性能损耗。

  • 反亲和性：当应用采用多副本部署的时候，那么就有必要利用反亲和性让各个应用实例打散分布在各 Node 上，这样可以提高服务的高可用性。

# 2.1 nodeAffinity

站在 Pod 的角度上，设置 Pod 希望调度到什么 Node 上。

  • preferredDuringSchedulingIgnoredDuringExecution <[]Object>：优先调度到满足指定的规则的 Node，相当于软限制
    • preference <Object> -required- ：一个节点选择器项，与相应的权重相关联
      • matchExpressions <[]Object>：按节点标签列出的节点选择器要求列表（推荐）
        • key <string> -required-
        • values <[]string>
        • operator <string> -required-：操作符可以为 In, NotIn, Exists, DoesNotExist. Gt, and Lt.
      • matchFields <[]Object>：按节点字段列出的节点选择器要求列表
        • key <string> -required-
        • values <[]string>
        • operator <string> -required-
    • weight <integer> -required- ：倾向权重，在范围 1-100
  • requiredDuringSchedulingIgnoredDuringExecution <Object>：Node 节点必须满足指定的所有规则才可以，相当于硬限制
    • nodeSelectorTerms <[]Object> -required-：节点选择列表
      • matchExpressions <[]Object>
      • matchFields <[]Object>

举例：

- 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"

案例1：

演示 requiredDuringSchedulingIgnoredDuringExecution

  • 创建 pod-nodeaffinity-required.yaml 文件

    apiVersion: v1
kind: Pod
metadata:
  name: pod-nodeaffinity-required
  labels:
    user: hedon
spec:
  containers:
    - name: nginx
      image: nginx:1.17.1
      imagePullPolicy: IfNotPresent
      ports:
        - name: nginx-port
          containerPort: 80
          protocol: TCP
  affinity: #亲和性配置
    nodeAffinity: #node 亲和性配置
      requiredDuringSchedulingIgnoredDuringExecution: #强制满足所有条件
        nodeSelectorTerms: #节点选择列表
          - matchExpressions:
              - key: nodeevn #存在标签nodeevn的节点，则值要在xxx或yyy
                operator: In
                values:
                  - "xxx"
                  - "yyy"

  • 创建 Pod

    [root@k8s-master pod]# kubectl apply -f pod-nodeaffinity-required.yaml 
pod/pod-nodeaffinity-required created

  • 查看 Pod 分配情况

    [root@k8s-master pod]# kubectl get pod pod-nodeaffinity-required -o wide
NAME                        READY   STATUS    RESTARTS   AGE    IP       NODE     NOMINATED NODE   READINESS GATES
pod-nodeaffinity-required   0/1     Pending   0          106s   <none>   <none>   <none>           <none>

    没找到 Pod 的分配情况。

  • 查看 Pod 详细信息

    [root@k8s-master pod]# kubectl describe pod pod-nodeaffinity-required
Name:         pod-nodeaffinity-required
  Type     Reason            Age        From               Message
  ----     ------            ----       ----               -------
  Warning  FailedScheduling  <unknown>  default-scheduler  0/3 nodes are available: 3 node(s) didn't match node selector.
  Warning  FailedScheduling  <unknown>  default-scheduler  0/3 nodes are available: 3 node(s) didn't match node selector.

    可以看到没有匹配到符合规则的 Node。

  • 给 k8s-node2 打上标签 nodeevn=xxx

    [root@k8s-master pod]# kubectl label node k8s-node2 nodeevn=xxx --overwrite
node/k8s-node2 labeled
[root@k8s-master pod]# kubectl get nodes --show-labels
NAME         STATUS   ROLES    AGE     VERSION   LABELS
k8s-master   Ready    master   4d      v1.18.0   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=k8s-master,kubernetes.io/os=linux,node-role.kubernetes.io/master=
k8s-node1    Ready    <none>   4d      v1.18.0   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=k8s-node1,kubernetes.io/os=linux,nodeevn=pro
k8s-node2    Ready    <none>   3d23h   v1.18.0   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=k8s-node2,kubernetes.io/os=linux,nodeevn=xxx

  • 查看 Pod 分配情况

    [root@k8s-master pod]# kubectl get pod pod-nodeaffinity-required -o wide
NAME                        READY   STATUS    RESTARTS   AGE     IP            NODE        NOMINATED NODE   READINESS GATES
pod-nodeaffinity-required   1/1     Running   0          4m47s   10.244.2.11   k8s-node2   <none>           <none>

    k8s-node2 现在已经符合规则，pod 分配成功。

案例2：

演示 preferredDuringSchedulingIgnoredDuringExecution

  • 创建 pod-nodeaffinity-preferred.yaml 文件

    apiVersion: v1
kind: Pod
metadata:
  name: pod-nodeaffinity-perferred
  labels:
    user: hedon
spec:
  containers:
    - name: nginx
      image: nginx:1.17.1
      imagePullPolicy: IfNotPresent
      ports:
        - name: nginx-port
          containerPort: 80
          protocol: TCP
  affinity: #亲和性配置
    nodeAffinity: #node 亲和性配置
      preferredDuringSchedulingIgnoredDuringExecution: #偏好配置
        - preference: #偏好列表，有对应的权重
            matchExpressions:
              - key: nodeAffinity
                operator: In
                values:
                  - "kkk"
                  - "jjj"
          weight: 1 #权重

  • 创建 Pod

    [root@k8s-master pod]# kubectl apply -f pod-nodeaffinity-preferred.yaml 
pod/pod-nodeaffinity-perferred created

  • 查看 Pod 调度情况

    [root@k8s-master pod]# kubectl get pod pod-nodeaffinity-perferred -o wide
NAME                         READY   STATUS    RESTARTS   AGE   IP            NODE        NOMINATED NODE   READINESS GATES
pod-nodeaffinity-perferred   1/1     Running   0          50s   10.244.2.12   k8s-node2   <none>           <none>

    此时 k8s-node1 和 k8s-node2 都没有 nodeAffinity=kkk 或 jjj 的标签，但是这只是偏好配置，所以还是分配到了其中一个节点，现在我们来给 k8s-node1 加上 nodeAffinity=kkk 的标签。

  • 给 k8s-node1 加标签

    [root@k8s-master pod]# kubectl label node k8s-node1 nodeAffinity=kkk
node/k8s-node1 labeled

  • 重启 Pod

    [root@k8s-master pod]# kubectl replace --force -f pod-nodeaffinity-preferred.yaml 
pod "pod-nodeaffinity-perferred" deleted
pod/pod-nodeaffinity-perferred replaced

  • 查看 Pod 调度情况

    [root@k8s-master pod]# kubectl get pod pod-nodeaffinity-perferred -o wide
NAME                         READY   STATUS    RESTARTS   AGE   IP            NODE        NOMINATED NODE   READINESS GATES
pod-nodeaffinity-perferred   1/1     Running   0          19s   10.244.1.17   k8s-node1   <none>           <none>

    调度到了 k8s-node1 上了。

‼️nodeAffinity 规则设置的注意事项

  1. 如果同时定义了 nodeSelector 和 nodeAffinity，那么必须两个条件都得到满足，Pod 才能运行到指定的 Node 上；
  2. 如果 nodeAffinity 指定了多个 nodeSelectorTerms，那么只需其中一个能够匹配成功即可；
  3. 如果一个 nodeSelectorTerms 中有多个 matchExpressions，则一个节点必须满足所有的才能匹配成功；
  4. 如果一个 Pod 所在的 Node 在 Pod 运行期间其标签发生了变化，不再符合该 Pod 的亲和性需求，系统会忽略此变化。

# 2.2 podAffinity

站在 Pod 的角度上，设置 Pod 希望和哪些已经运行的 Pod 在一起运行。

  • requiredDuringSchedulingIgnoredDuringExecution <[]Object>：强制
    • labelSelector <Object> ：标签选择器
      • matchExpressions <[]Object>：按节点标签列出的节点选择器要求列表(推荐)
        • key
        • value
        • operator
      • matchLabels <map[string]string>：指多个matchExpressions映射的内容
    • namespaces <[]string>：指定参照 pod 的 namespace
    • topologyKey <string> -required- ：指定调度作用域
  • preferredDuringSchedulingIgnoredDuringExecution <[]Object>：偏好
    • podAffinityTerm <Object> -required-
      • labelSelector <Object>
        • matchExpressions <[]Object>
        • matchLabels <map[string]string>
      • namespaces <[]string>
      • topologyKey <string> -required-
    • weight <integer> -required-：权重，值在 1-100 之间

topologyKey 用于指定调度的作用域，例如:

  • 如果指定为 kubernetes.io/hostname，那就是以 Node 节点为区分范围。
  • 如果指定为 beta.kubernetes.io/os，则以 Node 节点的操作系统类型来区分。

案例1：

演示 requiredDuringSchedulingIgnoredDuringExecution

  • 创建参照 Pod

    • 创建 pod-podaffinity-target.yaml 文件

      apiVersion: v1
kind: Pod
metadata:
  name: pod-podaffinity-target
  labels:
    podenv: pro # 设置标签
spec:
  containers: # 容器配置
    - name: nginx
      image: nginx:1.17.1
      imagePullPolicy: IfNotPresent
      ports:
        - name: nginx-port
          containerPort: 80
          protocol: TCP
  nodeName: k8s-node1 # 将目标pod定向调度到k8s-node1

    • 创建 Pod

      [root@k8s-master pod]# kubectl apply -f pod-podaffinity-target.yaml 
pod/pod-podaffinity-target created

    • 查看 Pod 调度情况

      oot@k8s-master pod]# kubectl get pod pod-podaffinity-target -o wide
NAME                     READY   STATUS    RESTARTS   AGE   IP            NODE        NOMINATED NODE   READINESS GATES
pod-podaffinity-target   1/1     Running   0          23s   10.244.1.20   k8s-node1   <none>           <none>

  • 创建新 Pod 去亲和参照 Pod

    apiVersion: v1
kind: Pod
metadata:
  name: pod-podaffinity-required
  labels:
    user: hedon
spec:
  containers:
    - name: nginx
      image: nginx:1.17.1
      imagePullPolicy: IfNotPresent
      ports:
        - name: nginx-port
          containerPort: 80
          protocol: TCP
  affinity: #亲和性配置
    podAffinity: #配置pod亲和
      requiredDuringSchedulingIgnoredDuringExecution: #强制
        - labelSelector:  # 该Pod必须和拥有标签podenv=xxx或者podenv=yyy
            matchExpressions:
              - key: podenv
                operator: In
                values:
                  - "xxx"
                  - "yyy"
          topologyKey: kubernetes.io/hostname #以Node节点为区分度

  • 创建 Pod

    root@k8s-master pod]# kubectl apply -f pod-podaffinity-required.yaml 
pod/pod-podaffinity-required created

  • 查看 Pod 调度情况

    [root@k8s-master pod]# kubectl get pod pod-podaffinity-required -o wide
NAME                       READY   STATUS    RESTARTS   AGE   IP       NODE     NOMINATED NODE   READINESS GATES
pod-podaffinity-required   0/1     Pending   0          40s   <none>   <none>   <none>           <none>

    因为我们没有符合条件的 Pod，所以新 Pod 得不到调度。

  • 给参照 Pod 上标签 podenv=xxx

    [root@k8s-master pod]# kubectl label pod pod-podaffinity-target podenv=xxx --overwrite
pod/pod-podaffinity-target labeled

  • 再查看 Pod 调度情况

    [root@k8s-master pod]# kubectl get pod pod-podaffinity-required -o wide
NAME                       READY   STATUS    RESTARTS   AGE    IP            NODE        NOMINATED NODE   READINESS GATES
pod-podaffinity-required   1/1     Running   0          107s   10.244.1.21   k8s-node1   <none>           <none>

    它就由于 Pod 亲和性跟参照 Pod 一起被调度到 k8s-node1 节点上了。

# 2.3 podAntiAffinity

站在 Pod 的角度上，设置 Pod 不希望和哪些已经运行的 Pod 在一起运行。

  • 编写 pod-podantiaffinity-required.yaml 文件

    apiVersion: v1
kind: Pod
metadata:
  name: pod-podantiaffinity-required
  labels:
    user: hedon
spec:
  containers:
    - name: nginx
      image: nginx:1.17.1
      imagePullPolicy: IfNotPresent
      ports:
        - name: nginx-port
          containerPort: 80
          protocol: TCP
  affinity: #亲和性配置
    podAntiAffinity: #配置pod反亲和性
      requiredDuringSchedulingIgnoredDuringExecution: #强制
        - labelSelector:  # 该Pod不想podenv=xxx的Pod一起运行
            matchExpressions:
              - key: podenv
                operator: In
                values:
                  - "xxx"
          topologyKey: kubernetes.io/hostname #以Node节点为区分度

  • 创建 Pod

    [root@k8s-master pod]# kubectl create -f pod-podantiaffinity-required.yaml 
pod/pod-podantiaffinity-required created

  • 查看 Pod 调度情况

    [root@k8s-master pod]# kubectl get pod pod-podantiaffinity-required -o wide
NAME                           READY   STATUS    RESTARTS   AGE   IP            NODE        NOMINATED NODE   READINESS GATES
pod-podantiaffinity-required   1/1     Running   0          39s   10.244.2.15   k8s-node2   <none>           <none>

    可以看到当前 Pod 避开了在 k8s-node1 的拥有 proenv=xxx 的 Pod，被调度到了 k8s-node2。

# 3. 污点

前面的调度方式都是站在 Pod 的角度上，通过在 Pod 上添加属性，来确定 Pod 是否要调度到指定的 Node 上，其实我们也可以站在 Node 的角度上，通过在 Node 上添加污点属性，来决定是否运行 Pod 调度过来。

Node 被设置了污点之后就和 Pod 之间存在了一种相斥的关系，进而拒绝 Pod 调度进来，甚至可以将已经存在的 Pod 驱逐出去。

污点的格式为：key=value:effect，key 和 value 是污点的标签，effect 描述污点的作用，支持如下三个选项：

  • PreferNoSchedule：k8s 将尽量避免把 Pod 调度到具有该污点的 Node 上，除非没有其他节点可以调度
  • NoSchedule：k8s 将不会把 Pod 调度到具有该污点的 Node 上，但是不会影响当前 Node 上已经存在的 Pod
  • NoExecute：k8s 将不会把 Pod 调度到具有该污点的 Node 上，同时也会将 Node 上已经存在的 Pod 驱逐

污点的三种格式.png

  • 设置污点

    kubectl taint node xxx key=value:effect

  • 去除污点

    kubectl taint node xxx key:effect-

  • 去除所有污点

    kubectl taint node xxx key-

  • 查看 Node 上的污点

    kubectl describe node xxx

案例：

演示污点效果。

  • 前提

    准备节点 k8s-node1，为了演示效果，暂时停止 k8s-node2

    [root@k8s-master pod]# kubectl delete node k8s-node2
node "k8s-node2" deleted
[root@k8s-master pod]# kubectl get nodes
NAME         STATUS   ROLES    AGE     VERSION
k8s-master   Ready    master   4d23h   v1.18.0
k8s-node1    Ready    <none>   26m     v1.18.0

  • 为 k8s-node1 节点设置一个污点：tag=hedon:PreferNoSchedule，然后创建 pod1

    # 添加污点
[root@k8s-master pod]# kubectl taint node k8s-node1 tag=hedon:PreferNoSchedule
node/k8s-node1 tainted

# 创建 pod1
[root@k8s-master pod]# kubectl run pod1 --image=nginx:1.17.1
pod/pod1 created

# 检查 pod1 调度情况
[root@k8s-master pod]# kubectl get pod pod1 -o wide
NAME   READY   STATUS    RESTARTS   AGE   IP            NODE        NOMINATED NODE   READINESS GATES
pod1   1/1     Running   0          16s   10.244.1.27   k8s-node1   <none>           <none>

    符合预期：“尽量不要调度过来”。因为没有别的节点可用的，还是可以调度到 k8s-node1 的。

  • 为 k8s-node1 取消tag=hedon:PreferNoSchedule 污点，然后设置新污点 tag=hedon:NoSchedule，然后创建 pod2

    # 取消污点
[root@k8s-master pod]# kubectl taint node k8s-node1 tag:PreferNoSchedule-
node/k8s-node1 untainted
# 设置污点
[root@k8s-master pod]# kubectl taint node k8s-node1 tag=hedon:NoSchedule
node/k8s-node1 tainted
# 创建 pod2
[root@k8s-master pod]# kubectl run pod2 --image=nginx:1.17.1
pod/pod2 created
# 查看 pod2 调度情况
[root@k8s-master pod]# kubectl get pod pod2 -o wide
NAME   READY   STATUS    RESTARTS   AGE   IP       NODE     NOMINATED NODE   READINESS GATES
pod2   0/1     Pending   0          8s    <none>   <none>   <none>           <none>

    符合预期：“新的别来”。

  • 为 k8s-node1 取消tag=hedon:NoSchedule 污点，然后设置新污点 tag=hedon:NoExecute，然后查看前面的 pod1 调度情况

    # 查看 Pod1 调度情况
[root@k8s-master pod]# kubectl get pod pod1 -o wide
NAME   READY   STATUS    RESTARTS   AGE     IP            NODE        NOMINATED NODE   READINESS GATES
pod1   1/1     Running   0          5m21s   10.244.1.27   k8s-node1   <none>           <none>
# 取消污点
[root@k8s-master pod]# kubectl taint node k8s-node1 tag:NoSchedule-
node/k8s-node1 untainted
# 设置污点
[root@k8s-master pod]# kubectl taint node k8s-node1 tag=hedon:NoExecute
node/k8s-node1 tainted
# 查看 Pod1 调度情况
[root@k8s-master pod]# kubectl get pod pod1 -o wide
Error from server (NotFound): pods "pod1" not found

    符合预期：“在的赶紧走”。Pod

# 4. 容忍

上面介绍了污点的作用，我们可以在 Node 上添加污点用来拒绝 Pod 调度上来，但是如果就是想让一个 Pod 调度到一个有污点的 Node 上去，这时候应该怎么做？这就需要使用到容忍。

容忍的详细配置：

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 的时候，有如下的三种写法：

    • 容忍指定的污点，污点带有指定的 effect

      tolerations: # 容忍
    - key: "tag" # 要容忍的污点的key
      operator: Exists # 操作符
      effect: NoExecute # 添加容忍的规则，这里必须和标记的污点规则相同

    • 容忍指定的污点，不考虑具体的effect：

        tolerations: # 容忍
    - key: "tag" # 要容忍的污点的key
      operator: Exists # 操作符

    • 容忍一切污点（慎用）：

      tolerations: # 容忍
    - operator: Exists # 操作符

案例：

在上面的污点中，已经给 k8s-node1 打上了 NoExecute 的污点，此时 Pod 是调度不上去的，此时可以通过在 Pod 中添加容忍，将 Pod 调度上去。

  • 创建 pod-toleration.yaml 文件

    apiVersion: v1
kind: Pod
metadata:
  name: pod-toleration
  labels:
    user: hedon
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: "hedon"    #要容忍的污点的value
      effect: NoExecute #增加容忍的规则，这里必须和标记的污点规则相同

  • 创建 Pod

    [root@k8s-master pod]# kubectl apply -f pod-toleration.yaml 
pod/pod-toleration created

  • 查看 Pod 调度情况

    [root@k8s-master pod]# kubectl get pod pod-toleration -o wide
NAME             READY   STATUS    RESTARTS   AGE   IP            NODE        NOMINATED NODE   READINESS GATES
pod-toleration   1/1     Running   0          31s   10.244.1.29   k8s-node1   <none>           <none>

    可以看到 pod-toleration 容忍了 k8s-node1 上的污点，调度到了 k8s-node1 上面了。

恢复环境：

  1. 删除 k8s-node1 的一切污点

    [root@k8s-master pod]# kubectl taint node k8s-node1 tag-
node/k8s-node1 untainted

  2. k8s-node2 重新加入集群

    在 k8s-master 生成永久令牌

    [root@k8s-master pod]# kubeadm token create --ttl 0 --print-join-command
W0706 20:21:03.410825   22427 configset.go:202] WARNING: kubeadm cannot validate component configs for API groups [kubelet.config.k8s.io kubeproxy.config.k8s.io]
kubeadm join 172.16.58.200:6443 --token ag80av.jnp23j2405k78sr9     --discovery-token-ca-cert-hash sha256:e4959de30bb94df662147bdf32044d5278eecd7c77f2e56b51ae07860a52fd79

    k8s-node2 删除原来的 CA 文件

    [root@k8s-node2 ~]# rm -rf /etc/kubernetes/pki/ca.crt

    k8s-node2 删除原来的 k8s 配置文件

    [root@k8s-node2 ~]# rm -rf /etc/kubernetes/kubelet.conf

    k8s-node2 停止原来的 k8s 进程

    # 查看 PID
[root@k8s-node2 ~]# ps -ef | grep k8s
avahi       599      1  0 11:05 ?        00:00:01 avahi-daemon: running [k8s-node2.local]
root       9681      1  1 11:13 ?        00:10:47 /usr/bin/kubelet --bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf --config=/var/lib/kubelet/config.yaml --cgroup-driver=systemd --network-plugin=cni --pod-infra-container-image=k8s.gcr.io/pause:3.2 --cgroup-driver=systemd
root     121478 121182  0 20:24 pts/0    00:00:00 grep --color=auto k8s
# kill
[root@k8s-node2 ~]# kill -9 9681

    k8s-node2 加入 集群

    [root@k8s-node2 ~]# kubeadm join 172.16.58.200:6443 --token ag80av.jnp23j2405k78sr9     --discovery-token-ca-cert-hash sha256:e4959de30bb94df662147bdf32044d5278eecd7c77f2e56b51ae07860a52fd79
...
This node has joined the cluster:
* Certificate signing request was sent to apiserver and a response was received.
* The Kubelet was informed of the new secure connection details.

Run 'kubectl get nodes' on the control-plane to see this node join the cluster

    k8s-master 检查 node 情况：

    [root@k8s-master pod]# kubectl get nodes
NAME         STATUS   ROLES    AGE     VERSION
k8s-master   Ready    master   4d23h   v1.18.0
k8s-node1    Ready    <none>   3m3s    v1.18.0
k8s-node2    Ready    <none>   106s    v1.18.0

# 十、临时容器

# 1. 临时容器简介

临时容器是一种特殊的容器，该容器可以在现有的 Pod 中临时运行，以便完成我们发起的操作，比如故障排查。我们应该使用临时容器来检查服务，而不是用临时容器来构建应用程序。

Pod 是 k8s 集群进行管理的最小单元，由于 Pod 是一次性且可以替换的，因此 Pod 一旦被创建，就无法将容器加入到 Pod 中。而且，我们通常使用 Deployment 来删除并替换P od。但是，有的时候我们需要检查现有 Pod 的状态，比如对难以复现的故障进行排查。在这些场景中，可以在现有 Pod 中运行临时容器来检查其状态并运行任意命令。

临时容器和其他容器的不同之处在于，它们缺少对资源或执行的保证，并且永远不会自动重启，因此不适合用来构建应用程序。临时容器使用和常规容器相同的 ContainerSpec来描述，但是许多字段是不兼容或者不允许的：

  • 临时容器没有端口配置，因此像 ports、livenessProbe、readinessProbe这样的字段是没有的
  • Pod 的资源分配是不可变的，因此 resources 这样的配置临时容器也是没有的

临时容器是使用 ephemeralcontainers来进行创建的，而不是直接添加到 pod.spec中，所以是无法使用 kubectl edit 来添加一个临时容器。

和常规容器一样，将临时容器添加到 Pod 后，不能更改或删除临时容器。

# 2. 临时容器作用

  • 当由于容器奔溃或容器镜像不包含调试工具而导致 kubectl exec 无用的时候，临时容器对于交互式故障排查非常有用。
  • 比如，像 distroless 镜像 允许用户部署最小的容器镜像，从而减少攻击面并减少故障和漏洞的暴露。由于 distroless 镜像不包含 Shell 或任何的调试工具，因此很难单独使用 kubectl exec 命令进行故障排查。
  • 使用临时容器的时候，启用 进程名字空间共享 (opens new window) 很有帮助，可以查看其他容器中的进程。

# 3. 临时容器配置

  • 查看临时容器是否开启（默认关闭）

    [root@k8s-master pod]# kubelet -h | grep EphemeralContainers
                EphemeralContainers=true|false (ALPHA - default=false)

  • 在每个节点（不管 Master 节点还是 Node 节点）修改 kubectl 的参数

    注意：kubectl 的启动文件的路径是 /usr/lib/systemd/system/kubelet.service.d/10-kubeadm.conf

    # 修改 /etc/sysconfig/kubelet 文件，添加 --feature-gates EphemeralContainers=true
$ vim /etc/sysconfig/kubelet

KUBELET_EXTRA_ARGS="--cgroup-driver=systemd --feature-gates EphemeralContainers=true"
KUBE_PROXY_MODE="ipvs

# 修改 /var/lib/kubelet/config.yaml 文件，添加 featureGates: EphemeralContainers: true
$ vim /var/lib/kubelet/config.yaml

apiVersion: kubelet.config.k8s.io/v1beta1
authentication:
  anonymous:
    enabled: false
  webhook:
    cacheTTL: 0s
    enabled: true
  x509:
    clientCAFile: /etc/kubernetes/pki/ca.crt
authorization:
  mode: Webhook
  webhook:
    cacheAuthorizedTTL: 0s
    cacheUnauthorizedTTL: 0s
clusterDNS:
- 10.96.0.10
clusterDomain: cluster.local
cpuManagerReconcilePeriod: 0s
evictionPressureTransitionPeriod: 0s
fileCheckFrequency: 0s
healthzBindAddress: 127.0.0.1
healthzPort: 10248
httpCheckFrequency: 0s
imageMinimumGCAge: 0s
kind: KubeletConfiguration
nodeStatusReportFrequency: 0s
nodeStatusUpdateFrequency: 0s
rotateCertificates: true
runtimeRequestTimeout: 0s
staticPodPath: /etc/kubernetes/manifests
streamingConnectionIdleTimeout: 0s
syncFrequency: 0s
volumeStatsAggPeriod: 0s
# 修改部分
featureGates:
  EphemeralContainers: true

    加载配置文件重启 kubelet

    systemctl daemon-reload
systemctl restart kubelet

  • 在 Master 节点修改 kube-apiserver.yaml

    [root@k8s-master pod]# vim /etc/kubernetes/manifests/kube-apiserver.yaml
apiVersion: v1
kind: Pod
metadata:
  annotations:
    kubeadm.kubernetes.io/kube-apiserver.advertise-address.endpoint: 192.168.49.100:6443
  creationTimestamp: null
  labels:
    component: kube-apiserver
    tier: control-plane
  name: kube-apiserver
  namespace: kube-system
spec:
  containers:
  - command:
    - kube-apiserver
    - --advertise-address=192.168.49.100
    - --allow-privileged=true
    - --authorization-mode=Node,RBAC
    - --client-ca-file=/etc/kubernetes/pki/ca.crt
    - --enable-admission-plugins=NodeRestriction
    - --enable-bootstrap-token-auth=true
    - --etcd-cafile=/etc/kubernetes/pki/etcd/ca.crt
    - --etcd-certfile=/etc/kubernetes/pki/apiserver-etcd-client.crt
    - --etcd-keyfile=/etc/kubernetes/pki/apiserver-etcd-client.key
    - --etcd-servers=https://127.0.0.1:2379
    - --insecure-port=0
    - --kubelet-client-certificate=/etc/kubernetes/pki/apiserver-kubelet-client.crt
    - --kubelet-client-key=/etc/kubernetes/pki/apiserver-kubelet-client.key
    - --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname
    - --proxy-client-cert-file=/etc/kubernetes/pki/front-proxy-client.crt
    - --proxy-client-key-file=/etc/kubernetes/pki/front-proxy-client.key
    - --requestheader-allowed-names=front-proxy-client
    - --requestheader-client-ca-file=/etc/kubernetes/pki/front-proxy-ca.crt
    - --requestheader-extra-headers-prefix=X-Remote-Extra-
    - --requestheader-group-headers=X-Remote-Group
    - --requestheader-username-headers=X-Remote-User
    - --secure-port=6443
    - --service-account-issuer=https://kubernetes.default.svc.cluster.local
    - --service-account-key-file=/etc/kubernetes/pki/sa.pub
    - --service-account-signing-key-file=/etc/kubernetes/pki/sa.key
    - --service-cluster-ip-range=10.96.0.0/12
    - --tls-cert-file=/etc/kubernetes/pki/apiserver.crt
    - --tls-private-key-file=/etc/kubernetes/pki/apiserver.key
    # 修改部分
    - --feature-gates=EphemeralContainers=true

  • 在 Master 节点上修改 kube-scheduler.yaml

    [root@k8s-master pod]# vim /etc/kubernetes/manifests/kube-scheduler.yaml
apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    component: kube-scheduler
    tier: control-plane
  name: kube-scheduler
  namespace: kube-system
spec:
  containers:
  - command:
    - kube-scheduler
    - --authentication-kubeconfig=/etc/kubernetes/scheduler.conf
    - --authorization-kubeconfig=/etc/kubernetes/scheduler.conf
    - --bind-address=127.0.0.1
    - --kubeconfig=/etc/kubernetes/scheduler.conf
    - --leader-elect=true
    # 修改部分
    - --feature-gates=EphemeralContainers=true

# 4. 使用临时容器在线 debug

  • 创建一个 nginx-yaml 文件

    apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  shareProcessNamespace: true # 这个配置非常重要，一定要配置
  containers:
  - name: nginx
    image: nginx:1.17.1

  • 创建 Pod

    [root@k8s-master pod]# kubectl apply -f nginx.yaml 
pod/nginx created

  • 创建 ec.json 文件，内容如下（注意：name 是 Pod 的名称）

    {
    "apiVersion": "v1",
    "kind": "EphemeralContainers",
    "metadata": {
            "name": "nginx"
    },
    "ephemeralContainers": [{
        "command": [
            "sh"
        ],
        "image": "busybox",
        "imagePullPolicy": "IfNotPresent",
        "name": "debugger",
        "stdin": true,
        "tty": true,
        "terminationMessagePolicy": "File"
    }]
}

  • 更新已经运行的容器

    kubectl replace --raw /api/v1/namespaces/default/pods/nginx/ephemeralcontainers  -f ec.json

  • 查看新创建的临时容器的状态

    [root@k8s-master pod]# kubectl describe pod nginx
# 临时容器
Ephemeral Containers:
  debugger:
    Container ID:  docker://15f9aa6f6a98fcaff2d6ee85c8a5a6bc7d85293ca832e81a16f0df8c7c61b395
    Image:         busybox
    Image ID:      docker-pullable://busybox@sha256:930490f97e5b921535c153e0e7110d251134cc4b72bbb8133c6a5065cc68580d
    Port:          <none>
    Host Port:     <none>
    Command:
      sh
    State:          Running
      Started:      Tue, 06 Jul 2021 20:46:11 -0700
    Ready:          False
    Restart Count:  0
    Environment:    <none>
    Mounts:         <none>

  • 可以使用如下的命令连接临时容器

    kubectl exec -it nginx -c debugger -- sh
# 或
kubectl attach -it nginx -c debugger

# 十一、服务质量 Qos

k8s 创建Pod的时候就会指定 QoS

[root@k8s-master pod]# kubectl describe pod nginx
QoS Class:       BestEffort

QoS 分为如下的三类：

  • Guaranteed
    • Pod 中的每个容器，包含初始化容器，必须指定内存请求和内存限制，并且两者要相等
    • Pod 中的每个容器，包含初始化容器，必须指定 CPU 请求和 CPU 限制，并且两者要相等
  • Burstable
    • Pod 不符合 Guaranteed QoS 类的标准
    • Pod 中至少一个容器具有内存或 CPU 请求，但是值不相等
  • BestEffort
    • Pod 中的容器必须没有设置内存和 CPU 限制或请求

一旦出现 OOM，k8s 为了保证服务的可用，会先删除 QoS 为 BestEffort 的 Pod，然后删除 QoS 为 Burstable 的Pod，最后删除 QoS 为 Guaranteed 的 Pod。

# 十二、Pod 控制器

在 k8s 中，按照 Pod 的创建方式可以将其分为两类：

  • 自主式 Pod：k8s 直接创建出来的 Pod，这种 Pod 删除后就没有了，也不会重建
  • 控制器创建 Pod：通过 Pod 控制器创建的 Pod，这种 Pod 删除之后还会自动重建

Pod 控制器：Pod 控制器是管理 Pod 的中间层，使用了 Pod 控制器之后，我们只需要告诉 Pod 控制器，想要多少个什么样的 Pod 就可以了，它就会创建出满足条件的 Pod 并确保每一个 Pod 处于用户期望的状态，如果 Pod 在运行中出现故障，控制器会基于指定的策略重启或重建 Pod。

在 k8s 中，有很多类型的 Pod 控制器，每种都有自己的适合的场景，常见的有下面这些：

  • ReplicationController：比较原始的 Pod 控制器，已经被废弃，由 ReplicaSet 替代
  • ReplicaSet：保证指定数量的 Pod 运行，并支持 Pod 数量变更，镜像版本变更
  • Deployment：通过控制 ReplicaSet 来控制 Pod，并支持滚动升级、版本回退
  • Horizontal Pod Autoscaler：可以根据集群负载自动调整 Pod 的数量，实现削峰填谷
  • DaemonSet：在集群中的指定 Node 上都运行一个副本，一般用于守护进程类的任务
  • Job：它创建出来的 Pod 只要完成任务就立即退出，用于执行一次性任务
  • CronJob：它创建的 Pod 会周期性的执行，用于执行周期性的任务
  • StatefulSet：管理有状态的应用
上次更新: 7/8/2021, 11:28:32 AM

← ReplicaSet →