1. health check健康检查

每个容器启动时都会执行一个进程，此进程由 Dockerfile 的 CMD 或 ENTRYPOINT 指定。如果进程退出时返回码非零，则认为容器发生故障，Kubernetes 就会根据 restartPolicy 重启策略来重启容器。

示例：

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: healthcheck
  name: healthcheck
spec:
  restartPolicy: OnFailure
  containers:
  - name: healthcheck
    image: busybox
    args:
    - /bin/sh
    - -c
    - sleep 10; exit 1

说明：

restartPolicy 设置为 OnFailure，默认为 Always

sleep 10; exit 1 模拟容器启动 10 秒后发生故障

2. 检测类型

Probe检测机制有以下两种类型：

• livenessProbe(存活探针)

  如果检查失败，将杀死容器，根据Pod的restartPolicy来操作。用指定的方式进入容器检测容器中的应用是否正常运行。

• readinessProbe(就绪探针)

  如果检查失败，Kubernetes会把Pod从service endpoints中剔除。用于判断容器中应用是否启动完成，防止将流量转发到不可用的 Pod上。

Liveness 探测和 Readiness 探测对比：

• 是两种 Health Check 机制，如果不特意配置，Kubernetes 将对两种探测采取相同的默认行为，即通过判断容器启动进程的返回值是否为零来判断探测是否成功。
• 两种探测的配置方法完全一样，支持的配置参数也一样。不同之处在于探测失败后的行为：Liveness 探测是重启容器；Readiness 探测则是将容器设置为不可用，不接收 Service 转发的请求。
• 两种探测方法都是独立执行的，二者之间没有依赖，所以可以单独使用，也可以同时使用。用 Liveness 探测判断容器是否需要重启以实现自愈；用 Readiness 探测判断容器是否已经准备好对外提供服务。

3. 检测方式

有以下三种检查方式：

• httpGet

  发送HTTP请求，返回200-400范围状态码为成功。

• exec

  执行Shell命令返回状态码是0为成功。

• tcpSocket

  通过容器的 IP 地址和端口号发起TCP Socket连接，检查是否建立成功。

livenessProbe示例：

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

说明：

启动进程首先创建文件 /tmp/healthy，30 秒后删除，在我们的设定中，如果 /tmp/healthy 文件存在，则认为容器处于正常状态，反正则发生故障。

livenessProbe 部分定义如何执行 Liveness 探测：

探测的方法是exec方式：通过 cat 命令检查 /tmp/healthy 文件是否存在。如果命令执行成功，返回值为零，Kubernetes 则认为本次 Liveness 探测成功；如果命令返回值非零，本次 Liveness 探测失败。

initialDelaySeconds: 10 指定容器启动 10 秒之后开始执行 Liveness 探测，我们一般会根据应用启动的准备时间来设置。比如某个应用正常启动要花 30 秒，那么 initialDelaySeconds 的值就应该大于 30。

periodSeconds: 5 指定每 5 秒执行一次 Liveness 探测。Kubernetes 如果连续执行 3 次 Liveness 探测均失败，则会杀掉并重启容器。

readinessProbe示例：

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: readiness
  name: readiness
spec:
  restartPolicy: OnFailure
  containers:
  - name: readiness
    image: busybox
    args:
    - /bin/sh
    - -c
    - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600
      readinessProbe:
      exec:
        command:
        - cat
        - /tmp/healthy
          initialDelaySeconds: 10
          periodSeconds: 5

说明：

Pod readiness 的 READY 状态经历了如下变化：

• 刚被创建时，READY 状态为不可用。
• 15 秒后（initialDelaySeconds + periodSeconds），第一次进行 Readiness 探测并成功返回，设置 READY 为可用。
• 30 秒后，/tmp/healthy 被删除，连续 3 次 Readiness 探测均失败后，READY 被设置为不可用。

4. health check在业务场景中的应用

4.1 在scale up扩容中使用health check

对于多副本应用，当执行 Scale Up 操作时，新副本会作为 backend 被添加到 Service 的负载均衡中，与已有副本一起处理客户的请求。考虑到应用启动通常都需要一个准备阶段，比如加载缓存数据，连接数据库等，从容器启动到真正能够提供服务是需要一段时间的。我们可以通过 Readiness 探测判断容器是否就绪，避免将请求发送到还没有 ready 的 backend。

示例：

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 3
  template:
    metadata:
      labels:
        run: web
    spec:
      containers:
   - name: web
     image: myhttpd
     ports:
     - containerPort: 8080
       readinessProbe:
       httpGet:
         scheme: HTTP
         path: /healthy
         port: 8080
       initialDelaySeconds: 10
          periodSeconds: 5
---

apiVersion: v1
kind: Service
metadata:
  name: web-svc
spec:
  selector:
    run: web
  ports:
  - protocol: TCP
    prot: 8080
    targetPort: 80

说明：

readinessProbe检测部分：schema 指定协议，支持HTTP(默认值)和HTTPS；path 指定访问路径；port 指定端口

容器启动 10 秒之后开始探测。

如果 http://[container_ip]:8080/healthy 返回代码不是 200-400，表示容器没有就绪，不接收 Service web-svc 的请求。

每隔 5 秒再探测一次。 直到返回代码为 200-400，表明容器已经就绪，然后将其加入到 web-svc 的负载均衡中，开始处理客户请求。

探测会继续以 5 秒的间隔执行，如果连续发生 3 次失败，容器又会从负载均衡中移除，直到下次探测成功重新加入。

4.2 在Rolling Update滚动更新中使用health check

现有一个正常运行的多副本应用，接下来对应用进行更新（比如使用更高版本的 image），Kubernetes 会启动新副本，然后发生了如下事件：

正常情况下新副本需要 10 秒钟完成准备工作，在此之前无法响应业务请求。

但由于人为配置错误，副本始终无法完成准备工作（比如无法连接后端数据库）。

因为新副本本身没有异常退出，默认的 Health Check 机制会认为容器已经就绪，进而会逐步用新副本替换现有副本，其结果就是：当所有旧副本都被替换后，整个应用将无法处理请求，无法对外提供服务。如果这是发生在重要的生产系统上，后果会非常严重。

如果正确配置了 Health Check，新副本只有通过了 Readiness 探测，才会被添加到 Service；如果没有通过探测，现有副本不会被全部替换，业务仍然正常进行。