1）三种探针分别“管什么”

✅ livenessProbe（存活探针）

• 目的：判断容器是否“卡死/假死”，需要不需要重启。
• 失败后动作：kubelet重启容器（相当于触发容器重启）。
• 典型场景：应用线程死锁、进入不可恢复状态（不重启就永远不恢复）。

误区：不要拿 livenessProbe 去判断“能不能对外提供服务”。那是 readinessProbe 的事。

✅ readinessProbe（就绪探针）

• 目的：判断容器是否已经“可以接流量”。
• 失败后动作：Pod 仍然运行，但会从 Service Endpoints 里摘除，不再接流量。
• 典型场景：
  • 应用启动中还没初始化完
  • 依赖 DB / MQ 未就绪
  • 高负载需要临时“拒绝接流量但不重启”

这就是线上最关键的探针：它保护流量。

✅ startupProbe（启动探针）

• 目的：专门解决“启动慢”的问题，避免启动过程中被 livenessProbe 误杀。
• 行为：只在启动阶段检查；startupProbe 未成功前，liveness/readiness 都不会生效（核心点）。
• 典型场景：Java、.NET、首次加载模型、需要迁移、预热缓存等启动很慢的服务。

2）探针支持的检查方式（常用）

K8s probe 常见三种 handler：

1. httpGet：HTTP 状态码 200~399 认为成功
2. tcpSocket：端口能建立 TCP 连接就成功
3. exec：容器内命令返回码 0 成功

建议优先 httpGet（可观测、语义清晰），其次 tcpSocket（只验证端口通不通），最后 exec（容易引入开销/权限/依赖）。

3）关键参数：怎么理解、怎么调

所有探针通用字段：

• initialDelaySeconds：容器启动后等多久 才开始探测
• periodSeconds：每隔多久探测一次
• timeoutSeconds：单次探测超时
• successThreshold：连续成功多少次才算成功（readiness 常用；liveness 通常保持 1）
• failureThreshold：连续失败多少次才算失败（决定“容忍度”）

经验公式（好用）

• readinessProbe：failureThreshold 可以偏小（快速摘流量）
• livenessProbe：要更保守（避免误杀），failureThreshold 可偏大
• startupProbe：failureThreshold * periodSeconds ≈ 你允许的最长启动时间
  • 例如periodSeconds=5，failureThreshold=60 → 允许 300 秒（5 分钟）启动

4）最佳实践（非常重要）

A. 三者怎么搭配（推荐套路）

• 大多数在线服务：readiness + liveness
• 启动慢的服务：startup + readiness + liveness（最稳）

B. 探针接口怎么设计

推荐实现 2 个接口：

• /ready：检查依赖是否可用（DB/MQ/缓存/关键配置/队列连接等）
• /live：只检查进程是否活着/主循环是否正常（不要查 DB，避免依赖抖动导致频繁重启）

C. 别把“外部依赖检查”放进 liveness

否则 DB 抖一下你就把服务重启风暴搞出来了。

5）可直接复制的 YAML 示例（常用模板）

示例 1：标准 Web 服务（readiness + liveness）

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-web
spec:
  replicas: 2
  selector:
    matchLabels:
      app: demo-web
  template:
    metadata:
      labels:
        app: demo-web
    spec:
      containers:
        - name: demo-web
          image: nginx:1.27
          ports:
            - containerPort: 80

          readinessProbe:
            httpGet:
              path: /ready
              port: 80
            initialDelaySeconds: 5
            periodSeconds: 5
            timeoutSeconds: 2
            failureThreshold: 2
            successThreshold: 1

          livenessProbe:
            httpGet:
              path: /live
              port: 80
            initialDelaySeconds: 15
            periodSeconds: 10
            timeoutSeconds: 2
            failureThreshold: 3

示例 2：启动很慢的服务（startup + readiness + liveness）

containers:
  - name: app
    image: your-image:latest
    ports:
      - containerPort: 8080

    startupProbe:
      httpGet:
        path: /live
        port: 8080
      periodSeconds: 5
      timeoutSeconds: 2
      failureThreshold: 60   # 60*5=300s，允许 5 分钟启动

    readinessProbe:
      httpGet:
        path: /ready
        port: 8080
      periodSeconds: 5
      timeoutSeconds: 2
      failureThreshold: 2

    livenessProbe:
      httpGet:
        path: /live
        port: 8080
      periodSeconds: 10
      timeoutSeconds: 2
      failureThreshold: 3

示例 3：TCP 探针（适合 MySQL/Redis 这类“端口通就算活着”的场景）

readinessProbe:
  tcpSocket:
    port: 6379
  periodSeconds: 5
  failureThreshold: 2

livenessProbe:
  tcpSocket:
    port: 6379
  periodSeconds: 10
  failureThreshold: 3

示例 4：exec 探针（谨慎使用）

readinessProbe:
  exec:
    command: ["sh", "-c", "test -f /tmp/ready"]
  periodSeconds: 5
  failureThreshold: 2

6）常见问题排查（你线上一定会遇到）

1）Pod 一直重启（CrashLoopBackOff）

优先看是否：

• livenessProbe 太激进（period 太短、timeout 太小、failureThreshold 太小）
• 启动慢却没加 startupProbe
• liveness 接口做了 DB 检查导致依赖抖动→重启风暴

2）服务不接流量，但 Pod Running

通常是 readinessProbe 在失败：

• 访问/ready 失败、超时、返回非 2xx/3xx
• 端口/路径写错
• 依赖未就绪（DB/MQ/配置中心）

3）滚动更新很慢

readinessProbe 通过太慢（successThreshold / initialDelay 设置太大），或者/ready 做了过重检查。