| etcd 磁盘 | 在大规模集群中，etcd 对磁盘 I/O 非常敏感。 | 为 etcd 数据目录使用专用 NVMe SSD。 |
| etcd 数据库大小 | 数据库超过约 8 GB 会显著增加延迟、资源使用和恢复时间。 | 保持 etcd 数据库 ≤ 8 GB；删除未使用对象，保持频繁更新对象较小（约 ≤100 KB）。 |
| etcd 键频繁变动 | 高频读写键会给 etcd 带来压力。 | 分析 etcd 指标，查找并减少热点键。 |
| etcd 中每种资源类型的数据大小 | 每种资源类型数据总量过大使全量列表操作代价高昂，可能阻塞控制器。 | 保持每种资源类型的数据总量 ≤ 800 MB；清理未使用的 Deployments/Services。 1 |
| API 服务器 LB 带宽和连接数 | 负载均衡器带宽或连接数限制可能导致节点变为 NotReady。 | 预先监控和配置 API 服务器负载均衡器。 |
| 每个命名空间的 Services 数量 | 大量 Services 会导致 Pod 中环境变量注入过多，启动变慢。 | 保持每个命名空间的 Services 数量 < 5,000，或设置 enableServiceLinks: false。 2 |
| 集群中 Services 总数 | 过多 Services 会增加 kube-proxy 规则，影响性能。 | 保持 Services 总数 < 10,000，并垃圾回收未使用的 Services。 1 |
| CoreDNS | 大量 Pod 会降低 CoreDNS 性能。 | 运行 NodeLocal DNSCache（nodelocaldns）。 |
| Pod 更新速率 | 高更新速率会将 Endpoint/EndpointSlice 变更推送到所有节点，可能引发风暴。 | 减少 Pod 变动；对于 RollingUpdate，设置保守的 maxUnavailable 和 maxSurge。 |
| ServiceAccount 令牌挂载 | 每个令牌 Secret 会创建一个 watch，过多 watch 会增加控制平面负担。 | 对不需要 API 访问的 Pod，设置 automountServiceAccountToken: false。 3 |
| 对象数量/大小 | 累积的 ConfigMaps、Secrets、PVC 等增加控制平面负载。 | 限制 ReplicaSet 历史（revisionHistoryLimit），并为 Jobs/CronJobs 使用 ttlSecondsAfterFinished。 |
| Pod 请求/限制 | 请求与限制差距过大可能在节点故障时触发级联故障。 | 尽可能将请求设置为与限制相等。 |
| 控制器重启与监控 | 控制器或 API 服务器重启会触发重新列表，可能导致 API 服务器过载。 | 监控控制器，合理设置资源避免重启，减少不必要的控制平面操作。 |
