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，则表示检查成功。

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

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

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

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

  po.spec.containers.livenessProbe.
  exec:
  command:
  - cat
  - /etc/hosts

配置参数

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

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

存活探针（liveness probe）详解

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

核心作用

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

HTTP探测实战（最常用）

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

[root@master ~/probe]# cat liveness.yaml
kind: Pod
apiVersion: v1
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx
    livenessProbe:
      httpGet:
        # http请求的端口
        port: 80
        # http请求的路径
        path: /
        # http请求的主机
        # host: 127.0.0.1
        # 请求方式
        scheme: HTTP
      # 超时时间，指定5秒
      timeoutSeconds: 5
      # 探针检查成功后，需要连续3次检查失败才认为容器出现问题
      failureThreshold: 3
      # 探针检查失败后，需要连续1次检查成功才认为容器恢复正常
      successThreshold: 1
      # 探针检查的执行间隔时间，指定3秒
      periodSeconds: 3
      # 容器启动后等待30秒再开始执行探针检查
      initialDelaySeconds: 30

[root@master ~/probe]# kubectl apply -f liveness.yaml
pod/nginx created

# 等待一段时间查看Pod的状态
[root@master ~/probe]# kubectl get po nginx
NAME    READY   STATUS    RESTARTS   AGE
nginx   1/1     Running   0          2m8s

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

修改一下请求路径

[root@master ~/probe]# cat liveness.yaml
kind: Pod
apiVersion: v1
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx
    livenessProbe:
      httpGet:
        port: 80
        # http请求的路径未/test，在nginx容器中，改路径应该会返回404状态码
        path: /test
        scheme: HTTP
      timeoutSeconds: 5
      failureThreshold: 3
      successThreshold: 1
      periodSeconds: 3
      initialDelaySeconds: 30

[root@master ~/probe]# kubectl apply -f liveness.yaml
pod/nginx created

# 稍微等待一会，查看Pod的状态，发现RESTARTS次数已经为1了，这里表示容器的重启次数
[root@master ~/probe]# kubectl get po
NAME             READY   STATUS    RESTARTS     AGE
nginx            1/1     Running   1 (8s ago)   48s

Exec探测实战

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

[root@master ~/probe]# cat liveness.yaml
kind: Pod
apiVersion: v1
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx
    livenessProbe:
      exec:
      # 指定shell命令，cat /etc/hosts
        command:
          - cat
          - /etc/hosts
      # 超时时间，指定5s
      timeoutSeconds: 5
      # 探针检查成功后，需要连续3次检查失败才认为容器出现问题
      failureThreshold: 3
      # 探针检查失败后，需要连续1次检查成功才认为容器恢复正常
      successThreshold: 1
      # 探针检查的执行间隔时间，指定3秒
      periodSeconds: 3
      # 容器启动后等待15秒再开始执行探针检查
      initialDelaySeconds: 15

[root@master ~/probe]# kubectl apply -f liveness.yaml
pod/nginx created
# 查看Pod的状态
[root@master ~/probe]# kubectl get po nginx
NAME    READY   STATUS    RESTARTS   AGE
nginx   1/1     Running   0          44s

TCP探测方式实战

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

[root@master ~/probe]# cat liveness.yaml
kind: Pod
apiVersion: v1
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx
    livenessProbe:
      # 测试某个容器的TCP端口是否能够连通，类似于telnet nc工具
      tcpSocket:
        port: 80
      # 超时时间，指定5s
      timeoutSeconds: 5
      # 探针检查成功后，需要连续3次检查失败才认为容器出现问题
      failureThreshold: 3
      # 探针检查失败后，需要连续1次检查成功才认为容器恢复正常
      successThreshold: 1
      # 探针检查的执行间隔时间，指定3秒
      periodSeconds: 3
      # 容器启动后等待15秒再开始执行探针检查
      initialDelaySeconds: 15

[root@master ~/probe]# kubectl apply -f liveness.yaml
pod/nginx created

# 检查Pod的状态
[root@master ~/probe]# kubectl get po nginx
NAME    READY   STATUS    RESTARTS   AGE
nginx   1/1     Running   0          40s

就绪探针（readiness probe）详解

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

核心作用

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

HTTP探测实战（最常用）

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

示例：创建Pod

[root@master ~/probe]# cat readiness.yaml
kind: Pod
apiVersion: v1
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  containers:
  - name: nginx
    image: nginx
    readinessProbe:
      httpGet:
        # http请求的端口
        port: 80
        # http请求的路径
        path: /
        # http请求的主机
        # host: 127.0.0.1
        # 请求方式
        scheme: HTTP
      # 超时时间，指定5秒
      timeoutSeconds: 5
      # 探针检查成功后，需要连续3次检查失败才认为容器出现问题
      failureThreshold: 3
      # 探针检查失败后，需要连续1次检查成功才认为容器恢复正常
      successThreshold: 1
      # 探针检查的执行间隔时间，指定3秒
      periodSeconds: 3
      # 容器启动后等待15秒再开始执行探针检查
      initialDelaySeconds: 15

[root@master ~/probe]# kubectl apply -f readiness.yaml
pod/nginx created

创建Service

[root@master ~/probe]# cat service.yaml
apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  type: ClusterIP
  selector:
    # 选择标签为 app: nginx 的 Pod
    app: nginx
  ports:
    - name: http
      protocol: TCP
      # Service的端口
      port: 80
      # Pod 上的端口
      targetPort: 80
[root@master ~/probe]# kubectl apply -f service.yaml
service/nginx-service created

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

[root@master ~/probe]# kubectl get po,svc,ep -o wide
NAME        READY   STATUS    RESTARTS   AGE    IP               NODE     NOMINATED NODE   READINESS GATES
pod/nginx   1/1     Running   0          4m2s   100.95.185.232   node02   <none>           <none>

NAME                    TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE    SELECTOR
service/nginx-service   ClusterIP   10.96.1.43   <none>        80/TCP    112s   app=nginx

NAME                      ENDPOINTS           AGE
endpoints/nginx-service   100.95.185.232:80   112s

修改Pod的就绪探针

[root@master ~/probe]# cat readiness.yaml
kind: Pod
apiVersion: v1
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  containers:
  - name: nginx
    image: nginx
    readinessProbe:
      httpGet:
        port: 80
        # http请求的路径，指定为/test，这里应该会返回404
        path: /test
        scheme: HTTP
      timeoutSeconds: 5
      failureThreshold: 3
      successThreshold: 1
      periodSeconds: 3
      initialDelaySeconds: 15

# 重新创建Pod
[root@master ~/probe]# kubectl apply -f readiness.yaml
pod/nginx created

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

[root@master ~/probe]# kubectl get po,svc,ep -o wide
NAME        READY   STATUS    RESTARTS   AGE    IP               NODE     NOMINATED NODE   READINESS GATES
pod/nginx   0/1     Running   0          2m5s   100.95.185.233   node02   <none>           <none>

NAME                    TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE     SELECTOR
service/nginx-service   ClusterIP   10.96.1.43   <none>        80/TCP    6m19s   app=nginx

NAME                      ENDPOINTS        AGE
endpoints/nginx-service                    6m19s

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

[root@master ~/probe]# kubectl describe po nginx
Name:             nginx
Namespace:        default
## 省略万字内容
Events:
  Type     Reason     Age                From               Message
  ----     ------     ----               ----               -------
  Normal   Scheduled  84s                default-scheduler  Successfully assigned default/nginx to node02
  Normal   Pulling    84s                kubelet            Pulling image "nginx"
  Normal   Pulled     81s                kubelet            Successfully pulled image "nginx" in 2.552840126s (2.552844946s including waiting)
  Normal   Created    81s                kubelet            Created container nginx
  Normal   Started    81s                kubelet            Started container nginx
  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，则表示检查成功。

[root@master ~/probe]# cat startup.yaml
apiVersion: v1
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  # 指定重启策略为Always
  restartPolicy: Always
  containers:
  - name: nginx
    image: nginx
    startupProbe:
      httpGet:
        # http请求的端口
        port: 80
        # http请求的路径
        path: /
        # http请求的主机
        # host: 127.0.0.1
        # 请求方式
        scheme: HTTP
      # 超时时间，指定5秒
      timeoutSeconds: 5
      # 探针检查成功后，需要连续3次检查失败才认为容器出现问题
      failureThreshold: 3
      # 探针检查失败后，需要连续1次检查成功才认为容器恢复正常
      successThreshold: 1
      # 探针检查的执行间隔时间，指定3秒
      periodSeconds: 3
      # 容器启动后等待15秒再开始执行探针检查
      initialDelaySeconds: 15

[root@master ~/probe]# kubectl apply -f startup.yaml
pod/nginx created

# 查看Pod的状态
[root@master ~/probe]# kubectl get po
NAME    READY   STATUS    RESTARTS   AGE
nginx   1/1     Running   0          2m16s

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

[root@master ~/probe]# cat startup.yaml
kind: Pod
apiVersion: v1
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  # 指定重启策略为Always
  restartPolicy: Always
  containers:
  - name: nginx
    image: nginx
    startupProbe:
      httpGet:
        port: 80
        # http请求的路径，指定/test，预计返回404
        path: /test
        scheme: HTTP
      # 超时时间，指定5秒
      timeoutSeconds: 5
      failureThreshold: 3
      successThreshold: 1
      periodSeconds: 3
      initialDelaySeconds: 15

[root@master ~/probe]# kubectl apply -f startup.yaml
pod/nginx created

#查看Pod的状态，发现容器一直在重启
[root@master ~/probe]# kubectl get po
NAME    READY   STATUS    RESTARTS      AGE
nginx   0/1     Running   3 (12s ago)   85s

Exec和TCP探测方式（省略）

可以参考上文的存活性探针的案例

一个完整的案例

kind: Pod
apiVersion: v1
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  restartPolicy: Never
  containers:
  - name: nginx
    image: nginx
    # 启动探针
    startupProbe:
      httpGet:
        port: 80
        path: /
        scheme: HTTP
      timeoutSeconds: 5
      failureThreshold: 3
      successThreshold: 1
      periodSeconds: 3
      initialDelaySeconds: 15
    # 存活探针
    livenessProbe:
      httpGet:
        port: 80
        path: /
        scheme: HTTP
      timeoutSeconds: 5
      failureThreshold: 3
      successThreshold: 1
      periodSeconds: 3
      initialDelaySeconds: 15
    # 就绪探针
    readinessProbe:
      httpGet:
        port: 80
        path: /
        scheme: HTTP
      timeoutSeconds: 5
      failureThreshold: 3
      successThreshold: 1
      periodSeconds: 3
      initialDelaySeconds: 15

三个探针的区别

维度	存活探针（Liveness）	就绪探针（Readiness）	启动探针（Startup）
核心目标	检测容器是否存活，失败则重启容器	检测容器是否就绪，失败则移除端点	处理启动延迟，延迟其他探针的执行
对 Pod 的影响	重启容器	从服务端点移除	无直接影响（成功后触发其他探针）
执行时机	容器启动后，按周期持续检测	容器启动后，按周期持续检测	仅在容器启动阶段执行，成功后停止
典型场景	处理应用逻辑错误导致的 "假死" 状态	确保 Pod 准备好接收流量	支持启动缓慢的应用（如数据库初始化）
依赖关系	无	无	优先于存活 / 就绪探针执行