K8s新手系列之探针

概述

官方文档：

• https://kubernetes.io/zh-cn/docs/concepts/configuration/liveness-readiness-startup-probes/
  
• https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/
  

容器探测用于检测容器中的应用实例是否正常工作，是保障业务可用性的一种传统机制。如果经过探测，实例的状态不符合预期，那么kubernetes就会把该Pod进行重启或者不承担业务流量。kubernetes提供了三种探针来实现容器探测，分别是：

• 存活探针（liveness probe）
  
• 就绪探针（readiness probe）
  
• 启动探针（startup probe）
  

探针的作用

自动恢复故障容器（存活探针）

作用：检测容器内应用是否处于崩溃、死锁或无响应状态，若检测失败则自动重启容器。
场景：

• 应用程序因内存泄漏导致无响应，但容器进程仍在运行。
  
• 数据库连接池耗尽，导致应用无法处理请求。
  

效果：无需人工干预，K8s 自动重启故障容器，提升系统可用性。
避免流量转发到未就绪容器（就绪探针）

作用：确保只有当容器完全准备好接收请求时，才会将流量分配给它。
场景：

• 容器启动后需要加载大量配置文件或预热缓存。
  
• 应用需要连接外部数据库或服务，连接建立前无法提供服务。
  

效果：防止客户端请求被转发到未完全启动的容器，减少请求失败率。
保护慢启动应用不被误杀（启动探针）

作用：为启动时间较长的应用提供专门的检测机制，避免存活探针过早触发重启。
场景：

• Java 应用启动时需要执行类加载和 JIT 编译，耗时较长。
  
• 数据密集型应用需要初始化大型数据集。
  

效果：避免因启动时间过长导致的频繁重启循环，节省系统资源。
实现滚动更新的平滑过渡

作用：在 Deployment 进行滚动更新时，就绪探针确保旧版本容器优雅下线，新版本容器完全就绪后再接收流量。
场景：微服务架构中，服务 A 更新时需要确保服务 B 不会调用到未就绪的 A 实例。
效果：减少服务更新过程中的请求失败率，实现无缝升级。
优化资源利用

作用：通过精准的健康检查，K8s 可以：

• 自动驱逐不可用的 Pod 并重新调度到健康节点。
  
• 在节点资源不足时，优先保留健康的容器，终止异常容器。
  

效果：提高集群资源利用率，降低运维成本。
探针的探测方式及配置参数

探测方式

探针可以通过以下几种方式执行检查：

• HTTP 请求（HTTPGetAction）：向容器发送 HTTP 请求，若返回状态码为 200-399，则表示检查成功。
  

1. po.spec.containers.livenessProbe.
2. httpGet:
3.     scheme: HTTP #支持的协议，http或者https
4.     port: 80 #端口号
5.     path: /hello #URI地址
6.     host: 127.0.0.1 #ip地址

复制代码

• TCP 连接（TCPSocketAction）：尝试与容器的指定端口建立 TCP 连接，若能成功连接，则检查通过。
  

1. po.spec.containers.livenessProbe.
2. tcpSocket:
3.     port: 8080 # 尝试访问8080端口

复制代码

• 命令执行（ExecAction）：在容器内执行指定命令，若命令退出状态码为 0，则检查成功。
  

1. po.spec.containers.livenessProbe.
2. exec:
3.     command:
4.         - cat
5.         - /etc/hosts

复制代码

配置参数

探针的核心配置参数如下：

• initialDelaySeconds：容器启动后等待多长时间再开始执行探针检查。
  
• periodSeconds：探针检查的执行间隔时间。
  
• timeoutSeconds：探针检查的超时时间。
  
• successThreshold：探针检查失败后，需要连续多少次检查成功才认为容器恢复正常。
  
• failureThreshold：探针检查成功后，需要连续多少次检查失败才认为容器出现问题。
  

存活探针（liveness probe）详解

在 Kubernetes（K8s）中，存活探针（Liveness Probe） 是用于监控容器内部应用是否处于健康运行状态的核心机制。当探测失败时，K8s 会自动重启容器，确保应用始终可用，如果容器没有提供健康状态检查，则默认为success
核心作用

• 检测应用无响应：当应用崩溃、死锁或进入不可恢复状态时触发重启。
  
• 自动恢复故障：无需人工干预，K8s 通过重启容器实现自愈。
  
• 提高可用性：确保 Pod 始终运行健康的容器实例。
  

HTTP探测实战（最常用）

向容器发送 HTTP 请求，若返回状态码为 200-399，则表示检查成功。

1. [root@master ~/probe]# cat liveness.yaml
2. kind: Pod
3. apiVersion: v1
4. metadata:
5.   name: nginx
6. spec:
7.   containers:
8.   - name: nginx
9.     image: nginx
10.     livenessProbe:
11.       httpGet:
12.         # http请求的端口
13.         port: 80
14.         # http请求的路径
15.         path: /
16.         # http请求的主机
17.         # host: 127.0.0.1
18.         # 请求方式
19.         scheme: HTTP
20.       # 超时时间，指定5秒
21.       timeoutSeconds: 5
22.       # 探针检查成功后，需要连续3次检查失败才认为容器出现问题
23.       failureThreshold: 3
24.       # 探针检查失败后，需要连续1次检查成功才认为容器恢复正常
25.       successThreshold: 1
26.       # 探针检查的执行间隔时间，指定3秒
27.       periodSeconds: 3
28.       # 容器启动后等待30秒再开始执行探针检查
29.       initialDelaySeconds: 30
31. [root@master ~/probe]# kubectl apply -f liveness.yaml
32. pod/nginx created
34. # 等待一段时间查看Pod的状态
35. [root@master ~/probe]# kubectl get po nginx
36. NAME    READY   STATUS    RESTARTS   AGE
37. nginx   1/1     Running   0          2m8s

复制代码

如果监测失败会发生什么呢？

修改一下请求路径

1. [root@master ~/probe]# cat liveness.yaml
2. kind: Pod
3. apiVersion: v1
4. metadata:
5.   name: nginx
6. spec:
7.   containers:
8.   - name: nginx
9.     image: nginx
10.     livenessProbe:
11.       httpGet:
12.         port: 80
13.         # http请求的路径未/test，在nginx容器中，改路径应该会返回404状态码
14.         path: /test
15.         scheme: HTTP
16.       timeoutSeconds: 5
17.       failureThreshold: 3
18.       successThreshold: 1
19.       periodSeconds: 3
20.       initialDelaySeconds: 30
22. [root@master ~/probe]# kubectl apply -f liveness.yaml
23. pod/nginx created
25. # 稍微等待一会，查看Pod的状态，发现RESTARTS次数已经为1了，这里表示容器的重启次数
26. [root@master ~/probe]# kubectl get po
27. NAME             READY   STATUS    RESTARTS     AGE
28. nginx            1/1     Running   1 (8s ago)   48s

复制代码

Exec探测实战

在容器内执行指定shell命令，若命令退出状态码为 0，则检查成功。

1. [root@master ~/probe]# cat liveness.yaml
2. kind: Pod
3. apiVersion: v1
4. metadata:
5.   name: nginx
6. spec:
7.   containers:
8.   - name: nginx
9.     image: nginx
10.     livenessProbe:
11.       exec:
12.       # 指定shell命令，cat /etc/hosts
13.         command:
14.           - cat
15.           - /etc/hosts
16.       # 超时时间，指定5s
17.       timeoutSeconds: 5
18.       # 探针检查成功后，需要连续3次检查失败才认为容器出现问题
19.       failureThreshold: 3
20.       # 探针检查失败后，需要连续1次检查成功才认为容器恢复正常
21.       successThreshold: 1
22.       # 探针检查的执行间隔时间，指定3秒
23.       periodSeconds: 3
24.       # 容器启动后等待15秒再开始执行探针检查
25.       initialDelaySeconds: 15
27. [root@master ~/probe]# kubectl apply -f liveness.yaml
28. pod/nginx created
29. # 查看Pod的状态
30. [root@master ~/probe]# kubectl get po nginx
31. NAME    READY   STATUS    RESTARTS   AGE
32. nginx   1/1     Running   0          44s

复制代码

TCP探测方式实战

尝试与容器的指定端口建立 TCP 连接，若能成功连接，则检查通过。

1. [root@master ~/probe]# cat liveness.yaml
2. kind: Pod
3. apiVersion: v1
4. metadata:
5.   name: nginx
6. spec:
7.   containers:
8.   - name: nginx
9.     image: nginx
10.     livenessProbe:
11.       # 测试某个容器的TCP端口是否能够连通，类似于telnet nc工具
12.       tcpSocket:
13.         port: 80
14.       # 超时时间，指定5s
15.       timeoutSeconds: 5
16.       # 探针检查成功后，需要连续3次检查失败才认为容器出现问题
17.       failureThreshold: 3
18.       # 探针检查失败后，需要连续1次检查成功才认为容器恢复正常
19.       successThreshold: 1
20.       # 探针检查的执行间隔时间，指定3秒
21.       periodSeconds: 3
22.       # 容器启动后等待15秒再开始执行探针检查
23.       initialDelaySeconds: 15
25. [root@master ~/probe]# kubectl apply -f liveness.yaml
26. pod/nginx created
28. # 检查Pod的状态
29. [root@master ~/probe]# kubectl get po nginx
30. NAME    READY   STATUS    RESTARTS   AGE
31. nginx   1/1     Running   0          40s

复制代码

就绪探针（readiness probe）详解

在 Kubernetes（K8s）中，就绪探针（Readiness Probe） 是用于判断容器是否已准备好接收客户端请求的机制。当探测失败时，K8s 会将该容器从 Service 的 Endpoint 中暂时移除，直到探测成功为止。
核心作用

• 避免流量转发到未就绪容器：确保只有当容器完全准备好时，才会将流量分配给它。
  
• 支持优雅上线和下线：在容器启动、升级或重启过程中，防止客户端请求被转发到不可用的实例。
  
• 提升服务稳定性：减少因容器未完全初始化而导致的请求失败率。
  

HTTP探测实战（最常用）

向容器发送 HTTP 请求，若返回状态码为 200-399，则表示检查成功。
示例：创建Pod

1. [root@master ~/probe]# cat readiness.yaml
2. kind: Pod
3. apiVersion: v1
4. metadata:
5.   name: nginx
6.   labels:
7.     app: nginx
8. spec:
9.   containers:
10.   - name: nginx
11.     image: nginx
12.     readinessProbe:
13.       httpGet:
14.         # http请求的端口
15.         port: 80
16.         # http请求的路径
17.         path: /
18.         # http请求的主机
19.         # host: 127.0.0.1
20.         # 请求方式
21.         scheme: HTTP
22.       # 超时时间，指定5秒
23.       timeoutSeconds: 5
24.       # 探针检查成功后，需要连续3次检查失败才认为容器出现问题
25.       failureThreshold: 3
26.       # 探针检查失败后，需要连续1次检查成功才认为容器恢复正常
27.       successThreshold: 1
28.       # 探针检查的执行间隔时间，指定3秒
29.       periodSeconds: 3
30.       # 容器启动后等待15秒再开始执行探针检查
31.       initialDelaySeconds: 15
33. [root@master ~/probe]# kubectl apply -f readiness.yaml
34. pod/nginx created

复制代码

创建Service

1. [root@master ~/probe]# cat service.yaml
2. apiVersion: v1
3. kind: Service
4. metadata:
5.   name: nginx-service
6. spec:
7.   type: ClusterIP
8.   selector:
9.     # 选择标签为 app: nginx 的 Pod
10.     app: nginx
11.   ports:
12.     - name: http
13.       protocol: TCP
14.       # Service的端口
15.       port: 80
16.       # Pod 上的端口
17.       targetPort: 80
18. [root@master ~/probe]# kubectl apply -f service.yaml
19. service/nginx-service created

复制代码

检查Pod、Service、EndPoint资源，发现EndPoint关联的是Pod的IP，符合预期

1. [root@master ~/probe]# kubectl get po,svc,ep -o wide
2. NAME        READY   STATUS    RESTARTS   AGE    IP               NODE     NOMINATED NODE   READINESS GATES
3. pod/nginx   1/1     Running   0          4m2s   100.95.185.232   node02   <none>           <none>
5. NAME                    TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE    SELECTOR
6. service/nginx-service   ClusterIP   10.96.1.43   <none>        80/TCP    112s   app=nginx
8. NAME                      ENDPOINTS           AGE
9. endpoints/nginx-service   100.95.185.232:80   112s

复制代码

修改Pod的就绪探针

1. [root@master ~/probe]# cat readiness.yaml
2. kind: Pod
3. apiVersion: v1
4. metadata:
5.   name: nginx
6.   labels:
7.     app: nginx
8. spec:
9.   containers:
10.   - name: nginx
11.     image: nginx
12.     readinessProbe:
13.       httpGet:
14.         port: 80
15.         # http请求的路径，指定为/test，这里应该会返回404
16.         path: /test
17.         scheme: HTTP
18.       timeoutSeconds: 5
19.       failureThreshold: 3
20.       successThreshold: 1
21.       periodSeconds: 3
22.       initialDelaySeconds: 15
24. # 重新创建Pod
25. [root@master ~/probe]# kubectl apply -f readiness.yaml
26. pod/nginx created

复制代码

重新检查Pod、Service、EndPoint资源，发现EndPoint资源没有关联Pod的IP

1. [root@master ~/probe]# kubectl get po,svc,ep -o wide
2. NAME        READY   STATUS    RESTARTS   AGE    IP               NODE     NOMINATED NODE   READINESS GATES
3. pod/nginx   0/1     Running   0          2m5s   100.95.185.233   node02   <none>           <none>
5. NAME                    TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE     SELECTOR
6. service/nginx-service   ClusterIP   10.96.1.43   <none>        80/TCP    6m19s   app=nginx
8. NAME                      ENDPOINTS        AGE
9. endpoints/nginx-service                    6m19s

复制代码

查看Pod的详细信息，发现Readiness probe failed

1. [root@master ~/probe]# kubectl describe po nginx
2. Name:             nginx
3. Namespace:        default
4. ## 省略万字内容
5. Events:
6.   Type     Reason     Age                From               Message
7.   ----     ------     ----               ----               -------
8.   Normal   Scheduled  84s                default-scheduler  Successfully assigned default/nginx to node02
9.   Normal   Pulling    84s                kubelet            Pulling image "nginx"
10.   Normal   Pulled     81s                kubelet            Successfully pulled image "nginx" in 2.552840126s (2.552844946s including waiting)
11.   Normal   Created    81s                kubelet            Created container nginx
12.   Normal   Started    81s                kubelet            Started container nginx
13.   Warning  Unhealthy  9s (x21 over 66s)  kubelet            Readiness probe failed: HTTP probe failed with statuscode: 404

复制代码

Exec和TCP探测方式（省略）

可以参考上文的存活性探针的案例
启动探针（startup probe）详解

启动探针（Startup Probe）在Kubernetes（K8s）1.16+之后的版本才支持。
在 Kubernetes（K8s）中，启动探针（Startup Probe） 是专门为启动缓慢的应用设计的健康检查机制。它允许应用有更多的时间完成初始化，避免被存活探针（Liveness Probe）误判为失败而频繁重启。

• 如果使用启动性探针，则其它的探针则会禁用，直到该探针探测成功为止
  
• 如果探测失败，k8s将会杀死该Pod，然后按照Pod的重启策略进行重启
  
• 如果容器没有提供启动探测，则默认状态为 Success。
  
• 对于startup探针是一次性检测，容器启动时进行检测，检测成功后，才会调用其它探针。且此探针不再生效
  

核心作用

• 保护慢启动应用：为初始化时间较长的应用提供专门的检测机制，避免存活探针过早触发重启。
  
• 避免重启循环：防止因应用启动时间超过存活探针的超时设置，导致的 "启动 - 检测失败 - 重启" 恶性循环。
  
• 兼容各类应用：支持不同类型的应用（如 Java、数据库、大数据处理框架）按照自身节奏完成启动。
  

HTTP探测方式（最常用）

向容器发送 HTTP 请求，若返回状态码为 200-399，则表示检查成功。

1. [root@master ~/probe]# cat startup.yaml
2. apiVersion: v1
3. metadata:
4.   name: nginx
5.   labels:
6.     app: nginx
7. spec:
8.   # 指定重启策略为Always
9.   restartPolicy: Always
10.   containers:
11.   - name: nginx
12.     image: nginx
13.     startupProbe:
14.       httpGet:
15.         # http请求的端口
16.         port: 80
17.         # http请求的路径
18.         path: /
19.         # http请求的主机
20.         # host: 127.0.0.1
21.         # 请求方式
22.         scheme: HTTP
23.       # 超时时间，指定5秒
24.       timeoutSeconds: 5
25.       # 探针检查成功后，需要连续3次检查失败才认为容器出现问题
26.       failureThreshold: 3
27.       # 探针检查失败后，需要连续1次检查成功才认为容器恢复正常
28.       successThreshold: 1
29.       # 探针检查的执行间隔时间，指定3秒
30.       periodSeconds: 3
31.       # 容器启动后等待15秒再开始执行探针检查
32.       initialDelaySeconds: 15
34. [root@master ~/probe]# kubectl apply -f startup.yaml
35. pod/nginx created
37. # 查看Pod的状态
38. [root@master ~/probe]# kubectl get po
39. NAME    READY   STATUS    RESTARTS   AGE
40. nginx   1/1     Running   0          2m16s

复制代码

当探测失败时会发生什么呢？

1. [root@master ~/probe]# cat startup.yaml
2. kind: Pod
3. apiVersion: v1
4. metadata:
5.   name: nginx
6.   labels:
7.     app: nginx
8. spec:
9.   # 指定重启策略为Always
10.   restartPolicy: Always
11.   containers:
12.   - name: nginx
13.     image: nginx
14.     startupProbe:
15.       httpGet:
16.         port: 80
17.         # http请求的路径，指定/test，预计返回404
18.         path: /test
19.         scheme: HTTP
20.       # 超时时间，指定5秒
21.       timeoutSeconds: 5
22.       failureThreshold: 3
23.       successThreshold: 1
24.       periodSeconds: 3
25.       initialDelaySeconds: 15
27. [root@master ~/probe]# kubectl apply -f startup.yaml
28. pod/nginx created
30. #查看Pod的状态，发现容器一直在重启
31. [root@master ~/probe]# kubectl get po
32. NAME    READY   STATUS    RESTARTS      AGE
33. nginx   0/1     Running   3 (12s ago)   85s

复制代码

Exec和TCP探测方式（省略）

可以参考上文的存活性探针的案例
一个完整的案例

1. kind: Pod
2. apiVersion: v1
3. metadata:
4.   name: nginx
5.   labels:
6.     app: nginx
7. spec:
8.   restartPolicy: Never
9.   containers:
10.   - name: nginx
11.     image: nginx
12.     # 启动探针
13.     startupProbe:
14.       httpGet:
15.         port: 80
16.         path: /
17.         scheme: HTTP
18.       timeoutSeconds: 5
19.       failureThreshold: 3
20.       successThreshold: 1
21.       periodSeconds: 3
22.       initialDelaySeconds: 15
23.     # 存活探针
24.     livenessProbe:
25.       httpGet:
26.         port: 80
27.         path: /
28.         scheme: HTTP
29.       timeoutSeconds: 5
30.       failureThreshold: 3
31.       successThreshold: 1
32.       periodSeconds: 3
33.       initialDelaySeconds: 15
34.     # 就绪探针
35.     readinessProbe:
36.       httpGet:
37.         port: 80
38.         path: /
39.         scheme: HTTP
40.       timeoutSeconds: 5
41.       failureThreshold: 3
42.       successThreshold: 1
43.       periodSeconds: 3
44.       initialDelaySeconds: 15

复制代码

三个探针的区别

维度存活探针（Liveness）就绪探针（Readiness）启动探针（Startup）核心目标检测容器是否存活，失败则重启容器检测容器是否就绪，失败则移除端点处理启动延迟，延迟其他探针的执行对 Pod 的影响重启容器从服务端点移除无直接影响（成功后触发其他探针）执行时机容器启动后，按周期持续检测容器启动后，按周期持续检测仅在容器启动阶段执行，成功后停止典型场景处理应用逻辑错误导致的 “假死” 状态确保 Pod 准备好接收流量支持启动缓慢的应用（如数据库初始化）依赖关系无无优先于存活 / 就绪探针执行
来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！