Pod健康检查

对Pod的健康状态检查可以通过两类探针来检查：LivenessProbe和ReadinessProbe。
LivenessProbe探针：用于判断容器是否存活（running状态），如果LivenessProbe探针探测到容器不健康，
　　则kubelet将杀掉该容器，并根据容器的重启策略做相应的处理。
　　如果一个容器不包含LivenessProbe探针，那么kubelet认为该容器的LivenessProbe探针返回的值永远是“Success”。

ReadinessProbe探针：用于判断容器服务是否可用（ready状态），可以接收请求。
　　如果Readiness探针检测到失败，则Pod的状态将被修改。
　　Endpoint Controller将从Service的Endpoint中删除包含该容器所在Pod的Endpoint。


kubelet定期执行LivenessProbe探针来诊断容器的健康状况。LivenessProbe有以下三种实现方式。

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

apiVersion: v1  #required
kind: Pod       #required
metadata:       #required
  labels:
    test: liveness
  name: liveness-exec  #required
spec:
  containers:
  - name: liveness
    image: centos
    imagePullPolicy: IfNotPresent
    args:
    - /bin/sh
    - -c
    - echo ok > /tmp/health; sleep 10; rm -rf /tmp/health; sleep 600
    livenessProbe:  #探针配置
      exec:  #类型
        command:  #探针需要执行的命令
        - cat
        - /tmp/health
      initialDelaySeconds: 15  #初次探测时间为15秒
      timeoutSeconds: 1

通过执行cat /tmp/health命令来判断一个容器是否在运行。
在运行10秒之后会删除这个文件，15秒之后探测的结果将会去是Fail，
Kubelet将会杀死该容器并且重启它。

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

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

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

apiVersion: v1
kind: Pod
metadata:
  name: liveness-http
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会认为容器已经无法提供服务，将重启该容器。

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
    status: "True"
    lastProbeTime: null
    lastTransitionTime: 2018-01-01T00:00:002
  - type: "www.example.com/feature-1"
    status: "False"
    lastProbeTime: null
    lastTransitionTime: 2019-03-01T00:00:00z
  containerStatus:
  - containerID: docker://abcd...
    ready: true

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