K8S中的Health Check

K8S中的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 场景中的应用

留下评论