疯狂的SRE

深色模式

大规模集群万节点挑战 ​

摘要：本文面向规划超大规模单集群的平台架构师，厘清 Kubernetes 官方规模认证边界，剖析 etcd、API Server、调度器、节点密度在万节点量级下的瓶颈，并给出单集群扩容与多集群拆分的权衡。覆盖版本：Kubernetes v1.28+。

适用版本与前提 ​

  • Kubernetes：v1.28+（规模认证数字以官方大集群文档为准）
  • 工具：kubectl、etcdctl、kubectl get --raw /metrics
  • 前提：理解控制平面组件职责与 etcd 一致性模型

背景与问题 ​

"万节点"是一个极具诱惑但容易误读的目标。Kubernetes 官方对单集群规模有明确认证边界：截至官方文档，Kubernetes 支持最多 5,000 节点，且需同时满足：每节点 ≤110 Pod、集群总 Pod ≤150,000、总容器 ≤300,000（见参考资料 [1]）。这意味着"万节点"已超出官方认证范围，必须把它当作"定制工程"而非"开箱即用能力"来对待。

版本相关

官方文档当前标注 v1.37 支持 5,000 节点；更早版本（含 v1.28）的认证规模同样以 5,000 节点为上限，但具体 Pod/容器配额请以你目标版本的官方文档为准。本文所有规模数字均引自参考资料 [1]，非本文独立实测。

核心概念：规模的三道天花板 ​

架构与原理 ​

etcd 是硬约束 ​

所有写最终落到 etcd。etcd 是 Raft 强一致存储，每次写需 leader 落盘 fsync 并复制到多数派。规模增长带来：

  • 对象数增长 → MVCC 历史膨胀、压缩/碎片压力
  • watch 客户端（kubelet、controller、scheduler）数增长 → 每个 apiserver 维护的 watch 连接与缓存线性上升
  • 磁盘 fsync 延迟直接转化为写 P99

官方要求 etcd 运行在专用机器、使用 SSD、避免资源争抢（见参考资料 [2]）。

API Server 是聚合扇出点 ​

apiserver 无状态但需为每个 watch 客户端维护缓存。节点越多，apiserver 内存与 CPU 随 watch 数量增长。大集群建议：垂直扩容优先，达到收益拐点后再水平扩（见参考资料 [1] 的 control plane components 段落）。

调度器是全量打分瓶颈 ​

默认调度器对每个待调度 Pod 评估全部节点。percentageOfNodesToScore 控制打分节点比例，是可调的关键旋钮（详见下文）。

生产实践：单集群能做的调优 ​

1. 节点密度 ​

在 ≤110 Pod/节点官方约束内，提高密度可显著减少节点总数、降低控制平面相对负载。但密度提升会把压力转移到 kubelet、CNI、节点内核（conntrack、ulimit）与 IP 规划。

yaml
# 通过 kubelet 限制单节点 Pod 上限（默认 110，与官方上限一致）
# /var/lib/kubelet/config.yaml
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
maxPods: 110

版本相关

maxPods 受 CNI 分配的 IP 池大小与节点内核参数共同约束。把密度推到数百 Pod/节点属非官方认证场景，[未实测]，需按实际 CNI 与内核参数验证网络与 pid/文件描述符上限。

2. 调度器打分比例 ​

yaml
# 调度器配置（KubeSchedulerConfiguration），大集群建议调高打分比例上限
apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
profiles:
  - schedulerName: default-scheduler
percentageOfNodesToScore: 50

含义：仅随机打分约 50% 节点即停止寻找"足够好"的节点，降低调度延迟。[版本相关]：该参数行为在 v1.28+ 一致，但取值需结合集群节点数与调度吞吐实测。

3. 控制平面垂直优先 + 多实例 ​

每个故障域至少 1 个控制平面实例提供容错；负载均衡应把同故障域的 kubelet 流量导向同域 apiserver，减少跨域延迟（见参考资料 [1]）。

4. 事件与存储隔离 ​

大集群把 Event 存到独立 etcd 实例，隔离事件写放大（见参考资料 [1]）。

万节点的现实路径 ​

当节点数逼近并超过 5,000，单集群调优收益递减，需架构层面决策：

多集群 vs 单集群

  • 单集群 + 定制：需投入专项工程（etcd 分片、apiserver 水平扩展、定制调度/CRD 控制器），运维复杂度与故障爆炸半径同步上升；官方不保证稳定性。
  • 多集群：按业务/地域/租户拆分，配合 KubeFed / Cluster API / 自研控制面做联邦。爆炸半径小、可独立升级，但跨集群调度与统一视图需额外建设。
  • 节点密度优先：在合规与 SLO 允许下尽量提高单节点密度，用更少节点承载更多负载，是性价比最高的"伪万节点"路径，但受 ≤110 Pod/节点硬约束。

生产危险

不要把"万节点单集群"作为默认目标。超出官方认证规模后，任何 etcd 抖动都会被放大为全集群不可用。落地前必须有 etcd 快照恢复演练、控制平面容量压测与明确的爆炸半径预案。

验证 ​

bash
# 当前规模与配额使用
kubectl get nodes --no-headers | wc -l
kubectl get pods -A --no-headers | wc -l

# etcd 存储与延迟（P99 fsync）
kubectl get --raw /metrics | grep etcd_mvcc_db_total_size_in_bytes
kubectl get --raw /metrics | grep etcd_disk_wal_fsync_duration_seconds_bucket

# 调度积压
kubectl get --raw /metrics | grep scheduler_pending_pods

回滚与清理 ​

  • 单集群扩容（加节点）本身可逆：kubectl drain + 缩容节点池即可回收
  • 引入独立 etcd / 调整配额属不可逆风险变更，需先快照：ETCDCTL_API=3 etcdctl snapshot save /backup/etcd.db
  • 多集群拆分是长期架构决策，无"一键回滚"，需在设计阶段保留单集群兼容的应用部署描述

故障排查 ​

规模相关现象根因动作
新 Pod 长时间 Pending调度器积压 / 节点分数不足调 percentageOfNodesToScore、扩容调度器
watch 延迟、组件 OOMapiserver 内存随对象数增长升 --target-ram-mb、独立事件 etcd
etcd 写拒绝达 quota-backend-bytes压缩 + defrag + 升配额
跨域延迟高apiserver 流量跨故障域修正负载均衡同域路由

性能、容量与成本 ​

成本权衡

专用 etcd 节点（建议 5 个，配本地 NVMe）、垂直扩容的 apiserver 节点、按故障域冗余，是万节点量级的主要固定成本。相比堆节点数，提升节点密度（减少节点总数）通常更省成本，但会抬高单节点故障爆炸半径——需在"省钱"与"容错"间显式权衡。

常见坑 ​

  • 误以为"kubeadm 能装就能扛万节点"——安装与规模是两回事
  • 只盯节点数，忽略 150,000 Pod 总配额先触顶
  • 把 ≥5000 节点的稳定性当成官方承诺而非定制工程 [未实测]
  • 多集群拆分后缺乏统一可观测与跨集群调度，反而增加运维负担

替代方案与权衡 ​

  • Cluster API：以声明式管理多集群生命周期，适合按环境拆分
  • Kueue / 调度分片：把批量负载与在线负载隔离，缓解单调度器压力 [版本相关，请以目标版本特性门为准]
  • 虚拟节点（如云厂商虚拟 Kubelet）：把部分负载下沉到 Serverless，减少真实节点数，但带来调度语义差异

参考资料 ​

基于 VitePress 构建 · 托管于阿里云 ECS

Copyright © 2026 CrazySRE