把 Kubernetes 单集群推到一万节点，已经不是简单的机器堆叠问题，而是控制面、数据面以及运维链路在规模效应下的系统性重构。很多团队在千节点阶段运行良好的参数，到了万节点会突然失效，根本原因就在于分布式系统里那些原本被忽略的常量，在数量级跃迁后变成了不可忽略的变量。
控制面组件在万节点下的性能瓶颈
API Server 作为集群的入口，在万节点环境中每秒要处理的请求量可能达到数万次。每个节点默认每 10 秒上报一次心跳，加上 Pod 状态同步、Endpoint 变更通知，API Server 的内存和 CPU 压力会呈非线性上涨。当 etcd 中存储的对象超过百万级别，单次 List 操作就可能占用上百 MB 内存，导致 API Server 频繁 GC 甚至 OOM。
etcd 本身也是关键瓶颈。Kubernetes 把全量状态都压在 etcd 上，万节点集群的 Pod、ConfigMap、Secret 等对象总量极易突破千万。etcd 的 Raft 协议要求写请求在多数节点落盘，磁盘 IOPS 不足时会直接推高写延迟，进而让调度器和控制循环出现大量重试。此时单纯加节点并不能解决问题，反而会因 Raft 成员增多降低投票效率。
一个常见的应对方式是拆分 API Server 的职责。例如将只读请求通过 --read-only-port 或者独立的只读实例承接，把写请求限制在特定实例上。同时可以给 kube-controller-manager 和 kube-scheduler 配置独立的选举空间，避免它们和 API Server 争抢同一套资源池。下面是一段资源限制的示例：
apiVersion: v1
kind: Pod
metadata:
name: kube-apiserver
spec:
containers:
- name: kube-apiserver
image: k8s.gcr.io/kube-apiserver:v1.28.0
resources:
requests:
cpu: "4"
memory: 8Gi
limits:
cpu: "8"
memory: 16Gi
etcd 存储与调优的核心对策
面对海量对象，首先要做的是减轻 etcd 的写入负担。Kubernetes 提供了不少可降频的参数，比如把 --node-monitor-grace-period 调大，降低节点状态变更频率。更重要的是开启 etcd 的碎片化整理和配额管理，避免历史版本堆积导致 db 文件膨胀。在生产中，我们通常会把 etcd 部署在独享的 SSD 机器上，并限制单集群 etcd 成员数为 5，以避免投票延迟过高。
另一个有效手段是使用 etcd 的自动压缩功能。Kubernetes 默认保留 5 分钟的历史版本，但在万节点下这 5 分钟可能包含上百万次写操作。通过配置 --auto-compaction-retention=1h 和 --quota-backend-bytes，可以显著降低存储压力。下面的命令展示了如何查看 etcd 的碎片情况：
ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 --cacert=/etc/etcd/ca.crt --cert=/etc/etcd/etcd.crt --key=/etc/etcd/etcd.key defrag
如果单 etcd 集群依然无法支撑，还可以采用多 etcd 后端或者按资源类型分片的方式。例如把 Event 对象单独放到一个 etcd 实例，因为 Event 写多读少且价值较低，隔离后能保护主 etcd 的稳定性。这种架构虽然增加了运维复杂度，但能明显提升控制面的可用性。
大规模网络与节点管理的实践方案
网络插件在万节点下的表现常被低估。以默认的 VXLAN 模式为例，每个节点都会维护全量的 Pod 路由信息，万节点时ARP表和转发规则急剧膨胀，新 Pod 上线延迟变长。实践中更推荐采用云厂商的 ENI 插件或者 Cilium 的 eBPF 模式，它们绕过了 kube-proxy 的 iptables 规则链，用哈希表直接做负载均衡，性能提升明显。
节点管理方面，必须压制不必要的心跳和状态同步。可以通过修改 kubelet 的 --node-status-update-frequency 从 10 秒改为 30 秒甚至 60 秒，并相应调整 API Server 的 --node-monitor-period。对于批量加入集群的节点，建议使用节点池分批注册，避免瞬时大量 Node 对象写进 etcd。以下为 kubelet 参数调整片段：
# 修改 /var/lib/kubelet/config.yaml 或启动参数 nodeStatusUpdateFrequency: 30s nodeLeaseDurationSeconds: 40
最后，万节点集群的监控和告警也要重新设计。Prometheus 若直接抓取所有节点指标，自身就会成为瓶颈。应采用联邦或者 Agent 模式，把指标在节点侧聚合后再上报。只有把控制面、存储、网络、监控四条链路同时改造，Kubernetes 万节点集群才能真正跑得稳、扩得动。
Kubernetes万节点集群集群架构修改时间：2026-08-17 21:02:40