Kubernetes之Health Check

描述

强大的自愈能力是 Kubernetes 这类容器编排引擎的一个重要特性。自愈的默认实现方式是自动重启发生故障的容器。除此之外，用户还可以利用 Liveness 和 Readiness 探测机制设置更精细的健康检查，进而实现如下需求：

• 1.零停机部署。
• 2.避免部署无效的镜像。
• 3.更加安全的滚动升级。

默认健康检查

默认情况下，每个容器启动时都会执行一个进程，由Dockerfile中的CMD或ENTRYPOINT指定。如果进程退出时的返回码不为0，则认为容器发生了故障，K8S会根据重启策略（restartPolicy）重启容器。

Pod 的 restartPolicy 设置为 OnFailure，默认为 Always

例如下面这个例子，它模拟了容器发生故障的场景，注意下面配置文件中的args选项的定义：

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

其中 sleep 10; exit 1代表启动10秒之后发生故障就非正常退出（返回码不为0），然后通过kubectl创建Pod：

执行 kubectl apply 创建 Pod，命名为 health-check。

kubectl apply -f health-check.yaml
# pod "health-check" created

kubectl get pod health-check
# NAME          READY  STATUS   RESTART  AGE
# health-check  1/1    Running  3        2

可看到容器当前已经重启了 3 次。

在上面的例子中，容器进程返回值非零，Kubernetes 则认为容器发生故障，需要重启。

但有不少情况是发生了故障，但进程并不会退出。比如访问 Web 服务器时显示 500 内部错误，可能是系统超载，也可能是资源死锁，此时 httpd 进程并没有异常退出，在这种情况下重启容器可能是最直接最有效的解决方案，那我们如何利用 Health Check 机制来处理这类场景呢？

答案就是 Liveness 探测

LivenessProbe探测

用于判断容器是否存活（Running状态），如果LivenessProbe探针探测到容器不健康，则kubelet将杀掉该容器，并根据容器的重启策略做相应的处理，如果一个容器不包含LivenessProbe探针，那么kubelet认为该容器LivenessProbe探针返回的值永远是Success

一句话Liveness：如果检测有问题（如果健康检查失败），重启pod！至于怎么检测，你说了算（自定义判断容器是否健康的条件）

• 1.ExecAction

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

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; sleep 10; rm -rf /tmp/health; sleep 600
    livenessProbe:
      exec:
        command:
        - cat
        - /tmp/health
      initialDelaySeconds: 15
      timeoutSeconds: 1

• 2.TCPSocketAction

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

apiVersion: v1
kind: Pod
metadata:
  labels:
   test: liveness
  name: liveness-exec
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:
  labels:
   test: liveness
  name: liveness-exec
spec:
  containers:
  - name: nginx
    image: nginx
    ports:
    - containerPort: 80
    livenessProbe:
      httpGet:
        path: /_status/healthz
        port: 80
      initialDelaySeconds: 30
      timeoutSeconds: 1

Liveness提供了一些重要的参数

initialDelaySeconds：容器启动后第一次执行探测是需要等待多少秒,看运行的服务而定。
periodSeconds：      执行探测的频率，默认是10秒，最小1秒。
timeoutSeconds：     探测超时时间，默认1秒，最小1秒。
successThreshold：   探测失败后，最少连续探测成功多少次才被认定为成功，默认是1，对于liveness必须是1，最小值是1。
failureThreshold：   探测成功后，最少连续探测失败多少次才被认定为失败。默认是3。最小值是1.

ReadinessProbe探测

用于判断容器服务是否可用（Ready状态），达到Ready状态的Pod才可以接收请求。对于被service管理的Pod，Service与Pod Endpoint的关联关系也将基于Pod是否Ready进行设置。如果在运行过程中Ready状态变为False，则系统自动将其从service的后端Endpoint里表中隔离出去，后续再把恢复到Ready状态的Pod加回到后端Endpoint列表。这样就能保证客户端在访问service时不会被转发到服务不可用的Pod实例上

readinessProbe的配置语法与livenessProbe完全一致

Liveness与Readiness比较

下面对 Liveness 探测和 Readiness 探测做个比较

• 1.Liveness 探测和 Readiness 探测是两种 Health Check 机制，如果不特意配置，Kubernetes 将对两种探测采取相同的默认行为，即通过判断容器启动进程的返回值是否为零来判断探测是否成功。

• 2.两种探测的配置方法完全一样，支持的配置参数也一样。不同之处在于探测失败后的行为：Liveness 探测是重启容器；Readiness 探测则是将容器设置为不可用，不接收 Service 转发的请求。

• 3.Liveness 探测和 Readiness 探测是独立执行的，二者之间没有依赖，所以可以单独使用，也可以同时使用。

• 4.用 Liveness 探测判断容器是否需要重启以实现自愈；
  用 Readiness 探测判断容器是否已经准备好对外提供服务。
  Readiness 可用于指定容器启动1分后，判断容器各服务是否已正常启动（如启动脚本执行后写指定内容至特定文件）

Liveness与Readiness是独立执行的，二者无依赖，可以单独使用也可以同时使用

Liveness 和 Readiness 共用的情况

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

在Rolling Update中的应用

现在有一个正常运行的多副本应用，我们要对其进行滚动更新即Rolling Update，K8S会逐步用新Pod替换旧Pod，结果就有可能发生这样的一个场景：当所有旧副本被替换之后，而新的Pod由于人为配置错误一直无法启动，因此整个应用将无法处理请求，无法对外提供服务，后果很严重！

因此，Readiness探测还提供了用于避免滚动更新中出现这种情况的一些解决办法，比如maxSurge和maxUnavailable两个参数，用来控制副本替换的数量。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: edc-webapi-deployment
  namespace: aspnetcore
spec:
  strategy:
    rollingupdate:
      maxSurge: 25%
      maxUnavailable: 25%
  replicas: 10
  selector:
    matchLabels:
      name: edc-webapi
  template:
    metadata:
      labels:
        name: edc-webapi
    spec:
      containers:
      - name: edc-webapi-container
        image: edisonsaonian/k8s-demo:1.2
        ports:
        - containerPort: 80
        imagePullPolicy: IfNotPresent
        readinessProbe:
          httpGet:
            scheme: HTTP
            path: /api/health
            port: 80
          initialDelaySeconds: 10
          periodSeconds: 5

---

apiVersion: v1
kind: Service
metadata:
  name: edc-webapi-service
  namespace: aspnetcore
spec:
  type: NodePort
  ports:
    - nodePort: 31000 
      port: 8080
      targetPort: 80
  selector:
    name: edc-webapi

• (1) maxSurge : 25% => 控制滚动更新过程中副本总数超过预期（这里预期是10个副本 replicas: 10）的上限，可以是数值也可以是百分比，然后向上取整。这里写的百分比，默认值是25%；

如果预期副本数为10，那么副本总数的最大值为RoundUp(10 + 10 * 25%)=13个。

• (2) maxUnavailable : 25% => 控制滚动更新过程中不可用的副本（这里预期是10个副本 replicas: 10）占预期的最大比例，可以是数值也可以是百分比，然后向下取整，同样地默认值也是25%；

如果预期副本总数为10，那么可用的副本数至少要为10-roundDown(10 * 25%)=10-2=8个。

综上看来，maxSurge的值越大，初始创建的新副本数量就越多；maxUnavaliable值越大，初始销毁的旧副本数量就越多；

如果滚动更新失败，可以通过 kubectl rollout undo 回滚到上一个版本。

kubectl rollout history deployment edc-webapi-deployment

本章我们讨论了 Kubernetes 健康检查的两种机制：Liveness 探测和 Readiness 探测，并实践了健康检查在 Scale Up 和 Rolling Update 场景中的应用