Pod健康检查

畅云客

已于 2024-05-07 11:33:16 修改

阅读量678

点赞数 15

分类专栏：容器文章标签：运维 kubernetes docker 容器 linux

于 2024-05-07 11:33:04 首次发布

本文链接：https://blog.csdn.net/qq_33906471/article/details/138525528

版权

容器专栏收录该内容

37 篇文章 1 订阅

订阅专栏

介绍

在Kubernetes集群当中，我们可以通过配置liveness probe（存活探针）和readiness probe（可读性探针）来影响容器的生存周期。

目前LivenessProbe和ReadinessProbe两种探针都支持下面三种探测方法

ExecAction：在容器中执行指定的命令，如果执行成功，退出码为 0 则探测成功

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

HTTPGetAction：通过容器的IP地址、端口号及路径调用 HTTP Get方法，如果响应的状态码大于等于200且小于400，则认为容器健康。

探针探测结果有以下值

Success：表示通过检测

Failure：表示未通过检测

Unknown：表示检测没有正常进行

Pod探针相关的属性：探针(Probe)有许多可选字段，可以用来更加精确的控制Liveness和Readiness两种探针的行为

initialDelaySeconds： Pod启动后首次进行检查的等待时间，单位“秒”。

periodSeconds：检查的间隔时间，默认为10s，单位“秒”。

timeoutSeconds：探针执行检测请求后，等待响应的超时时间，默认为1s，单位“秒”。

successThreshold：连续探测几次成功，才认为探测成功，默认为 1，在 Liveness 探针中必须为1，最小值为1。

failureThreshold：探测失败的重试次数，重试一定次数后将认为失败，在 readiness 探针中，Pod会被标记为未就绪，默认为 3，最小值为 1

livenessProbe：存活性探测

许多应用程序经过长时间运行，最终过渡到无法运行的状态，除了重启，无法恢复。通常情况下，K8S会发现应用程序已经终止，然后重启应用程序pod。有时应用程序可能因为某些原因（后端服务故障等）导致暂时无法对外提供服务，但应用软件没有终止，导致K8S无法隔离有故障的pod，调用者可能会访问到有故障的pod，导致业务不稳定。K8S提供livenessProbe来检测容器是否正常运行，并且对相应状况进行相应的补救措施。

# 该资源清单定义了livenessProbe，启动后10秒在进行检查，每隔3秒检测一次
# 检测失败就会重启pod
[root@master ~]# cat nginx_livenessProbe.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  restartPolicy: Always
  containers:
  - name: test-nginx
    image: nginx
    imagePullPolicy: IfNotPresent
    args:
    - /bin/sh
    - -c
    - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600
    livenessProbe:
      initialDelaySeconds: 10
      periodSeconds: 3
      exec:
        command:
        - cat
        - /tmp/healthy

# 部署资源
[root@master ~]# kubectl apply -f nginx_livenessProbe.yaml 
pod/nginx created

# 检测失败就会重启pod，可以查看RESTARTS了解重启次数
[root@master ~]# kubectl get pod
NAME    READY   STATUS    RESTARTS      AGE
nginx   1/1     Running   3 (13s ago)   3m40s

readinessProbe：就绪性探测

在没有配置readinessProbe的资源对象中，pod中的容器启动完成后，就认为pod中的应用程序可以对外提供服务，该pod就会加入相对应的service，对外提供服务。但有时一些应用程序启动后，需要较长时间的加载才能对外服务，如果这时对外提供服务，执行结果必然无法达到预期效果，影响用户体验。比如使用tomcat的应用程序来说，并不是简单地说tomcat启动成功就可以对外提供服务的，还需要等待spring容器初始化，数据库连接上等等

# 该资源清单定义了readinessProbe，启动后20秒在进行检查
# 每隔5秒检测一次80端口的/index.html页面，设置10秒超时
# 检测失败，该pod就不能提供服务
[root@master ~]# cat nginx_readinessProbe.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
    ports:
    - name: server
      containerPort: 80
    - name: management
      containerPort: 81
    readinessProbe:
      initialDelaySeconds: 20   
      periodSeconds: 5          
      timeoutSeconds: 10   
      httpGet:
        scheme: HTTP
        port: 80
        path: /index.html
[root@master ~]# kubectl apply -f nginx_readinessProbe.yaml 
pod/nginx created

# 把pod的index.html页面删除发现pod的就绪状态就变了
[root@master ~]# kubectl exec -it nginx -- rm -rf /usr/share/nginx/html/index.html
[root@master ~]# kubectl get pod
NAME    READY   STATUS    RESTARTS   AGE
nginx   0/1     Running   0          101s