Kubernetes Pod生命周期和重启策略

长安故里

已于 2022-04-27 11:53:53 修改

阅读量461

点赞数

分类专栏： Kubernetes 文章标签： linux kubernetes

于 2022-04-27 11:45:52 首次发布

本文链接：https://blog.csdn.net/lsx_3/article/details/124445076

版权

Kubernetes 专栏收录该内容

12 篇文章

订阅专栏

Kubernetes Pod生命周期、重启策略、健康检查、服务可用性检查

在Pod被部署之后，会被系统定义成多种状态。我们称之为Pod的生命周期。熟悉整个生命周期，是理解如何设置Pod的调度策略、重启策略的前提。

Pod的状态

状态值	描述
Pending	API Server已经创建Pod,但是Pod中的容器尚未启动完成，例如镜像正在下载等
Running	Pod内的所有容器都已经创建完毕，并且至少有一个容器处于运行状态、启动状态或者重启状态
Succeeded	Pod内的容器都已经成功执行后推出，并且不会重启
Failed	Pod内的容器均已经推出，并且至少有一个以退出状态为失败
Unknow	由于某种原因，无法获取到Pod的状态，例如可能因为网络不通畅导致等

Pod的重启策略

Pod的重启策略（RestartPolicy）应用于Pod中的所有容器，并且由Pod所在的Node上的kubelet进行判断和重启操作。当某个容器异常退出，或者健康检查失败，kubelet根据RestartPolicy的值，进行相关的操作。
Pod有以下的重启策略：

Always：当容器失效时，kubelet自动重启该容器（默认模式）
OnFailuure：当容器种植运行，并且退出码不为0时，kubelet自动重启该容器
Never：不论容器运行状态如何，kubelet都不会重启该容器

Pod的重启策略和Pod的控制方式也是有一定的关系，每种控制方式和Pod的重启策略的要求如下：

ReplicationController和DaemonSet：必须设定为Always，需要保持该容器持续运行
Job：OnFailure或者Never，确保容器执行完毕之后不会重启
kubelet：在Pod失效的时候自动重启它，不论重启策略是什么，也不会对Pod进行健康检查
其他：根据需求进行设定

apiVersion: v1
kind: Pod
metadata:

  name: foo
spec:
  containers:
  - name: busybox
    image: busybox
    args:
    - /bin/sh
    - -c
    - sleep 10;exit 3
  restartPolicy: Never  '//添加重启策略为从不重启'

健康检查

Kubernetes对Pod的健康检查状态可以分为三种探针来检查：LivenessProbe、ReadinessProbe以及StartupProbe，其中最主要的是LivenessProbe和ReadinessProbe
以下是对探针的详细说明：

LivenessProbe：用于判断容器是否还存活，也就是是否还处于Running状态，如果LivenessProbe探针探测到容器时非健康状态，kubelet将会杀死该容器，并且依据容器的重启策略做出相对应的处理，如果创建容器时不包含LivenessProbe探针配置，那么kubelet则会默认为该容器的LivenessProbe探针返回值永远为Success。
ReadinessProbe：用于判断容器服务是否可用，也就是是否处于Ready状态，对于服务的容器，必须是处于Ready状态，才可以接收请求，对于Service管理的Pod，Service与Pod Endpoint的关联关系也将基于Pod是否Ready进行设定。如果在运行的过程中，Ready状态变成False，则系统自动将其从Service的后端EndPoint列表中隔离，后续Pod恢复Ready状态之后，自动将其加入到Endpoint列表中。需要注意的是ReadinessProbe是定期触发执行的，并且存在Pod的整个生命周内。
StartupProbe：在使用过程中，会遇到某些应用启动速度较慢。再启动过程中可能出现访问超时的情况，这时候ReadinessProbe就不适用当前场景，但是StartupProbe可以解决这种问题。

---
apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-exec
spec:
  containers:
  - name: liveness
    image: gcr.io/google_containers/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

以上的例子通过cat /tmp/health来判断一个Pod是否正常，在该Pod运行后，将创建/tmp/health并且在10s之后删除该文件，而livenessProbe健康检查的初始探测时间（initialDelaySeconds）为15秒，如果探测结果为Fail，那么kubelet将会杀死该容器，并且重启该容器

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

以上的例子通过容器的IP地址和端口号执行TCP检查，如果能正常建立TCP连接，则说明容器健康

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

以上代码通过容器的IP地址、端口号以及路径调用HTTP GET方法，kubelet定时发送HTTP请求到localhost:80/_status/healthz,如果状态码返回大于等于200且小于400则认为容器健康.

在上面所有的例子中都需要设定initialDelaySeconds和timeoutSeconds，它们的含义如下：

initialDelaySeconds：启动容器后进行手册健康检查的等待时间，单位为秒
timeoutSeconds：健康检查发送请求后的等待响应的超时时间，单位为秒，当超时情况发生时，kubelet则认为该容器失效，并且根据重启策略进行相关操作

startupProbe:
  httpGet:
    path: /_status/healthz
    port: 80
  filureThreshold: 30
  periodSeconds: 10

以上代码片段是startupProbe的参考配置，可以看到这个Pod可以有长达300秒的超长启动时间