背景 这类问题在真实项目里很常见：高并发、复杂依赖、发布频繁、团队协作面广。只有把边界条件提前定义清楚，系统才会在压力下保持稳定。 实践要点 先定义目标：可用性、延迟、成本哪个优先。 把关键路径显式化：超时、重试、降级、回滚。 把策略写进代码和流程，而不是只停留在文档。 代码片段 apiVersion: v1 kind: ConfigMap metadata: name: sample 总结 工程实践最怕“看起来正确”。把策略做成可观测、可验证、可回滚的闭环，才能在生产环境里真正稳定运行。 稳定性不是某个技巧，而是持续的系统化约束。
事故模式 下游抖动时，上游大量重试，导致下游雪上加霜，最终全链路崩溃。表面看是“下游慢”，本质是“重试风暴”。 核心思路：重试预算 对每个服务设定单位时间最大重试量。 预算耗尽后只允许失败快返，不再重试。 将预算按调用优先级分层。 参数实践 请求总超时必须小于上游超时预算。 单次重试间隔采用指数退避 + 抖动。 只对幂等请求开启自动重试。 指标面 retry_attempts_total retry_budget_remaining upstream_timeout_rate outlier_ejection_count 小结 超时、重试、熔断必须联动配置。没有预算约束的重试机制，最终一定把局部故障放大成系统性故障。
背景 Ingress 够简单，但在多团队协作、细粒度权限和高级路由策略上容易吃力。 迁移思路 先并行接入，不强切 从低风险路由开始迁移 明确 GatewayClass 与 Route 的职责边界 总结 迁移重点不在 YAML 语法，而在组织层面的边界和治理模型。 流量治理升级，技术和协作模型要一起升级。
背景 很多集群在节点升级、手动驱逐时出现服务抖动，根因常常是没配或错配 PDB。 基本配置 apiVersion: policy/v1 kind: PodDisruptionBudget metadata: name: api-pdb spec: minAvailable: 2 selector: matchLabels: app: api 总结 PDB 不是“可选增强”，而是生产集群进行维护操作的安全护栏。 维护窗口稳定与否，很多时候取决于这几行 YAML。
典型事故 业务高峰来临，HPA 根据 CPU 拉副本；同时 VPA 建议提升 requests，导致 Pod 频繁重建。结果不是稳定，而是不断抖动。 协同原则 HPA 负责“横向弹性”（副本数）。 VPA 负责“纵向建议”（资源基线）。 两者不要同时直接控制同一 Deployment 的同一资源维度。 实操模式 在线服务：HPA + VPA(recommendation only)。 离线作业：VPA(auto) + 关闭 HPA。 把 VPA 建议周期性写回 Helm values，再经灰度发布生效。 关键参数 HPA 目标指标建议使用自定义业务指标（QPS、队列深度），不要只盯 CPU。 HPA behavior 里设置 scaleDown 稳定窗口，防止“刚扩就缩”。 VPA 设置 minAllowed/maxAllowed，避免极端建议。 观测面板建议 当前副本数与目标副本数差值。 Pod 重建频率与重建原因。 requests 利用率分布（而非平均值）。 小结 HPA 与 VPA 本质上是两个控制器。让它们协同的关键，不是“都开”，而是“职责分离 + 变更节流 + 可观测闭环”。
背景 同样是自动伸缩，HPA、VPA、KEDA 解决的问题并不一样。 选择思路 请求型 Web 服务：优先 HPA 资源画像长期不准：引入 VPA 做建议或自动调参 事件驱动消费：优先 KEDA 常见组合 HPA + Cluster Autoscaler：最常见 HPA + KEDA：API + 消费任务混合系统 VPA 先建议模式观察，再决定是否自动 总结 不要为“自动化程度更高”盲目上更多组件。 先把指标质量做好，再谈伸缩策略。 伸缩策略的上限，取决于指标体系的下限。
背景 很多集群的问题，最后都落在资源配置上： requests 太高，调度不进去 requests 太低，服务被抢占导致抖动 limits 太严，CPU 被频繁 throttling 基本策略 先测业务基线，再填 requests CPU limits 结合业务特性决定是否设置 内存 limits 必须有，否则容易把节点拖垮 resources: requests: cpu: "300m" memory: "512Mi" limits: cpu: "1000m" memory: "1Gi" 观测指标 建议持续看： container_cpu_cfs_throttled_seconds_total container_memory_working_set_bytes Pod OOMKilled 次数 总结 资源参数不是一次性配置，而是持续调优过程。 用监控数据驱动参数调整，比凭经验拍数值更靠谱。 资源治理本质是容量治理，最终影响的是可用性和成本。
成本高不一定是机器贵 很多集群成本高，核心原因是资源配置粗放： request 远大于实际使用 HPA 指标失真导致过度扩容 长尾任务长期占用节点 第一件事：拉齐 request 和真实负载 建议先看 7 到 14 天数据，按 P95 使用量设置 request，再保留安全余量。盲目按峰值配置，浪费通常最大。 第二件事：把弹性策略拆开 在线服务：偏稳定，防抖优先 离线任务：可抢占，成本优先 把工作负载分层后，调参会清晰很多。 第三件事：节点池治理 基础池用稳定机型承载核心服务 弹性池接临时流量和批任务 定期清理空转节点 额外收益点 镜像瘦身缩短拉取时间 减少跨可用区流量 对低优先级任务使用 Spot/抢占实例 小结 成本优化不是一次性动作，而是持续运营。先让容量模型可信，再谈更激进的降本策略。
常见事故模式 发布时最容易看到这几类问题： 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。 结语 高可用不是靠单个参数，而是探针策略和退出流程共同生效。发布稳定性通常是这些细节堆出来的。
背景 很多团队第一次把服务上到 Kubernetes 时，会觉得滚动发布已经帮我们解决了“不中断发布”的问题。 实际上，RollingUpdate 只是开始，不是答案。 线上真正导致发布抖动的，往往是这些细节： 新 Pod 还没准备好就被加进流量 老 Pod 收到 SIGTERM 后立刻退出 长连接请求被中途切断 readiness 和 liveness 配置混乱 ingress、service、应用本身三层状态不同步 想做到真正意义上的零中断，得把整条链路串起来看。 先理解滚动发布到底做了什么 Deployment 默认使用 RollingUpdate 策略，大致过程是： 拉起新 Pod 等新 Pod Ready 逐步减少旧 Pod 直到新版本全部替换完成 一个常见配置如下： strategy: type: RollingUpdate rollingUpdate: maxUnavailable: 0 maxSurge: 1 这表示： 发布期间不允许可用实例减少 每次最多多起一个新 Pod 它能降低抖动概率，但不能保证应用层面的请求一定不受影响。 Readiness Probe 决定流量什么时候进来 如果只配了 liveness，没有配 readiness，基本等于告诉集群： “只要进程还活着，就可以接流量。” 这在很多服务里是错的。 比如一个 API 服务启动后还要做这些事情： 加载配置 预热缓存 建立数据库连接池 初始化路由和依赖客户端 在这些动作完成之前，进程虽然活着，但根本不适合接请求。 readinessProbe: httpGet: path: /ready port: 8080 initialDelaySeconds: 3 periodSeconds: 5 timeoutSeconds: 1 failureThreshold: 3 livenessProbe: httpGet: path: /health port: 8080 initialDelaySeconds: 10 periodSeconds: 10 这两个探针不要混用： ...