kubernetes之配置保活探针与就绪探针

参考：https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/

在kubernetes中，kubelet通过liveness探针决定在何时重新启动容器。例如，容器中的应用运行时进入死锁状态，liveness探针对容器进行健康检查时检测到这种情况，那么探针检测失败，则kubelet就会重新启动容器。可以看到重新启动并没有从根本上解决死锁问题，只是忽略了问题使容器继续运行。

kubelet通过readiness类型的探针决定container是否准备就绪处理流量，当pod中的所有container全部处于ready状态时，pod被认为可以对外提供服务。readiness探针的典型应用是控制pod是否作为service的backend。以下示例中都没有为容器指定"restart policy"，所以均采用默认值"Always"。

Define a liveness command

有些程序因为长时间运行而进入崩坏的状态，其中的一个解决办法是重新启动，liveness探针专门用来解决此类问题。

下例是运行一个容器的pod，容器image是k8s.gcr.io/busybox，配置文件如下：

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-exec
spec:
  containers:
  - name: liveness
    image: k8s.gcr.io/busybox
    args:
    - /bin/sh
    - -c
    - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600
    livenessProbe:
      exec:
        command:
        - cat
        - /tmp/healthy
      initialDelaySeconds: 5
      periodSeconds: 5

从以上配置文件看出，pod包含一个容器。每隔 periodSeconds秒执行一次liveness探针诊断，initialDelaySeconds表示kubelet在启动容器后首次执行探针诊断的延迟时间。探针的具体实现是在容器内部执行cat /tmp/healthy命令，如果命令退出码是0表示容器存活健康，如果非0则kubelet重新启动容器。

容器启动以后执行如下指令：

/bin/sh -c "touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600"

创建pod：

kubectl create -f https://k8s.io/examples/pods/probe/exec-liveness.yaml

 在30秒之内查看pod事件：

kubectl describe pod liveness-exec

输出如下：

FirstSeen    LastSeen    Count   From            SubobjectPath           Type        Reason      Message
--------- --------    -----   ----            -------------           --------    ------      -------
24s       24s     1   {default-scheduler }                    Normal      Scheduled   Successfully assigned liveness-exec to worker0
23s       23s     1   {kubelet worker0}   spec.containers{liveness}   Normal      Pulling     pulling image "k8s.gcr.io/busybox"
23s       23s     1   {kubelet worker0}   spec.containers{liveness}   Normal      Pulled      Successfully pulled image "k8s.gcr.io/busybox"
23s       23s     1   {kubelet worker0}   spec.containers{liveness}   Normal      Created     Created container with docker id 86849c15382e; Security:[seccomp=unconfined]
23s       23s     1   {kubelet worker0}   spec.containers{liveness}   Normal      Started     Started container with docker id 86849c15382e

 35秒以后，再次查看pod事件，输出如下：

FirstSeen LastSeen    Count   From            SubobjectPath           Type        Reason      Message
--------- --------    -----   ----            -------------           --------    ------      -------
37s       37s     1   {default-scheduler }                    Normal      Scheduled   Successfully assigned liveness-exec to worker0
36s       36s     1   {kubelet worker0}   spec.containers{liveness}   Normal      Pulling     pulling image "k8s.gcr.io/busybox"
36s       36s     1   {kubelet worker0}   spec.containers{liveness}   Normal      Pulled      Successfully pulled image "k8s.gcr.io/busybox"
36s       36s     1   {kubelet worker0}   spec.containers{liveness}   Normal      Created     Created container with docker id 86849c15382e; Security:[seccomp=unconfined]
36s       36s     1   {kubelet worker0}   spec.containers{liveness}   Normal      Started     Started container with docker id 86849c15382e
2s        2s      1   {kubelet worker0}   spec.containers{liveness}   Warning     Unhealthy   Liveness probe failed: cat: can't open '/tmp/healthy': No such file or directory

发现探针诊断失败事件，此时容器被重新启动，再等待30秒，确定容器被重启：

kubectl get pod liveness-exec

 输出结果：

NAME            READY     STATUS    RESTARTS   AGE
liveness-exec   1/1       Running   1          1m

restart次数被加1。

Define a liveness HTTP request 

以下是HTTP GET类型的liveness探针示例，pod包含一个容器，image是k8s.gcr.io/liveness：

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-http
spec:
  containers:
  - name: liveness
    image: k8s.gcr.io/liveness
    args:
    - /server
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
        httpHeaders:
        - name: X-Custom-Header
          value: Awesome
      initialDelaySeconds: 3
      periodSeconds: 3

 注意探针中path、port、httpHeader的配置，kubelet通过这些信息，构建http get请求，并通过kuelet运行的网络将请求发送到容器的指定端口、路径上。当应答状态码大于等于200小于400时表示探针诊断通过，其它状态码表示失败。kubelet杀死容器然后重新启动。

Define a TCP liveness probe

TCP类型是最简单的探针，kubelet尝试打开容器上的某个端口，如果连接成功建立则诊断通过，否则失败，示例配置如下：

apiVersion: v1
kind: Pod
metadata:
  name: goproxy
  labels:
    app: goproxy
spec:
  containers:
  - name: goproxy
    image: k8s.gcr.io/goproxy:0.1
    ports:
    - containerPort: 8080
    readinessProbe:
      tcpSocket:
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 10
    livenessProbe:
      tcpSocket:
        port: 8080
      initialDelaySeconds: 15
      periodSeconds: 20

Use a named port 

在定义探针时使用命名端口，示例如下：

ports:
- name: liveness-port
  containerPort: 8080
  hostPort: 8080

livenessProbe:
  httpGet:
    path: /healthz
    port: liveness-port

Define readiness probes

容器有时候会暂时无法对外提供服务，比如容器在启动阶段需要下载大量数据配置文件等，此时容器无法对外提供服务但又不能杀死它，而用户也希望此时容器不要授受来自service的流量 ，readiness类型探针专门处理此种情况。

readiness probe与liveness probe的配置类似，唯一不同的只是字段名称，将livenessProbe换成readinessProbe，如下：

readinessProbe:
  exec:
    command:
    - cat
    - /tmp/healthy
  initialDelaySeconds: 5
  periodSeconds: 5

 readiness probe暂时阻止pod成为service的backend，当诊断通过时再将pod加入到相应service的后端。liveness探针影响的是单个容器，但readiness探针影响的是整个pod，即如果pod中有多个容器，只要有一个容器的readiness探针诊断失败，那么整个pod都会处于unready状态。