文档中心

容器服务

请输入

大规模集群管理

大规模集群限制和建议

在大规模 Kubernetes 集群中，性能瓶颈主要体现在两个方面：一是集群所能容纳的资源对象总量（静态承载能力），二是在执行变更操作时系统能够承受的处理速率（动态吞吐性能）。本文将详细描述 VKE 的静态规模和请求限制，并提供优化建议，帮助您更好地应对规模扩展带来的挑战。

资源大小和数量限制

为确保大规模集群的稳定性与性能，请务必仔细审阅以下限制条件及对应的说明。一旦超出这些限制，集群可能会出现性能下降或稳定性问题。下表对 VKE 的通用使用限制做了进一步说明，同时也建议您了解开源 Kubernetes 对大规模集群的相关限制。

类别	限制项	限制值	说明与影响
数据量	ETCD 总容量	默认支持 8 GiB，最大支持 16 GiB	该值过大会影响性能，包括数据读写延迟、系统资源占用和选举延时，也会导致服务和数据恢复过程更加耗时。ETCD 数据库大小上限为 16GiB，超过该值集群会进入只读状态。
		每种类型 ETCD 对象总大小	800 MiB	单一类型的资源对象占用 ETCD 过多空间，会导致客户端（如 Controller）在 List 该资源时对 kube-apiserver 造成巨大压力，可能导致超时或 OOM。
		单个资源大小	1 MiB	单个资源对象过大会严重影响 ETCD 写入性能和 API Server 处理效率。对于高频修改的资源，建议将单个资源大小控制在 10 KiB 以下。在 ETCD 中，每次对键值对的更新都会生成一个新的历史版本，在高频更新大数据对象的场景下，ETCD 保存其数据的历史版本时会消耗更多的资源。
数量	Node 数量	Flannel 模型集群：默认 200，最大 1000 VPC-CNI 模型集群：5000	集群超过 5000 节点时，控制面组件会面临显著压力。Flannel 模型受 VPC 路由条目限制，上限为 1000 节点。大规模集群建议选用 VPC-CNI 模型。
		Pod 数量	启用 NetworkPolicy：50000 不启用 NetworkPolicy：150000	Pod 数量过多会增大 ETCD 存储压力，升高 API Server 的 List/Watch 操作延迟，拉长 Controller Manager 的资源同步周期，增加 Scheduler 的调度决策延迟，加剧控制面组件负载。建议单集群 Pod 总规模控制在 150000 以内。
		Pending Pod 数量	10000	Pending Pod 数量过多时，新提交的 Pod 可能会长时间处于等待状态，调度器会周期性产生 Event，继而可能导致 Event 泛滥。
		CiliumIdentities 数量	65535	Cilium 通过 Identity 来实现安全策略。每个具有唯一 Label 组合的 Pod 都会消耗一个 Identity。当 Identity 数量接近上限时，新的 Pod 可能无法获取网络身份，导致网络不通。
		HPA 数量	2000	每个 HPA 会每 15 秒处理一次。当 HPA 对象数量超过 2000 时，性能会线性下降，增加 kube-controller-manager 和 API Server 的压力。
密度	单节点 Pod 数量	Flannel 模型集群：默认 64，上限 256 VPC-CNI 模型集群：Pod 密度与 ECS 规格相关详细说明，请参见节点的 Pod 调度密度计算说明。	Flannel 模型集群：创建集群时，通过控制台指引，自定义设置。集群创建成功后无法修改。 VPC-CNI 模型集群：如需在单节点上运行更多 Pod，应选择支持更多弹性网卡的 ECS 规格。

应用负载的配置优化

分类	说明	配置建议
控制 Pod 对象大小	如需高频操作（如扩缩容）大型工作负载，应当将 Pod 大小控制小于 10 KiB 以下。Kubernetes 将资源清单存储在 ETCD 数据库中，每次获取资源时（List/Watch）都会传输完整清单，过大的数据量会显著增加 API Server 负载和网络带宽消耗，进而影响控制平面整体性能。当集群中 Pod 数量较多时，Pod 大小对性能的影响会成倍放大。	避免将大量配置数据直接内嵌在 Pod YAML 的env或args中，可使用 ConfigMap 或 Secret 进行挂载。
控制集群中 Watch 的总连接数	对于 Pod 配置的每个 Secret 和 ConfigMap，节点上的 kubelet 都会创建一个对应的 Watch 连接以监听变化。所有节点产生的 Watch 总数可能对控制平面造成巨大负载。当集群中的 Watch 数量超过 200000 时，可能会影响集群初始化时间，甚至导致控制平面频繁重启。	对于不需要变更的 ConfigMap 和 Secret，使用 Immutable ConfigMap 避免产生 Watch。 Immutable ConfigMap 示例如下： apiVersion: v1 kind: ConfigMap metadata: ... data: ... immutable: true 使用更大规格的节点提高 Pod 密度，在同等算力下减少节点数量，从而降低 Watch 总数。
禁止 Daemonset 按百分比更新	在数千节点的大规模集群中，批量创建或更新 DaemonSet 会对控制平面造成较高负载。如果 DaemonSet 中的 Pod 在启动过程中向 API Server 发起大量请求，将进一步加剧控制平面资源的消耗。	通过配置updateStrategy来严格控制滚动更新的并发度：控制滚动更新并发采用绝对值而非百分比，maxUnavailable建议不超过 10。建议设置minReadySeconds为 5 秒以上，确保新 Pod 完全就绪后再继续下一批更新。配置readinessProbe和livenessProbe，确保新 Pod 健康检查通过后才标记为 Ready。 maxSurge设置为 0，避免额外扩容带来的资源压力。选择业务低峰期执行大规模集群的 DaemonSet 更新。 updateStrategy配置 YAML 示例如下： apiVersion: apps/v1 kind: DaemonSet metadata: ... spec: minReadySeconds: 5 updateStrategy: rollingUpdate: maxSurge: 0 maxUnavailable: 10 type: RollingUpdate
设置 Job ttlSecondsAfterFinished	对于通过 CronJob 或其他机制创建的大量 Job 对象，应当配置ttlSecondsAfterFinished字段，使其在完成后自动被清理。未配置自动清理时，已完成和失败的 Job 及其 Pod 会持续占用 ETCD 存储空间和控制面资源，可能导致 API Server List 操作延迟升高、ETCD 存储膨胀以及命名空间内对象数量超限等问题。	为所有 CronJob 和一次性 Job 配置ttlSecondsAfterFinished，建议设置为 86400（24 小时）。定期排查并手动清理未配置 TTL 的历史 Completed 和 Failed 状态 Job。更多配置信息，请参见 Kubernetes 文档。 YAML 示例如下： apiVersion: batch/v1 kind: Job metadata: ... spec: ttlSecondsAfterFinished: 100 template: spec: containers: - name: pi
禁用 Pod 自动挂载 ServiceAccount 功能	默认情况下，Kubernetes 会为 Pod 自动挂载 ServiceAccount 的凭证相关 Secret，kubelet 还会在每个节点上为每个 Secret 创建 Watch 监听变化，会对 API Server 造成显著负载。	对于无需访问 API Server 的 Pod，在 Pod Spec 中设置automountServiceAccountToken: false。 YAML 示例如下： spec: automountServiceAccountToken: false # 关键配置：禁用 Token 自动挂载 containers: - name: app image: nginx:latest
禁用 Pod 自动注入 Service 环境变量	Kubernetes 默认会为每个 Pod 注入命名空间内所有活跃 Service 的环境变量（如 MY_SERVICE_SERVICE_HOST、MY_SERVICE_SERVICE_PORT 等）。当服务数量过多时，可能导致 Pod 启动时因环境变量过多而崩溃。	在 Pod Spec 中设置enableServiceLinks: false，禁用服务环境变量注入。 YAML 示例如下： spec: enableServiceLinks: false # 关键配置：禁用 Service 环境变量注入 containers: - name: app image: nginx:latest
设置 revisionHistoryLimit 减少 RS 数量	Kubernetes 默认保留 10 个历史 ReplicaSet 版本。在大规模集群中存在大量 Deployment 时，每个 Deployment 的历史 ReplicaSet 版本会被存储在 ETCD 中，持续消耗 ETCD 存储空间。	将 Deployment 的revisionHistoryLimit设置为 3~5，在保留必要回滚能力的同时减少历史对象积累。对于不需要历史版本的 Deployment 可设置为 0。更多配置说明，请参见 Kubernetes 文档。 YAML 示例如下： apiVersion: apps/v1 kind: Deployment metadata: ... spec: replicas: 5 revisionHistoryLimit: 3
禁止 Daemonset List-Watch ClusterScope 资源	避免在每个节点上部署独立控制器监听全量集群数据。这种模式在节点启动阶段会同时向 API Server 发送大量 List 请求以同步集群状态，且每个节点都会维护独立的 Watch 连接，导致 Watch 连接数和请求量激增，造成控制面巨大压力。	将全量数据监听的控制器以 Deployment 形式部署，而非 DaemonSet 形式部署到每个节点。对于必须在节点上运行的组件（如日志采集组件），通过设置FieldSelector或LabelSelector仅监听本节点 Pod。

APIServer 访问优化

分类	说明	配置建议
访问 APIServer	在大规模集群中，客户端访问 kube-apiserver 的方式对控制面稳定性有直接影响。不合理的 API 调用模式会导致 kube-apiserver 和 ETCD 的 CPU、内存和网络负载激增，严重时可能引发控制面过载或请求超时。VKE 已内置限流机制保护 API Server，但从客户端侧优化 API Server 访问模式，仍是保障集群性能的核心措施。	请参考 Kubernetes 开发者最佳实践。

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

这个页面对您有帮助吗？

有用

无用