生命周期

Kubelet 可以选择是否执行在容器上运行的两种探针执行和做出反应：

• livenessProbe ：指示 容器是否正在运行

  • 如果存活探测失败，则 kubelet 会杀死容器，并且容器将受到其 重启策略 的影响

    如果容器不提供存活探针，则默认状态为 Success
    

• readinessProbe ：指示容器是否 准备好服务请求
  • 如果就绪探测失败，端点控制器将从 与 Pod 匹配 的所有 Service 的端点 中 删除 该 Pod 的 IP 地址

  • 初始延迟 之前的 就绪状态 默认为 Failure

    如果容器不提供就绪探针，则默认状态为 Success
    

如果容器中的进程能够在遇到问题或不健康的情况下 自行崩溃 ，则不一定需要存活探针

kubelet 将根据 Pod 的restartPolicy 自动执行正确的操作

如果希望容器在 探测失败 时被 杀死并重新启动 ，那么请

• 指定 一个 存活探针
• 指定 restartPolicy 为 Always 或 OnFailure

如果要 仅在探测成功 时才开始向 Pod 发送流量，请 指定 _就绪_探针

在这种情况下，就绪探针可能与存活探针相同，但是 spec 中的就绪探针的存在意味着 Pod 将在没有接收到任何流量的情况下启动，并且只有在探针探测成功后才开始接收流量

如果希望容器能够 自行维护 ，可以指定一个就绪探针，该探针检查与 存活探针不同的端点

如果只想在 Pod 被删除时能够排除请求 ，则不一定需要使用就绪探针 

在删除 Pod 时，Pod 会自动将自身置于未完成状态，无论就绪探针是否存在，当等待 Pod 中的容器停止时，Pod 仍处于未完成状态 

自 Kubernetes 1.14（在1.11 版本是为 alpha）起默认支持 Pod 就绪检测机制扩展

应用程序可以向 PodStatus 注入额外的反馈或信号： Pod readiness

要使用这个功能，请在 PodSpec 中设置 readinessGates 来指定 kubelet 评估 Pod readiness 的附加条件列表

Readiness gates 由 Pod 的 status.condition 字段的当前状态决定

如果 Kubernetes 在 Pod 的 status.conditions 字段中找不到这样的条件，则该条件的状态默认为 "False"

下面是一个例子：

kind: Pod
spec:
  readinessGates:
    - conditionType: "www.example.com/feature-1"
status:
  conditions:
    - type: Ready                              # 内置的 Pod 状态
      status: "False"
      lastProbeTime: null
      lastTransitionTime: 2018-01-01T00:00:00Z
    - type: "www.example.com/feature-1"        # 附加的额外的 Pod 状态
      status: "False"
      lastProbeTime: null
      lastTransitionTime: 2018-01-01T00:00:00Z
  containerStatuses:
    - containerID: docker://abcd...
      ready: true

添加的 Pod 条件的名称必须符合 Kubernetes 的 label key 格式

只有到 Pod 中的 所有容器状态 都是 Ready ，且 Pod 附加的额外状态检测的 readinessGates 条件 也是 Ready 的时候， Pod 的状态才是 Ready

存活探针由 kubelet 来执行，因此所有的请求都在 kubelet 的网络命名空间中进行：

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-http
spec:
  containers:
  - args:
    - /server
    image: k8s.gcr.io/liveness
    livenessProbe:
      httpGet:
        # when "host" is not defined, "PodIP" will be used
        # host: my-host
        # when "scheme" is not defined, "HTTP" scheme will be used. Only "HTTP" and "HTTPS" are allowed
        # scheme: HTTPS
        path: /healthz
        port: 8080
        httpHeaders:
        - name: X-Custom-Header
          value: Awesome
      initialDelaySeconds: 15
      timeoutSeconds: 1
    name: liveness

1. Pod 中只有一个容器并且正在运行。容器成功退出：
   • 记录完成事件
   • 如果 restartPolicy 为：
     • Always：重启容器，Pod phase 仍为 Running
     • OnFailure：Pod phase 变成 Succeeded
     • Never：Pod phase 变成 Succeeded
2. Pod 中只有一个容器并且正在运行。容器退出失败：
   • 记录失败事件
   • 如果 restartPolicy 为：
     • Always：重启容器，Pod phase 仍为 Running
     • OnFailure：重启容器，Pod phase 仍为 Running
     • Never：Pod phase 变成 Failed
3. Pod 中有两个容器并且正在运行：
   • 容器1退出失败
     • 记录失败事件
     • 如果 restartPolicy 为：
       • Always：重启容器，Pod phase 仍为 Running
       • OnFailure：重启容器，Pod phase 仍为 Running
       • Never：不重启容器，Pod phase 仍为 Running
   • 如果有容器1没有处于运行状态，并且容器2退出：
     • 记录失败事件
     • 如果 restartPolicy 为：
       • Always：重启容器，Pod phase 仍为 Running
       • OnFailure：重启容器，Pod phase 仍为 Running
       • Never：Pod phase 变成 Failed
4. Pod 中只有一个容器并处于运行状态。容器运行时内存超出限制：
   • 容器以失败状态终止
   • 记录 OOM 事件
   • 如果 restartPolicy 为：
     • Always：重启容器，Pod phase 仍为 Running
     • OnFailure：重启容器，Pod phase 仍为 Running
     • Never: 记录失败事件，Pod phase 仍为 Failed
5. Pod 正在运行，磁盘故障：
   • 杀掉所有容器
   • 记录适当事件
   • Pod phase 变成 Failed
   • 如果使用控制器来运行，Pod 将在别处重建
6. Pod 正在运行，其节点被分段：
   • 节点控制器等待直到超时
   • 节点控制器将 Pod phase 设置为 Failed
   • 如果是用控制器来运行，Pod 将在别处重建

Next：Pod Hook

Previous：安全策略

Home: pod