Kubernetes实战复盘：探针配置错误导致服务反复重启、流量摘除、集群雪崩彻底解决

Kubernetes实战复盘：探针配置错误导致服务反复重启、流量摘除、集群雪崩彻底解决

前言

Kubernetes 已经成为容器化服务编排的事实标准。

它通过以下能力管理服务：

  • 自动调度
  • 滚动升级
  • 服务扩缩容
  • 负载均衡
  • 故障自愈
  • 健康检查
  • 探针检测
  • 副本管理

很多开发者认为：只要服务能在 Kubernetes 中启动起来，就代表部署成功。

但线上大量故障恰恰源于 Kubernetes 配置细节：

  • 探针路径错误
  • 探针端口错误
  • 探针超时太短
  • 探针间隔不合理
  • 启动探针失败导致服务反复重启
  • 就绪探针失败导致流量被摘除
  • 存活探针失败导致容器被杀死
  • 资源不足导致 Pending 或 Evicted

本文基于真实线上服务反复重启故障，完整还原 Kubernetes 探针问题、分析底层原因、给出生产级配置方案。

QQ20260802-115207

一、真实线上故障场景还原

1.1 业务背景

某后端服务部署在 Kubernetes 集群中，负责处理用户订单请求。

服务使用 Kubernetes Deployment 部署，配置了：

  • livenessProbe
  • readinessProbe
  • startupProbe
  • resources
  • replicas

上线后，服务表现异常：

  • 服务启动后很快被重启
  • Pod 状态反复 CrashLoopBackOff
  • 部分实例无法进入 Running 状态
  • 接口偶尔超时
  • 集群中服务实例数量不稳定
  • 高峰期出现服务雪崩

1.2 错误配置示例

yaml
containers:

  • name: order-service
    image: order-service:latest
    ports:
    • containerPort: 8080
      livenessProbe:
      httpGet:
      path: /health
      port: 8080
      initialDelaySeconds: 5
      periodSeconds: 2
      readinessProbe:
      httpGet:
      path: /ready
      port: 8080
      initialDelaySeconds: 5
      periodSeconds: 2

这段配置看起来没有明显问题，但实际上存在风险。

二、探针配置错误为什么会导致服务雪崩

2.1 存活探针失败导致容器被杀死

livenessProbe 用于判断容器是否存活。

如果存活探针失败，Kubernetes 会认为容器已经故障，并尝试重启它。

常见现象：

  • Pod 反复重启
  • 日志中出现 CrashLoopBackOff
  • 服务实例不稳定
  • 流量切换频繁
  • 数据库连接抖动

2.2 就绪探针失败导致流量被摘除

readinessProbe 用于判断容器是否已经准备好接收流量。

如果就绪探针失败，Kubernetes 会将该 Pod 从 Service 后端端点中摘除。

常见现象：

  • 新启动实例无法承接流量
  • 服务可用实例减少
  • 高峰期负载集中到少量实例
  • 剩余实例被打爆
  • 接口超时增加

2.3 启动探针失败导致服务无法上线

startupProbe 用于判断容器是否完成启动。

如果启动探针失败，Kubernetes 会认为服务没有正常启动，并可能重启容器。

常见现象：

  • 服务启动时间超过预期
  • 启动阶段被误判失败
  • 服务反复进入重启循环
  • 新版本无法正常发布

2.4 探针超时太短导致误杀

很多服务启动后需要一段时间预热：

  • 加载配置
  • 建立数据库连接
  • 初始化缓存
  • 连接消息队列
  • 预热 JVM
  • 加载本地资源

如果探针检查过早或超时太短，会误判服务不可用。

三、常见探针配置错误

3.1 探针路径错误

yaml
livenessProbe:
httpGet:
path: /health
port: 8080

如果服务实际健康检查路径是 /actuator/health，那么探针会失败。

3.2 探针端口错误

yaml
livenessProbe:
httpGet:
path: /health
port: 80

容器内部服务实际监听 8080，探针访问 80 会失败。

3.3 启动延迟太短

yaml
initialDelaySeconds: 5

服务启动需要 30 秒，5 秒后检查会直接失败。

3.4 检查频率太高

yaml
periodSeconds: 1

每秒检查一次会增加服务压力，尤其在启动阶段。

3.5 失败阈值太低

yaml
failureThreshold: 1

短暂抖动就直接失败，容易造成误杀。

3.6 成功阈值太高

yaml
successThreshold: 3

需要连续多次成功才标记就绪，可能导致服务上线变慢。

3.7 探针接口没有真实检查

很多健康检查接口只返回固定成功结果，没有真正检查依赖资源。

http
/health 返回 200

但数据库、缓存、消息队列实际已经异常。

四、Kubernetes 三类探针详解

4.1 存活探针 livenessProbe

作用：判断容器是否还活着。

失败后行为：Kubernetes 会重启容器。

适合检查：

  • 服务是否卡死
  • 端口是否正常监听
  • 服务是否无法恢复

示例：

yaml
livenessProbe:
httpGet:
path: /actuator/health
port: 8080
initialDelaySeconds: 30
periodSeconds: 10
failureThreshold: 3
timeoutSeconds: 5

4.2 就绪探针 readinessProbe

作用：判断容器是否可以接收流量。

失败后行为：从 Service 端点中摘除流量。

适合检查：

  • 服务是否启动完成
  • 配置是否加载成功
  • 数据库连接是否正常
  • 缓存是否初始化完成
  • 是否可以承接业务请求

示例：

yaml
readinessProbe:
httpGet:
path: /actuator/health/readiness
port: 8080
initialDelaySeconds: 30
periodSeconds: 10
failureThreshold: 3
successThreshold: 2
timeoutSeconds: 5

4.3 启动探针 startupProbe

作用：判断容器是否完成首次启动。

失败后行为：可能重启容器。

适合检查：

  • 服务是否完成预热
  • 启动时间是否过长
  • 首次启动是否成功

示例：

yaml
startupProbe:
httpGet:
path: /actuator/health
port: 8080
initialDelaySeconds: 10
periodSeconds: 5
failureThreshold: 12
timeoutSeconds: 5

五、生产级完整探针配置

yaml
containers:

  • name: order-service
    image: order-service:latest
    ports:
    • containerPort: 8080
      name: http
      resources:
      requests:
      cpu: "0.5"
      memory: "512Mi"
      limits:
      cpu: "2"
      memory: "2Gi"
      startupProbe:
      httpGet:
      path: /actuator/health
      port: http
      initialDelaySeconds: 10
      periodSeconds: 5
      failureThreshold: 12
      timeoutSeconds: 5
      livenessProbe:
      httpGet:
      path: /actuator/health
      port: http
      initialDelaySeconds: 30
      periodSeconds: 10
      failureThreshold: 3
      timeoutSeconds: 5
      readinessProbe:
      httpGet:
      path: /actuator/health/readiness
      port: http
      initialDelaySeconds: 30
      periodSeconds: 10
      failureThreshold: 3
      successThreshold: 2
      timeoutSeconds: 5

六、健康检查接口设计规范

6.1 基础健康检查

http
GET /actuator/health

返回服务是否存活。

6.2 就绪检查

http
GET /actuator/health/readiness

返回服务是否可以接收流量。

6.3 详细状态检查

json
{
"status": "UP",
"components": {
"db": {
"status": "UP"
},
"redis": {
"status": "UP"
},
"mq": {
"status": "UP"
}
}
}

6.4 注意事项

健康检查接口不能太重。

不能在健康检查中执行：

  • 复杂业务逻辑
  • 大批量数据查询
  • 耗时计算
  • 外部同步调用
  • 写入操作
  • 长时间锁等待

健康检查应该快速返回。

七、线上排查命令

7.1 查看 Pod 状态

bash
kubectl get pods

7.2 查看 Pod 详细信息

bash
kubectl describe pod order-service-xxx

7.3 查看 Pod 日志

bash
kubectl logs -f order-service-xxx

7.4 查看最近日志

bash
kubectl logs --tail 100 order-service-xxx

7.5 查看事件

bash
kubectl get events

7.6 查看 Deployment 状态

bash
kubectl get deployment order-service

7.7 查看 Service 后端端点

bash
kubectl get endpoints order-service

7.8 进入 Pod 排查

bash
kubectl exec -it order-service-xxx -- bash

7.9 测试健康检查接口

bash
curl http://localhost:8080/actuator/health

八、企业级 Kubernetes 探针规范

  1. 所有生产服务必须配置存活探针；

  2. 所有生产服务必须配置就绪探针；

  3. 启动时间较长的服务必须配置启动探针；

  4. 探针路径、端口、协议必须与服务实际一致；

  5. 启动探针必须容忍服务正常预热时间；

  6. 存活探针不能过于敏感，避免误杀服务；

  7. 就绪探针必须真实反映服务是否能承接流量；

  8. 健康检查接口不能包含重业务逻辑；

  9. 高峰期避免频繁重启和流量摘除；

10.发布前必须验证探针状态和 Pod 生命周期。

九、总结

Kubernetes 探针不是简单的健康检查，它直接决定服务的生死和流量走向。

常见故障包括：

  • 启动探针失败导致服务反复重启
  • 存活探针失败导致容器被杀死
  • 就绪探针失败导致流量被摘除
  • 探针路径错误导致服务无法上线
  • 探针超时太短导致误杀
  • 服务预热时间不足导致误判

生产环境核心准则：启动探针保护启动过程，存活探针判断是否应重启，就绪探针判断是否能承接流量。三者职责不同，不能混用。

版权与友链信息

版权归属：凡尘

友情链接：凡尘博客 fanchenblog.com、wz.fanchenblog.com、雨落凡尘博客 b.fanchenblog.com、t.fanchenblog.com、凡尘乡音 y.fanchenblog.com、凡尘影院 a.fanchenblog.com

posted @ 2026-08-02 11:54  凡尘——雨落凡尘  阅读(25)  评论(0)    收藏  举报