健康检查探针 Probe

Kubernetes 如何判断一个容器是「活着但卡死」还是「真的能接流量」？答案是探针（Probe）：由 kubelet 周期性对容器发起检查，据此决定重启容器或把 Pod 从 Service 摘除，这是集群自愈与无损发布的基础。

三种探针的区别

探针	检查目的	失败后果
livenessProbe 存活探针	进程在跑但应用是否卡死	重启容器
readinessProbe 就绪探针	是否准备好接收流量	从 Service Endpoint 摘除，不重启
startupProbe 启动探针	慢启动应用何时真正就绪	保护前两种探针不误杀

三种检查方式

exec 在容器里执行命令、httpGet 请求 HTTP 接口、tcpSocket 建立 TCP 连接，可自由组合：

apiVersion: v1
kind: Pod
metadata:
  name: probe-demo
spec:
  containers:
    - name: app
      image: nginx
      livenessProbe:              # 存活：请求 /healthz
        httpGet:
          path: /healthz
          port: 80
      readinessProbe:             # 就绪：请求 /ready
        httpGet:
          path: /ready
          port: 80
      startupProbe:               # 启动：等文件出现
        exec:
          command: ["sh", "-c", "test -f /tmp/started"]
        failureThreshold: 30      # 慢启动最多等 30×10s

常用参数

参数	默认值	含义
initialDelaySeconds	0	容器启动后延迟多少秒再开始探测
periodSeconds	10	两次探测间隔
timeoutSeconds	1	单次探测超时
successThreshold	1	连续成功几次才算健康
failureThreshold	3	连续失败几次才判定不健康

就绪探针与 Service 摘流

就绪探针失败后，该 Pod 会立即从 Service 的 Endpoint 中移除，流量只发给就绪的 Pod——滚动更新时新 Pod 不就绪就不会被放流量，这正是「先就绪、后放量」无损发布的机制。

startupProbe 护慢启动

Java 等应用启动可能要几十秒，期间健康接口还没就绪，livenessProbe 会误判并反复重启。用 startupProbe 给足失败次数，存活/就绪探针会等它成功后才开始计时，避免启动期被杀。

误配导致的重启循环

探针路径 404、端口写错、timeoutSeconds 太小、initialDelaySeconds 不够，都会让健康容器被反复重启，表现为 CrashLoopBackOff：

kubectl get pods
# 输出：NAME         READY   STATUS             RESTARTS
#       probe-demo   0/1     CrashLoopBackOff   5
kubectl describe pod probe-demo    # 看探针失败事件与具体原因
kubectl logs probe-demo --previous # 看被杀前应用日志

先用 describe 确认是 liveness 失败，再用日志验证应用健康接口是否真的可用，然后针对性调大 timeoutSeconds 或 initialDelaySeconds。

小结：livenessProbe 管重启、readinessProbe 管摘流量、startupProbe 护慢启动；多数健康接口用 httpGet 即可；容器被反复重启先 describe 看探针事件，再核对路径、端口与参数。