kubernetes健康检查配置解析

Posted 2023-04-01 傻啦猫@_@

一、健康检查种类

在kubernetes中，经常会看到健康检查相关的配置。一般有两种健康检查方式：存活性健康检查和可用性健康检查，也叫做存活探针（livenessProbe）或者就绪探针（readinessProbe）。

livenessProbe探测应用是否处于健康状态，如果不健康会杀掉容器并根据容器策略决定是否重启容器。

readinessProbe探测应用是否就绪并处于正常服务的状态，探测失败后隔离服务（不分配流量）。

startupProbe用于容器启动时判断容器是否启动完成，在这个探针探测成功前，即容器启动成功前，livenessProbe和readinessProbe探针都不会起作用，防止某些启动很慢的容器在启动过程中被检测。

在实际的使用中只需要配置livenessProbe和readinessProbe，通过一段工作中使用到的配置给大家作以说明。

livenessProbe:
  failureThreshold: 3
  httpGet:
    path: /sams/webapi/health
    port: 19201
    scheme: HTTP
  initialDelaySeconds: 120
  periodSeconds: 20
  successThreshold: 1
  timeoutSeconds: 30
readinessProbe:
  failureThreshold: 3
  httpGet:
    path: /sams/webapi/health
    port: 19201
    scheme: HTTP
  initialDelaySeconds: 120
  periodSeconds: 20
  successThreshold: 1
  timeoutSeconds: 30

二、字段含义

从yaml配置可以看出，livenessProbe和readinessProbe配置基本相似，每个字段所表示的含义也相同。

字段	含义
ailureThreshold	不正常阈值。检测失败次数超过此值表示容器不健康（默认3次）
httpGet	采用http健康检查的方式
path	服务器上的访问URI
port	容器上要访问端口号
scheme	用于连接host的协议（HTTP或HTTPS），默认为HTTP
initialDelaySeconds	等待时间。从容器启动开始算起到检查开始时间差
periodSeconds	每次探测时间间隔（默认10秒）
successThreshold	正常阈值，失败后检查成功的最小次数，即从错误到正确要多少次表示健康（默认1次）
timeoutSeconds	探测超时时间（默认1秒）
httpHeaders	自定义请求头

三、三种检查方式

kubernetes中每种健康检查有三种方式。上面示例中采用的是httpGet的方式，其他两种为TCP和EXEC。

区别：

http（httpGet）检查方式会向容器中运行的服务发送HTTP GET请求，返回任何大于等于200且小于400的值，均表示健康，反之为不健康。

TCP（tcpSocket）检查方式将连接到容器的某个端口（port），如果探测成功，返回值为0，则该容器是健康的，反之为不健康。

EXEC检查方式会在容器中执行特定的命令（command），如果命令执行成功，则返回0，那么就认为容器是健康的，反之为不健康。

检查结果：

对于两种健康检查方式，有三种检查结果。

结果	含义
Success	通过了检查
Failure	未通过检查
Unknown	未能进行检查，因此不采取任何措施

# 可以通过事件查看检查结果。
[root@k8s-master test]# kubectl describe pod nginx-deploy-db66ff67c-kt4dx
...
Events:
  Type     Reason     Age                From               Message
  ----     ------     ----               ----               -------
  Normal   Scheduled  68s                default-scheduler  Successfully assigned default/nginx-deploy-db66ff67c-kt4dx to k8s-worker2
  Normal   Pulled     23s (x3 over 67s)  kubelet            Container image "nginx" already present on machine
  Normal   Created    23s (x3 over 67s)  kubelet            Created container mynginx
  Normal   Started    23s (x3 over 67s)  kubelet            Started container mynginx
  Normal   Killing    23s (x2 over 43s)  kubelet            Container mynginx failed liveness probe, will be restarted
  Warning  Unhealthy  12s (x6 over 57s)  kubelet            Readiness probe failed: dial tcp 192.168.126.4:8000: connect: connection refused
  Warning  Unhealthy  8s (x8 over 53s)   kubelet            Liveness probe failed: dial tcp 192.168.126.4:8000: connect: connection refused
[root@k8s-master test]#

四、验证测试

1. livenessProbe探测应用是否处于健康状态，如果不健康会杀掉容器并根据容器策略决定是否重启容器。

# deployment.yaml 部署应用
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx-deploy
  name: nginx-deploy
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx-deploy
  template:
    metadata:
      labels:
        app: nginx-deploy
    spec:
      restartPolicy: Always
      containers:
        - name: mynginx
          image: nginx
          imagePullPolicy: IfNotPresent
          ports:
          - containerPort: 80
          livenessProbe:
            failureThreshold: 3
            httpGet:
              path: /index.html
              port: 80
              scheme: HTTP
            initialDelaySeconds: 10
            periodSeconds: 5
            successThreshold: 1
            timeoutSeconds: 5

[root@k8s-master test]# kubectl apply -f deployment.yaml 
deployment.apps/nginx-deploy created
[root@k8s-master test]# kubectl get pod
NAME                          READY   STATUS    RESTARTS   AGE
nginx-deploy-95b59f7f-56mmx   1/1     Running   0          6s
nginx-deploy-95b59f7f-vzdsk   1/1     Running   0          6s
[root@k8s-master test]# 

# 创建service
[root@k8s-master ~]# kubectl expose deployment nginx-deploy --port=8000 --target-port=80
service/nginx-deploy exposed
[root@k8s-master test]# kubectl get svc
NAME           TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)    AGE
kubernetes     ClusterIP   10.96.0.1      <none>        443/TCP    9d
nginx-deploy   ClusterIP   10.96.123.93   <none>        8000/TCP   35m

# 进入pod修改index.html
[root@k8s-master test]# kubectl exec -it nginx-deploy-95b59f7f-56mmx -c mynginx -- /bin/bash
root@nginx-deploy-95b59f7f-56mmx:/# cd /usr/share/nginx/html/
root@nginx-deploy-95b59f7f-56mmx:/usr/share/nginx/html# echo 111 > index.html 
root@nginx-deploy-95b59f7f-56mmx:/usr/share/nginx/html# 

# 将两个pod的index.html改为111和222。

将其中一个index.html删除，会发生重启。

2. dinessProbe探测应用是否就绪并处于正常服务的状态，探测失败后隔离服务。

# deployment.yaml 部署应用
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx-deploy
  name: nginx-deploy
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx-deploy
  template:
    metadata:
      labels:
        app: nginx-deploy
    spec:
      restartPolicy: Always
      containers:
        - name: mynginx
          image: nginx
          imagePullPolicy: IfNotPresent
          ports:
          - containerPort: 80
          readinessProbe:
            failureThreshold: 3
            httpGet:
              path: /index.html
              port: 80
              scheme: HTTP
            initialDelaySeconds: 10
            periodSeconds: 5
            successThreshold: 1
            timeoutSeconds: 5

[root@k8s-master test]# kubectl apply -f deployment.yaml 
deployment.apps/nginx-deploy created
[root@k8s-master test]# kubectl get pod
NAME                            READY   STATUS    RESTARTS   AGE
nginx-deploy-5999b7b675-fq7cm   1/1     Running   0          22s
nginx-deploy-5999b7b675-lws9w   1/1     Running   0          22s

# 进入pod修改index.html
[root@k8s-master test]# kubectl exec -it nginx-deploy-5999b7b675-fq7cm -c mynginx -- /bin/bash
root@nginx-deploy-5999b7b675-fq7cm:/# cd /usr/share/nginx/html/
root@nginx-deploy-5999b7b675-fq7cm:/usr/share/nginx/html# ls
50x.html  index.html
root@nginx-deploy-5999b7b675-fq7cm:/usr/share/nginx/html# echo 111 > index.html 
root@nginx-deploy-5999b7b675-fq7cm:/usr/share/nginx/html# 

# 将两个pod的index.html改为111和222。

将其中一个index.html删除，容器不会重启，但是不会在接收流量（被隔离）。

TCP和EXEC使用类似的方法验证即可。

六、梳理总结

存活性健康检查在检测失败后杀死容器，可用性健康检查失败后隔离服务（不分配流量）。容器是否重启由容器的重启策略restartPolicy决定的。

三种检查方式配置类似，区别在于方式的不同。HTTP为httpGet，TCP为tcpSocket，EXEC为exec（command）。

如果一个容器不包含存活探针，则Kubelet认为容器的存活探针的返回值永远成功，即永远不会重启。

七、扩展

1. 容器启动策略（restartPolicy）

策略	含义
Always	总是重启容器（默认）
OnFailure	容器终止运行且退出码不为0时重启
Never	不论状态如何，都不重启

2. HTTP 配置示例

livenessProbe:
  failureThreshold: 3
  httpGet:
    path: /index.html
    port: 80
    scheme: HTTP
  initialDelaySeconds: 10
  periodSeconds: 5
  successThreshold: 1
  timeoutSeconds: 5
readinessProbe:
  failureThreshold: 3
  httpGet:
    path: /index.html
    port: 80
    scheme: HTTP
  initialDelaySeconds: 10
  periodSeconds: 5
  successThreshold: 1
  timeoutSeconds: 5

3. TCP 配置示例

livenessProbe:
  failureThreshold: 3
  tcpSocket:
    port: 80
  initialDelaySeconds: 10
  periodSeconds: 5
  successThreshold: 1
  timeoutSeconds: 5
readinessProbe:
  failureThreshold: 3
  tcpSocket:
    port: 80
  initialDelaySeconds: 10
  periodSeconds: 5
  successThreshold: 1
  timeoutSeconds: 5

4. EXEC 配置示例

livenessProbe:
  failureThreshold: 3
  exec:
    command:
    - cat
    - /usr/share/nginx/html/index.html
  initialDelaySeconds: 10
  periodSeconds: 5
  successThreshold: 1
  timeoutSeconds: 5
readinessProbe:
  failureThreshold: 3
  exec:
    command:
    - cat
    - /usr/share/nginx/html/index.html
  initialDelaySeconds: 10
  periodSeconds: 5
  successThreshold: 1
  timeoutSeconds: 5

本文由mdnice多平台发布