Kubernetes 生产排障Pod 一直重启时先别急着重建集群一、CrashLoopBackOff 只是结果不是根因Kubernetes 里 Pod 一直重启是生产环境最常见也最容易被误判的问题。很多人第一反应是镜像有问题、节点有问题甚至怀疑集群坏了。实际上CrashLoopBackOff只是结果不是原因。真正要查的是容器为什么退出、探针为什么失败、资源为什么不足、配置为什么不一致。排障时先看事件再看日志再看资源。kubectl describe pod可以看到调度、拉镜像、探针失败和 OOM 等事件kubectl logs --previous能看到上一次崩溃前的日志kubectl top pod或监控系统能观察 CPU、内存是否触顶。如果跳过这些证据直接重启服务可能只是把问题刷新一遍。二、排障路径事件、日志和资源要串成证据链flowchart TD A[Pod 重启] -- B[查看 describe 事件] B -- C{是否 OOMKilled?} C -- 是 -- D[检查内存限制与堆配置] C -- 否 -- E[查看 previous 日志] E -- F{探针失败?} F -- 是 -- G[调整探针与启动流程] F -- 否 -- H[检查配置和依赖]探针配置是高频坑。启动慢的应用如果 livenessProbe 太激进会在服务真正准备好之前被 kubelet 杀掉然后进入反复重启。正确做法是区分 startupProbe、readinessProbe 和 livenessProbe。启动阶段用 startupProbe 给应用预热时间readinessProbe 决定是否接流量livenessProbe 只用于判断进程是否不可恢复。三、探针配置实践启动、就绪和存活不能混用下面是一个更稳的探针配置片段。它不是万能模板关键是根据应用启动时间和依赖检查成本调整。startupProbe: httpGet: path: /health/startup port: 8080 failureThreshold: 30 periodSeconds: 2 readinessProbe: httpGet: path: /health/ready port: 8080 initialDelaySeconds: 5 periodSeconds: 5 livenessProbe: httpGet: path: /health/live port: 8080 initialDelaySeconds: 30 periodSeconds: 10四、资源与配置权衡重启服务不是修复问题资源限制也要认真看。容器被 OOMKilled 时应用日志可能来不及写完只能从 Pod 状态看到退出原因。Java、Node.js、Go 等运行时都需要根据容器限制设置内存参数。给了 512Mi limit却让进程默认按宿主机内存估算很容易被内核杀掉。配置错误同样常见。ConfigMap 没更新、Secret key 写错、环境变量为空、数据库地址不可达都会导致应用启动后立即退出。生产排障要形成固定路径先确认镜像版本再确认配置版本再确认依赖状态最后才考虑节点和集群层面的问题。还要把修复动作分级。短期可以调大探针窗口、回滚镜像或恢复配置长期则要补启动健康检查、资源基线和发布前验证。否则下一次依赖变慢或配置缺失时同样的重启循环还会出现。生产落地补充从能跑到可维护从生产落地角度看这类方案不能只停留在主流程。更关键的是把输入校验、失败分支、资源上限和回滚路径提前写清楚。主流程通常容易在演示环境里跑通真正暴露问题的是异常输入、依赖抖动、并发放大和权限边界。一篇技术方案如果没有解释这些约束读者很难判断它能否放进真实系统。评估时建议先定义三类指标正确性指标、稳定性指标和成本指标。正确性指标回答结果是否可信稳定性指标回答失败时是否可控成本指标回答持续运行是否划算。三类指标要同时进入验收清单不能只用平均耗时或单次成功率证明方案有效。实现层面还需要把观测数据留出来。日志至少包含请求标识、关键参数摘要、耗时、状态和错误类型指标至少覆盖成功率、超时率、重试次数和队列长度必要时再补 Trace 关联上下游调用。这样排查问题时不用靠猜也能区分是代码逻辑、外部依赖还是容量配置导致的故障。测试策略也要覆盖边界条件。除了正常样例还要准备空输入、超大输入、重复请求、依赖超时、权限不足和部分成功等用例。涉及并发时应补充压力测试和资源泄漏检查涉及数据处理时应补充幂等校验和结果一致性校验。测试不是装饰而是保证后续重构仍然可信的依据。异常路径补充把失败当成接口契约下面的补充片段强调一个原则调用方必须得到稳定、可解释的错误而不是在超时、空输入或依赖失败时收到模糊结果。代码不追求覆盖所有业务细节而是展示输入校验、超时控制和错误封装这三个生产系统最容易遗漏的环节。from __future__ import annotations import asyncio from dataclasses import dataclass dataclass class GuardedResult: ok: bool value: str error: str async def run_with_guard(input_text: str, timeout: float 3.0) - GuardedResult: if not input_text.strip(): return GuardedResult(okFalse, errorinput cannot be empty) try: async with asyncio.timeout(timeout): # 真实项目中这里放模型调用、数据库查询或外部服务请求。 await asyncio.sleep(0.01) return GuardedResult(okTrue, valuefaccepted: {input_text}) except TimeoutError: return GuardedResult(okFalse, erroroperation timeout) except Exception as exc: return GuardedResult(okFalse, errorfoperation failed: {exc})五、总结Pod 重启排障要从事件、日志、探针、资源和配置逐层推进。不要把CrashLoopBackOff当成根因也不要一上来重建资源。证据链清楚Kubernetes 问题通常能被拆成具体、可修复的小问题。