提升大规模 Kubernetes 集群的稳定性#

本指南帮助集群运维人员和 SRE 减少控制平面过载，提高可靠性，并限制大规模 Kubernetes 集群中的影响范围。

#注意事项

• 网络、存储、负载均衡器、日志和监控调优不在本文范围内；请参阅相关厂商文档。

问题	描述	优化建议
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 服务器过载。	监控控制器，合理设置资源避免重启，减少不必要的控制平面操作。

#Footnotes

1. https://github.com/kubernetes/community/blob/master/sig-scalability/configs-and-limits/thresholds.md ↩ ↩²

2. https://kubernetes.io/docs/tutorials/services/connect-applications-service/#accessing-the-service ↩

3. https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#opt-out-of-api-credential-automounting ↩