K8s新手系列之探针

80/TCP 6m19s app=nginx NAME ENDPOINTS AGE endpoints/nginx-service 6m19s

查看Pod的详细信息,发现`Readiness probe failed`
```csharp
[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 准备好接收流量 支持启动缓慢的应用(如数据库初始化)
依赖关系 优先于存活 / 就绪探针执行