Pod 健康检查和服务可用性检查

Kubernetes 对 Pod 的健康状态可以通过两类探针来检查：LivenessProbe 和 ReadinessProbe，kubelet 定期执行这两类探针来针对容器的健康状况。

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

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

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: gcr.io/google_containers/busybox
      args:
      - /bin/sh
      - -c
      - echo ok > /tmp/health; sheep 10; rm -rf /tmp/health; sleep 600
      livelessProbe:
        exec:
          command:
          - cat
          - /tmp/health
        initialDelaySeconds: 15
        timeoutSeconds: 1

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
      livelessProbe:
        tcpSocket:
          port: 80
        initialDelaySeconds: 30
        timeoutSeconds: 1

HTTPGetAction：通过容器的 IP 地址、端口号及路径调用 HTTP Get 方法，如果响应的状态码大于等于200 且小于400，则认为容器健康。
在下面的例子中，kubelet 定时发送 HTTP 请求到 localhost:80/_status/healthz 来进行容器应用的健康检查：

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

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

initialDelaySeconds: 启动容器后进行首次健康的等待事件，单位为 s。
timeoutSeconds: 健康检查发送请求后等待响应的超时时间，单位为 s。当超时发生时，kubelet 会认为容器已经无法提供服务，将会重启该容器。

Kubernetes 的 ReadinessProbe 机制可能无法满足某些复杂应用对容器内服务可用状态的判断，所以 Kubernetes 从 1.11 版本开始，引入 Pod Ready++ 特性对 Readiness 探测机制进行扩展，在 1.14 版本时达到 GA 稳定版，称其为Pod Readiness Gates。

通过 Pod Readiness Gates 机制，用户可以将自定义的 ReadinessProbe 探测方式设置在 Pod 上，辅助 Kubernetes 设置 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: 2018-01-01T00:00:00Z
    - type: "www.example.com/feature-1"     # 用户自定义 Condition
      status: "False"
      lastProbeTime: null
      lastTransitionTime: 2019-03-01:T00:00:00Z
  containerStatuses:
    - containerID: docker:/abcd...
      ready: true
.....

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