文档中心

容器服务

大规模集群管理

大规模集群版本和配置

大规模集群版本和配置

在构建大规模集群的生产环境时，请参考本文完成集群版本选择与组件配置。本文涵盖 Kubernetes 版本选型、控制面配置、数据面优化以及容器网络和 DNS 配置等关键内容。

版本选择

当集群中的节点数量超过 500 时，建议使用的集群 Kubernetes 版本和集群中重要组件的版本如下所示。

分类	名称	推荐版本	推荐理由
Kubernetes 版本	Kubernetes 版本	≥ 1.34	缓存一致性读和流式 List 响应特性 GA，对于包含大量资源的 List 请求场景，可有效降低 kube-apiserver 内存占用并提升系统稳定性。更多说明，请参见 Kubernetes 版本发布记录。
重要组件版本	vpc-cni	≥ v1.9.3	client-go 支持流式 List 响应。 informer 过滤 Headless Service 及其对应的 EndpointSlice。
		vpc-cni-controlplane	≥ v1.4.5	client-go 支持流式 List 响应。增大了默认 Worker 数。
		core-dns	≥ 1.10.1-vke.200	优化了默认 CPU 和内存资源的请求和上限。
		csi-ebs	≥ 1.3.1	client-go 支持流式 List 响应。
		csi-nas	≥ v1.3.2	client-go 支持流式 List 响应。
		csi-tos	建议使用 csi-fsx 替代 csi-tos	csi-tos 已经进入下线阶段，因此建议使用 csi-fsx 替代 csi-tos。
		csi-vepfs	≥ v0.17.0	client-go 支持流式 List 响应。
		fsx	csi-fsx ≥ v0.7.0 fsx-service ≥ v0.10.2	client-go 支持流式 List 响应。

控制面配置

分类	说明	观测方式	配置建议
控制面规格	VKE 提供 Kubernetes 控制面托管，在大规模集群限制和建议所述范围内，VKE 会根据控制面负载对 Kubernetes 控制面自动进行升配。通常情况下，该操作在 15 分钟内完成，且严格遵循滚动更新策略，其间长链接会断开重连，kube-apiserver 响应延迟会有抖动，理论上对业务无影响。	为集群开启云原生观测能力，详情请参见开启观测。	确保集群使用在大规模集群限制和建议范围内，超出限制会影响集群稳定性。当集群短时间上量幅度超过 500 节点时，为避免突发流量引起的抖动，可通过提交工单或联系您的火山引擎客户经理进行升配。
APIServer CLB 升配	Kubernetes 数据面组件通过 CLB 访问 APIServer，当集群 Node 和 Pod 规模增大时，APIServer 的入站流量会显著增加，CLB 带宽容量可能成为瓶颈，导致数据面组件与控制面的通信延迟升高甚至超时。 VKE 默认使用按规格计费 CLB 实例，最高提供 2000 Mbps 带宽上限，对于大规模集群或高并发场景，需要根据实际流量监控情况适时升配 CLB 带宽规格。	查看 APIServer 关联的 CLB 实例带宽的监控数据。详情请参见查看监控数据。	配置 CLB 带宽使用率告警，详情请参见配置告警策略。集群节点数超过 1000 或 CLB 带宽利用率持续超过 70% 时，应及时升配或改为按使用量计费。更多说明，请参见转换实例计费方式。
kube-controller-manager 配置	VKE 控制面自动升降配会动态调整 kube-controller-manager 参数，通常无需额外关注。	为集群开启云原生观测能力，并通过 kube-controller-manager 监控看板，查看 controller 队列长度和延迟等信息。详情请参见开启观测、控制面服务观测。	当集群默认调谐性能无法满足需求时，可通过调整 kube-controller-manager 的 kubeApiQps 和 KubeApiBurst 参数来调谐集群性能。详细操作，请参见查看集群信息中的控制面参数配置页签内容。较大 Worker 节点数和 QPS/Burst 会对 kube-apiserver 造成额外压力，请经过测试后，再应用到线上环境。

数据面配置

分类	说明	配置建议	推荐值
kubelet 配置	VKE kubelet 的 QPS/Burst 默认值为 5/10，当节点上 Pod 数量多且变更频繁时，可能出现 Pod 状态更新缓慢、调度延迟、存储卷挂载缓慢等显著性能问题，建议您调大--kube-api-burst和--kube-api-burst参数。调大该两个参数会显著增加 kubelet 和 kube-apiserver 之间的 QPS，请重点关注 kube-apiserver 负载，逐步地增加该参数。	调整 kubelet 的--kube-api-burst和--kube-api-burst参数。详情请参见配置节点池 Kubelet 参数。逐步增加--kube-api-burst和--kube-api-burst参数取值，并关注 kube-apiserver 性能和资源用量，经过测试后，再应用到线上环境。	kubelet 各参数配置推荐值如下： kubeAPIQPS：50 kubeAPIBurst：100 eventRecordQPS：50 eventBurst：100 registryPullQPS：10 registryBurst：20
节点启动加速	节点启动主要包含 ECS 实例的创建、节点初始化、下载系统组件镜像、节点状态刷新等过程，不同 ECS 机型启动速度有所区别，通常节点启动的端到端耗时在 5 min 以内。	对于节点启动速度有更高要求的用户，可使用磁盘快照进行加速，详情请参见使用数据盘快照加速节点扩容。	无
容器镜像加速	在大规模集群中，当应用镜像达到数 GB 甚至数十 GB 时，镜像拉取时间会成为 Pod 启动的主要瓶颈。集中式镜像仓库在并发拉取时容易成为网络带宽瓶颈。VKE 提供两种加速方案： P2P 镜像加速利用节点内网带宽在节点间分发镜像，适合大规模集群并发拉取场景。镜像懒加载（Nydus）按需加载镜像数据热点区域，实现秒级启动就绪。两种方案可结合使用以获得最佳效果。	在容器服务控制台目标集群的总览页面控制面参数配置页签，保证 AlwaysPullImages 处于关闭状态。详情请参见查看集群信息。镜像加速方案，请参见 P2P 镜像加速方案、容器镜像懒加载方案。	无

网络规划

分类	说明	配置建议	推荐值
容器网络模式	有两种容器网络模型： VPC-CNI：VKE 容器网络的默认模式，基于原生 VPC，能够支持更多的节点数量和更大的工作负载。在 VPC-CNI 模式下，VPC 会为所有 Pod IP 地址分配一个 IP 地址段，每个节点会从这个地址段中划分出一块子网段，用于分配给其上的 Pod IP 地址，具有性能高，扩展性好的特点。 Flannel：为每个新节点在 VPC 网络的路由表中添加一条新的自定义路由。VPC 路由表最多支持 1000 条规则，因此 Flannel 模型集群最多支持 1000 个节点，不适合大规模工作负载。更多说明，请参见 VPC 路由的限制。	容器网络模式一旦选择无法更改，为保证集群扩展性，请使用 VPC-CNI 的容器网络模式。	无
集群网段规划	在大规模 Kubernetes 集群中，容器网络的 IP 地址网段的大小直接决定集群可承载的节点数量和 Pod 数量上限。	节点数超过 1000 时，推荐优先选用10.0.0.0/8网段的 VPC，确保有足够的 IP 地址空间进行子网划分。提前评估 Service 网段规划容量，创建后无法调整网段大小。	无
Cilium Operator 配置	Cilium Operator 会周期性回收 CiliumIdentity，CiliumIdentity 最大上限为 65535。在未独立部署的情况下，Cilium Operator 集成在 Cello DaemonSet 中，每个节点一个副本。当节点数量增多时，所有副本通过 Lease 机制进行 Leader Election，会产生大量对 kube-apiserver 的访问。对于大规模集群，应当将 Cilium Operator 从 DaemonSet 中解耦，采用独立 Deployment 部署并配置合理的副本数。	在容器服务控制台目标集群的组件管理页面，通过配置 vpc-cni 组件，调整 Cilium Operator 配置：超过 500 节点的集群，建议开启 Cilium Operator 独立部署。超过 50000 Pod 的集群，建议提升 Cilium Operator 的资源配置。	独立部署 Cilium Operator 的副本数：建议最少设置为 3。 Cilium Operator 的 Memory Limit：议最少设置为 8 GiB。
VPC-CNI IP 池化设置	Cello 通过池化机制缓存 VPC ENI 和 IP 资源来提升 Pod 拉起速度。在默认池化参数下（如poolTarget=3），800 个节点的集群会缓存约 2400 个空闲 IP。对于大规模集群或子网容量有限的场景，需要根据实际需求评估，并适当调大或调小池化参数。	根据业务需求，在容器服务控制台目标集群的组件管理页面，通过配置 vpc-cni 组件，调整池化参数：调大：可提升 Pod 创建吞吐量并降低突发时对 VPC OpenAPI 的访问压力，但会造成 IP 资源预占和浪费。调小：节省 IP 但可能影响 Pod 启动速度。
NetworkPolicy 限制	集群若启用了 NetworkPolicy 来控制 Pod 之间的访问，则每个节点上的 Cello 组件会 ListWatch 集群内所有的 CiliumEndpoints，在节点规模超过 1000 时，会给 APIServer 带来访问压力。	如果无需使用 NetworkPolicy，请确保 vpc-cni 组件配置中 NetworkPolicy 设置为关闭（默认为关闭）。如果使用 NetworkPolicy，建议同步设置 Cilium 的 Labels，避免让 Networkpolicy 参与到 CiliumIdentity 的分配，造成 CiliumIdentity 达到上限。更多说明，请参见参考 Cilium 官方文档。	无
Service 和 NetworkPolicy 数量	VPC-CNI 模型集群中，Service 和 NetworkPolicy 均基于 Cilium 的 BPF Map 机制实现，其数量与 BPF Map 大小有关。每个 Service 对应的 Pod 会在 Backend Map 中生成唯一条目；每个被 NetworkPolicy 选中的 Pod 对应一个 Policy Map，每条 NetworkPolicy 规则都会在该 Map 中生成一条记录。随着集群中 Service、Pod 规则和 NetworkPolicy 规则数量的增长，相关 BPF Map 可能触及容量上限，导致 Service 或 NetworkPolicy 规则无法生效，Service 状态异常、访问异常以及访问控制不符合预期。	根据集群预期规模，您可以提交工单联系 VKE 团队提前规划并合理配置 BPF Map 参数，避免因容量不足影响业务正常运行。同时通过 VMP 使用如下指标观测 BPF Map 的容量： Service Metrics：max(cilium_bpf_map_pressure{map_name=~"lb."}) by (map_name) NetworkPolicy Metrics：max(cilium_bpf_map_pressure{map_name=~"policy."}) by (map_name)	无

集群 DNS 规划

分类	说明	观测方式	配置建议
CoreDNS 副本调整	CoreDNS 作为集群内 DNS 解析服务，其副本数直接影响 DNS 查询的处理能力。在大规模集群或高 DNS 请求负载场景下，默认配置可能不满足需求，应当根据实际负载情况手动调整 CoreDNS 副本数。	为集群开启云原生观测能力，并通过 core-dns 监控看板，查看错误率和请求延迟等信息。详情请参见开启观测、DNS 服务观测。	对于 500 节点以上的集群，将 CoreDNS 扩容至 6 个以上。详情请参见 CoreDNS 最佳实践。
node-local-dns 部署	NodeLocal DNSCache 通过在每个节点上部署本地 DNS 缓存 DaemonSet，使 Pod 的 DNS 查询在本地完成解析，将集中式 DNS 负载分散到各节点，同时降低查询延迟。	无	对于 500 节点以上的集群，建议开启 NodeLocalDNS 部署。详情请参见使用 NodeLocal DNSCache 缓存代理。

最近更新时间：2026.05.15 17:34:21

这个页面对您有帮助吗？

有用

有用

无用

无用