K8S篇之默认pod健康探针参数说明

常见问题：当Pod 的存活探针（livenessProbe）和就绪探针（readinessProbe）的initialDelaySeconds设置过短，导致探针在服务未完全启动时就开始检测，从而导致pod触发 "connection refused" 错误。
需要调整探针的延迟启动时间和检测周期，适配服务的实际启动时长，具体修改方案如下：

一、核心修改点（针对探针配置）

1.增大initialDelaySeconds：给服务足够的启动时间（比如从 10 秒调整为 60 秒，根据服务实际启动时长调整）；

2.放宽failureThreshold：允许更多次探测失败，避免频繁判定不健康；

3.（可选）调整periodSeconds：延长探测间隔，减少不必要的探测。

K8s 探针配置的最佳实践模板

以下是适用于不同场景的 K8s 探针（存活、就绪、启动）配置最佳实践模板，覆盖普通服务、慢启动服务、高可用服务等场景：

一、通用基础模板（适用于大多数常规服务）

yaml 复制代码

spec:
  containers:
  - name: your-container
    image: your-image:latest
    ports:
    - containerPort: 8080
    # 存活探针：检测服务是否存活，失败则重启容器
    livenessProbe:
      tcpSocket:  # 也可替换为httpGet（HTTP服务）
        port: 8080
      initialDelaySeconds: 30  # 服务启动后延迟30秒开始探测
      periodSeconds: 10        # 每10秒探测一次
      timeoutSeconds: 3        # 单次探测超时3秒
      failureThreshold: 5      # 连续5次失败则判定不健康
      successThreshold: 1      # 1次成功则恢复健康

    # 就绪探针：检测服务是否就绪，失败则从Service摘除
    readinessProbe:
      tcpSocket:
        port: 8080
      initialDelaySeconds: 20  # 比存活探针稍早启动
      periodSeconds: 5         # 就绪探测间隔更短，确保快速上线
      timeoutSeconds: 2
      failureThreshold: 3
      successThreshold: 2      # 需连续2次成功，避免偶发波动

    # 资源限制（配合探针，避免资源不足导致启动失败）
    resources:
      limits:
        cpu: "2"
        memory: "4Gi"
      requests:
        cpu: "1"
        memory: "2Gi"

二、慢启动服务模板（如大数据 / AI 服务，启动时长 > 5 分钟）

针对启动慢的服务，新增启动探针（Startup Probe）单独管理启动阶段，避免存活 / 就绪探针误判：

yaml 复制代码

spec:
  containers:
  - name: slow-start-container
    image: ai-model:latest
    ports:
    - containerPort: 9000
    # 启动探针：仅在启动阶段生效，成功后不再探测
    startupProbe:
      httpGet:  # 若为TCP服务，替换为tcpSocket
        path: /health/startup
        port: 9000
      initialDelaySeconds: 60   # 启动后60秒开始探测
      periodSeconds: 20         # 每20秒探测一次
      timeoutSeconds: 5
      failureThreshold: 20      # 允许20次失败（总探测时长=20*20=400秒≈6.5分钟）

    # 存活探针：启动探针成功后才开始工作
    livenessProbe:
      httpGet:
        path: /health/liveness
        port: 9000
      initialDelaySeconds: 30
      periodSeconds: 15
      timeoutSeconds: 3
      failureThreshold: 3

    # 就绪探针：启动探针成功后才开始工作
    readinessProbe:
      httpGet:
        path: /health/readiness
        port: 9000
      initialDelaySeconds: 20
      periodSeconds: 5
      timeoutSeconds: 2
      failureThreshold: 2

三、高可用服务模板（如核心业务服务，需更严格的探测）

针对核心服务，通过更短的探测间隔 + 更严格的失败阈值，确保服务异常时快速响应：

yaml 复制代码

spec:
  containers:
  - name: core-service
    image: core-api:latest
    ports:
    - containerPort: 80
    livenessProbe:
      httpGet:
        path: /api/health
        port: 80
        httpHeaders:  # 自定义请求头（如鉴权）
        - name: X-Health-Check
          value: "true"
      initialDelaySeconds: 15
      periodSeconds: 5          # 每5秒探测一次，快速发现异常
      timeoutSeconds: 2
      failureThreshold: 2       # 连续2次失败则重启
      successThreshold: 1

    readinessProbe:
      httpGet:
        path: /api/ready
        port: 80
      initialDelaySeconds: 10
      periodSeconds: 3          # 就绪探测间隔更短
      timeoutSeconds: 1
      failureThreshold: 2
      successThreshold: 2

    # 配置Pod中断预算（配合探针，减少高可用风险）
  terminationGracePeriodSeconds: 30  # 优雅终止时长

四、探针类型选择建议

探针类型适用场景推荐探测方式存活探针（Liveness）检测服务是否存活（如进程崩溃）TCP/HTTP（轻量接口）就绪探针（Readiness）检测服务是否可提供服务（如依赖未就绪）HTTP（业务就绪接口）启动探针（Startup）慢启动服务（如 AI / 大数据）HTTP（启动完成接口）

探针类型	适用场景	推荐探测方式
存活探针（Liveness）	检测服务是否存活（如进程崩溃）	TCP/HTTP（轻量接口）
就绪探针（Readiness）	检测服务是否可提供服务（如依赖未就绪）	HTTP（业务就绪接口）
启动探针（Startup）	慢启动服务（如 AI / 大数据）	HTTP（启动完成接口）

五、关键配置原则

1.initialDelaySeconds：略小于服务实际启动时长（可通过日志统计）；

2.failureThreshold：慢启动服务设大（如 20），核心服务设小（如 2~3）；

3.探测接口：需轻量无业务逻辑（避免探测本身影响服务性能）；

4.避免单点依赖：探针接口不要依赖外部服务（如数据库），仅检测自身状态。