https://ops.docs.72602.space/using/k8s/more_than_1k_nodes/index.html 在这个量级上，K8s 不再只是“能跑就行”，而是进入可扩展性、稳定性、可观测性和资源效率的工程化挑战。下面我从架构、控制面、节点管理、网络、存储、安全和运维几个方面系统讲解。 🧠 一、总体思路：大规模集群的本质挑战 当节点规模超过 500～1000 时，Kubernetes 的瓶颈通常出现在： 控制平面（API Server / etcd）压力过大； 调度器吞吐不足； 资源对象（Pod / Node / Secret / ConfigMap 等）过多，导致 List/Watch 延迟； 网络和 CNI 插件在高并发下性能下降； 监控、日志、事件系统的数据量爆炸； 维护和升级变得极度复杂。 所以，大规模集群的重点是： 控制平面分层、节点池分区、流量隔离、观测与调优。 🏗️ 二、控制平面（Control Plane） 1. etcd 优化 独立部署：不要和 kube-apiserver 混布，最好是独立的高性能节点（NVMe SSD、本地盘）。 使用 etcd v3.5+（性能改进明显），并开启压缩和快照机制。 调大 --max-request-bytes 和 --quota-backend-bytes，避免过载。 定期 defrag：可用 CronJob 自动化。 不要存放短生命周期对象（例如频繁更新的 CRD 状态），可以考虑用外部缓存系统（如 Redis 或 SQL）。 2. API Server 扩展与保护 使用 负载均衡（HAProxy、NGINX、ELB）在多 API Server 之间分流； 调整： --max-mutating-requests-inflight --max-requests-inflight --target-ram-mb 合理设置 --request-timeout，防止 watch 卡死； Hugo en