带你玩转kubernetes-k8s（第15篇：k8s-深入掌握Pod-上节遗留问题解决方案，Pod生命周期和重启策略）

    上篇我们在使用Downward API将Pod的labels 信息 annotations信息过载到Volume这个实例中出现了问题，本节先解决上篇的内容再回头讲解今天的内容。

     上篇中，我们mouthPaht指定的目录的是/etc下面的目录，由于docker的容器的目录结构，docker容器是对下层的文件系统有只对权限，但是没有修改权限，所以导致报一些了rootfs的错误。

   现在我们将yaml文件修改为这个样子。

apiVersion: v1
kind: Pod
metadata:
  name: dapi-test-pod-volume
  labels:
    zone: us-est-coast
    cluster: test-cluster
    rack: rack-22
  annotations:
    build: two
    builder: john-doe
spec:
  containers:
    - name: test-container
      image: busybox
      imagePullPolicy: IfNotPresent
      command: ["/bin/sh","-c"]
      args:
      - while true;do
          if [[ -e /var/labels ]];then
            echo -en "\n\n";cat /var/labels; fi;
          if [[ -e /var/annotations ]];then
            echo -en "\n\n";cat /var/annotations; fi;
          sleep 60;
        done;
      volumeMounts:
        - name: podinfo
          mountPath: /var
          readOnly: false

上节的问题我们就说到这里。下面我们回到我们这节的主题。

Pod生命周期和重启策略

       Pod在整个生命周期中被系统定义为各种状态，熟悉Pod的各种状态对于理解如何设置Pod的调度策略、重启策略是很有必要的。

  Pod的状态表如下所述：

  

状态值	描述
Pending	API Server 已经创建该Pod，但在Pod内还有一个或多个容器的镜像没有创建，包括正在下载镜像的过程
Running	Pod内所有容器均已创建，且至少有一个容器处于运行状态、正在启动状态或正在重启状态。
Succeeded	Pod内所有容器均成功执行后退出，且不会再重启
Failed	Pod内所有容器均已退出，但至少有一个容器退出为失败状态
Unknown	由于某种原因无法获取该Pod的状态，可能由于网络通信不畅导致。

 

      Pod的重启策略（RestartPolicy）应用于Pod内的所有容器，并且仅在Pod所处的Node上由kubelet进行判断和重启操作。当某个个容器异常退出或者健康检查失败时，kubelet将根据RestartPolicy的设置来进行相应的操作。

      Pod的重启策略包括Always、OnFailure和Never，默认值为Always。

     ◎　Always：当容器失效时，由kubelet自动重启该容器。
     ◎　OnFailure：当容器终止运行且退出码不为0时，由kubelet自动重启该容器。
     ◎　Never：不论容器运行状态如何，kubelet都不会重启该容器。

     kubelet重启失效容器的时间间隔以sync-frequency乘以2n来计算，例如1、2、4、8倍等，最长延时5min，并且在成功重启后的10min后重置该时间。
     Pod的重启策略与控制方式息息相关，当前可用于管理Pod的控制器包括ReplicationController、Job、DaemonSet及直接通过kubelet管理（静态Pod）。每种控制器对Pod的重启策略要求如下。

    ◎　RC和DaemonSet：必须设置为Always，需要保证该容器持续运行。
    ◎　Job：OnFailure或Never，确保容器执行完成后不再重启。
    ◎　kubelet：在Pod失效时自动重启它，不论将RestartPolicy设置为什么值，也不会对Pod进行健康检查。

结合Pod的状态和重启策略，表3.3列出一些常见的状态转换场景。

 

Pod包含的容器数	Pod当前的状态	发生事件	Pod的结果状态
			RestarPolicy=Always	RestartPolicy=OnFailure	RestartPolicy=Never
包含1个容器	Running	容器成功退出	Running	Succeeded	Succeeded
包含1个容器	Running	容器失败退出	Running	Running	Failed
包含两个容器	Running	1个容器失败退出	Running	Running	Running
包含两个容器	Running	容器被OOM杀掉	Running	Running	Failed

 

     Kubernetes 对 Pod 的健康状态可以通过两类探针来检查：LivenessProbe 和ReadinessProbe，kubelet定期执行这两类探针来诊断容器的健康状况。
（1）LivenessProbe探针：用于判断容器是否存活（Running状态），如果LivenessProbe探针探测到容器不健康，则kubelet将杀掉该容器，并根据容器的重启策略做相应的处理。如果一个容器不包含LivenessProbe探针，那么kubelet认为该容器的LivenessProbe探针返回的值永远是Success。
（2）ReadinessProbe探针：用于判断容器服务是否可用（Ready状态），达到Ready状态的Pod才可以接收请求。对于被Service管理的Pod，Service与Pod Endpoint的关联关系也将基于Pod是否Ready进行设置。如果在运行过程中Ready状态变为False，则系统自动将其从Service的后端Endpoint列表中隔离出去，后续再把恢复到Read状态的Pod加回后端Endpoint列表。这样就能保证客户端在访问Service时不会被转发到服务不可用的Pod实例上。

    LivenessProbe和ReadinessProbe均可配置以下三种实现方式。

    （1）ExecAction： 在容器内部执行一个命令，如果该命令的返回码为0，则表明容器健康。

      在下面的例子中，通过执行“cat /tmp/health” 命令来判断一个容器运行是否正常。在该Pod运行后，将在创建/tmp/health文件10s后删除该文件，而LivenessProbe健康检查的初始探测时间（initialDelaySeconds）为15s，探测结果是Fail，将导致kubelet杀掉该容器并重启它：

 

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-exec
spec:
  containers:
  - name: liveness
    image: busybox
    args:
      - /bin/sh
      - c
      - echo ok > /tmp/health; sleep 10; rm -rf /tmp/health; sleep 600
    livenessProbe:
      exec:
        command:
        - cat /tmp/health
      initialDelaySeconds: 15
      timeoutSeconds: 1

 

（2）TCPSocketAction：通过容器的IP地址和端口号执行TCP检查，如果能够建立TCP连接，则表明容器健康。

在下面的例子中，通过容器内的localhost：80建立TCP连接进行健康检查：

apiVersion: v1
kind: Pod
metadata:
  name: pod-with-healthcheck
spec:
  containers:
  - name: nginx
    image: nginx
    ports:
    - containerPort: 80
    livenessProbe:
      tcpSocket:
        port: 80
      initialDelaySeconds: 30
      timeoutSeconds: 1

（3）HTTPGetAction: 通过容器的IP地址、端口号及路径调用HTTP Get方法，如果响应的状态码大于等于200且小于400，则认为容器健康。

       在下面的例子中，kubelet定时发送HTTP请求到localhost:80/_status/healthz来进行容器应用的健康检查：

apiVersion: v1
kind: Pod
metadata:
  name: pod-with-healthcheck2
spec:
  containers:
  - name: nginx
    image: nginx
    ports:
    - containerPort: 80
    livenessProbe:
      httpGet:
        path: /_status/healthz
        port: 80
      initialDelaySeconds: 30
      timeoutSeconds: 1
                         

   对于每种探测方法，都需要设置initialDelaySeconds和timeoutSeconds两个参数，它们的含义分别如下。

initialDelaySeconds：启动容器后进行首次健康检查的等待时间，单位为s

timeoutSeconds:  健康坚持发送请求后等待响应的超时时间，单位为s。当超时发生时，kubelet会认为容器已经无法提供服务，将会重启该容器。

    k8s的ReadinessProbe机制无法满足某些复杂应用对容器内服务可用状态的判断，所以k8s引入Pod Ready++特性对Readiness探测机制进行扩展。

   通过Pod Readiness Gates机制，用户可以将自动以的ReadinessProbe探测方式设置在Pod上，辅助k8s设置Pod何时达到服务可用状态（Ready）。为了使自动以的ReadinessProbe生效，用户提供一个外部的控制器（Controller）来设置相应的Condition状态。

   Pod的Readiness Gates 在Pod定义中的ReadinessGate字段进行设置。下面的例子设置了一个类型为www.example.com/feature-1的Readiness Gate：

kind: Pod
.....
spec:
  readinessGates:
  - conditionType: "www.example.com/feature-1"
status:
  conditions:
  - type: Ready # Kubernetes系统内置的名为Ready的Condition
    status: "True"
    lastProbeTime: null
    lastTransitionTime: 2019-03-15T00:00:00Z
  - type: "wwww.example.com/feature-1"
    status: "False"
    lastProbeTime: null
    lastTransitionTime: 2019-07-15T00:00:00Z
  containerStatuses:
  - containerID: docker://abcd..
    ready: true
.....

   新增的自定义Condition的状态（status）将由用户自定义的外部控制器设置，默认值为False。Kubernetes将在判断全部readinessGates条件都为True时，才设置Pod为服务可用状态。