背景 这类问题在真实项目里很常见：高并发、复杂依赖、发布频繁、团队协作面广。只有把边界条件提前定义清楚，系统才会在压力下保持稳定。 实践要点 先定义目标：可用性、延迟、成本哪个优先。 把关键路径显式化：超时、重试、降级、回滚。 把策略写进代码和流程，而不是只停留在文档。 代码片段 apiVersion: v1 kind: ConfigMap metadata: name: sample 总结 工程实践最怕“看起来正确”。把策略做成可观测、可验证、可回滚的闭环，才能在生产环境里真正稳定运行。 稳定性不是某个技巧，而是持续的系统化约束。
背景 很多集群在节点升级、手动驱逐时出现服务抖动，根因常常是没配或错配 PDB。 基本配置 apiVersion: policy/v1 kind: PodDisruptionBudget metadata: name: api-pdb spec: minAvailable: 2 selector: matchLabels: app: api 总结 PDB 不是“可选增强”，而是生产集群进行维护操作的安全护栏。 维护窗口稳定与否，很多时候取决于这几行 YAML。
常见事故模式 发布时最容易看到这几类问题： Pod 刚启动就被打流量，依赖还没就绪 应用短暂卡顿被 liveness 误杀 Pod 被删时连接直接断开，导致错误尖峰 三类探针分工 startupProbe：启动阶段保护期 readinessProbe：是否可以接收流量 livenessProbe：进程是否需要重启 不要用 liveness 去做复杂业务检查，它更适合检测“进程是否活着”。 终止流程要完整 示例配置： spec: terminationGracePeriodSeconds: 30 containers: - name: api lifecycle: preStop: exec: command: ["/bin/sh", "-c", "sleep 8"] 应用内部还需要做到： 收到 SIGTERM 后停止接收新请求 等待在途请求结束 关闭连接池与后台任务 一个经验值 如果入口网关或 Service Mesh 更新端点需要几秒，preStop 这几秒很关键。它给控制面收敛时间，避免流量打到即将退出的 Pod。 结语 高可用不是靠单个参数，而是探针策略和退出流程共同生效。发布稳定性通常是这些细节堆出来的。