背景 etcd 长期写删后会出现内部碎片，导致磁盘占用与 I/O 开销上升，影响 API Server 响应。 维护策略 监控数据库大小与可回收空间比例。 在低峰期执行 defrag，分节点滚动处理。 与快照备份策略联动，确保可回滚。 风险控制 禁止在控制面高峰窗口集中 defrag。 每次操作后验证 leader 稳定性与请求延迟。 把维护结果写入变更审计。 小结 etcd 维护是平台稳定性的基础工。把 defrag 变成制度化窗口操作，能显著降低控制面长尾风险。
为什么需要优先级 资源紧张时，系统必须明确“谁先活下来”。没有优先级，调度器只能随机牺牲。 设计原则 业务分层：核心链路、重要链路、可降级链路。 每层定义最小副本保障。 抢占只用于紧急保命，不用于日常扩容。 配套治理 为低优先级工作负载设置 PodDisruptionBudget。 为核心服务预留节点池或资源 buffer。 监控 preemption 频次与受害服务恢复时间。 小结 优先级和抢占不是“配置项”，而是容量治理策略。把 SLO 映射到调度规则，资源紧张时系统才有确定性。
事故模式 下游抖动时，上游大量重试，导致下游雪上加霜，最终全链路崩溃。表面看是“下游慢”，本质是“重试风暴”。 核心思路：重试预算 对每个服务设定单位时间最大重试量。 预算耗尽后只允许失败快返，不再重试。 将预算按调用优先级分层。 参数实践 请求总超时必须小于上游超时预算。 单次重试间隔采用指数退避 + 抖动。 只对幂等请求开启自动重试。 指标面 retry_attempts_total retry_budget_remaining upstream_timeout_rate outlier_ejection_count 小结 超时、重试、熔断必须联动配置。没有预算约束的重试机制，最终一定把局部故障放大成系统性故障。
典型事故 业务高峰来临，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 本质上是两个控制器。让它们协同的关键，不是“都开”，而是“职责分离 + 变更节流 + 可观测闭环”。
指标系统最怕什么 很多团队一开始埋点很积极，过一阵就发现存储暴涨、查询变慢。高基数标签通常是罪魁祸首。 典型高危标签： user_id request_id 完整 URL 路径 动态错误信息 设计原则 指标看聚合趋势，不看单请求细节 单请求细节放到 trace 或日志 标签值集合必须可控 一个可行做法 http.route 用模板路由，如 /users/:id 错误类型归类为固定枚举 把业务自定义标签做白名单审核 工程措施 在 SDK 层做标签拦截 给 metric pipeline 增加 cardinality 预算告警 定期扫描 top N label pairs 小结 可观测性不是“埋得越多越好”。指标、日志、追踪各司其职，系统才能长期稳定运行。