# 集群过载保护最佳实践 集群过载是指Kubernetes集群中的资源（如计算、存储、网络等）超出集群的处理能力，导致集群控制平面（如etcd、kube-apiserver）或工作节点资源耗尽的状态。当过载发生时，集群性能将显著下降，甚至无法正常运行。因此，需要提前对集群进行过载保护，通过过载控制、LIST请求处理优化等机制确保集群在负载激增时仍能维持核心服务的稳定性，避免业务受损。本文将进一步分析集群过载的可能的原因和影响，并介绍CCE集群的过载保护机制，同时提供集群过载保护的相关建议。 #### 集群过载的原因 集群过载会影响整个Kubernetes环境的稳定性和业务连续性，其可能原因如下： - **计算、网络和存储资源需求量超出集群最大供给能力** ：etcd和kube-apiserver是集群控制平面的两个核心组件。etcd是后台数据库，负责存储所有集群数据，而kube-apiserver则是控制平面的入口，负责处理请求。为了减轻etcd的负担，kube-apiserver缓存了集群数据。此外，集群中的其他核心组件也会缓存集群中的各种资源，并监听这些资源的变化。当计算、网络和存储资源需求量超出集群最大供给能力时，**这些组件将长期处于高负载状态，一旦超过阈值将会导致集群过载**。 - **客户端查询数据量过大（如发起大量LIST请求、单个LIST请求查询大量数据）** ：以客户端通过Field Selectors查询集群中的Pod数据为例，当kube-apiserver缓存数据未被命中时，由于etcd无法按字段进行过滤，kube-apiserver需要从etcd拉取全量Pod数据。取得全量Pod数据后，kube-apiserver需要在内存中将全量Pod数据反序列化为结构化对象，然后遍历所有Pod进行字段匹配，最终返回过滤后的序列化结果。当此类查询并发量高时，各组件资源水位持续攀升，最终引发etcd延迟飙升、kube-apiserver OOM、控制循环失调等级联故障，从而导致整个集群进入过载状态。 图1客户端查询数据量过大示例 ![](https://support.huaweicloud.com/bestpractice-cce/zh-cn_image_0000002272408145.png "点击放大") #### 集群过载的影响 集群过载时，会出现Kubernetes API响应延迟增加、控制节点资源水位升高的现象，从而对集群控制平面及依赖该平面的业务产生影响，以下列举了一些可能受到影响的场景： - **Kubernetes资源管理**：在进行创建、删除、更新或查询Kubernetes资源的操作时，可能会出现失败的情况。 - **Kubernetes分布式选主**：集群过载可能导致主节点的Lease续期请求未能及时完成，进而导致主节点的Lease过期，失去领导地位。这将触发主节点的重新选举，可能造成短暂的服务中断、任务迁移、调度延迟以及集群性能波动。 - **集群管理**：集群严重过载时，可能会处于不可用状态，此时无法进行集群管理操作，例如创建或删除节点等。 #### CCE集群过载保护机制 - **过载控制** ：CCE集群从v1.23版本开始支持集群过载控制，在集群控制平面的资源压力较大时，通过减少处理系统外LIST请求来缓解压力。该功能需要开启集群的过载控制开关，详情请参见[集群过载控制](https://support.huaweicloud.com/usermanual-cce/cce_10_0602.html)。 - **L** **IST** **请求处理优化**：CCE集群从v1.23.8-r0、v1.25.3-r0版本开始对LIST请求处理进行了优化，即使客户端未指定resourceVersion查询参数， kube-apiserver也会基于其缓存响应请求，避免额外查询etcd，并能确保响应数据最新。此外，通过对kube-apiserver缓存增加Namespace索引，当客户端查询指定Namespace的指定资源时，无需再基于全量数据过滤属于此Namespace的资源，可以有效降低响应延迟时间和控制平面内存开销。 - **服务端精细化限流策略** ：通过API优先级和公平性（APF）对请求并发限制进行精细化控制，详情请参见[API优先级和公平性（APF）](https://kubernetes.io/zh-cn/docs/concepts/cluster-administration/flow-control/)。 #### 集群防过载建议 实际业务运行过程中，Kubernetes集群的性能和可用性受多种因素的影响，例如集群规模、集群资源数量和大小、集群资源访问量等。CCE服务基于长期云原生实践，持续对集群性能和可用性进行优化，并总结梳理了以下集群过载保护建议，您可根据实际业务情况进行应用，以保障业务长期稳定可靠运行。 | 类别 | 建议 | 费用说明 | |:---|:---|:---| | 集群层面 | [使用新版本集群] | 不涉及费用。 | | 集群层面 | [启用集群过载控制] | 不涉及费用。 | | 集群层面 | [调整集群管理规模] | 集群管理规模越大，费用越高，具体请参见[云容器引擎价格计算器](https://www.huaweicloud.com/pricing/calculator.html#/cce)。 | | 集群层面 | [控制集群资源数据量] | 不涉及费用。 | | 集群层面 | [控制资源对象更新频率] | 不涉及费用。 | | 集群层面 | [拆分集群] | 拆分集群时，费用的变化与集群数量和管理规模有关，具体请参见[云容器引擎价格计算器](https://www.huaweicloud.com/pricing/calculator.html#/cce)。 | | 运维层面 | [启用集群可观测能力] | - 使用Prometheus监控控制节点组件指标时，监控中心需要将相关指标上报至AOM。如果上报AOM的指标在[容器基础指标范围](https://support.huaweicloud.com/productdesc-aom2/aom_01_0023.html)内，则不涉及费用。否则，将会根据指标上报量、存储时长以及数据转储量收取相关费用，具体请参见[应用运维管理价格计算器](https://www.huaweicloud.com/pricing/calculator.html#/aom)。 - 开启日志采集之后，云日志服务将按用量收费，具体请参见[云日志服务价格计算器](https://www.huaweicloud.com/pricing/calculator.html#/lts)。 | | 运维层面 | [清理集群无效资源] | 不涉及费用。 | | 应用层面 | [优化客户端访问模式] | 不涉及费用。 | | 应用层面 | [利用ConsistentListFromCache特性门控] | 不涉及费用。 | | 应用层面 | [严格控制List请求的频率与范围] | 不涉及费用。 | #### 使用新版本集群 CCE集群版本迭代过程中，会不断带来新的过载保护相关功能及优化，建议您及时升级至最新版本集群。详情请参见[升级集群](https://support.huaweicloud.com/usermanual-cce/cce_10_0197.html)。 #### 启用集群过载控制 过载控制开启后，将根据控制节点的资源压力，动态调整系统外LIST请求的并发限制，维护控制节点和集群的可靠性。 详情请参见[集群过载控制](https://support.huaweicloud.com/usermanual-cce/cce_10_0602.html)。 #### 调整集群管理规模 如果集群控制节点资源水位线持续高位，比如持续出现内存使用率大于85%，建议您及时扩大集群管理规模，避免突发流量导致集群过载，详情请参见[变更集群规格](https://support.huaweicloud.com/usermanual-cce/cce_10_0403.html)。 ![](https://support.huaweicloud.com/bestpractice-cce/public_sys-resources/note_3.0-zh-cn.png) - 集群管理规模越大，控制节点规格越高、性能也更佳。 - CCE集群管理规模指的是集群支持管理的最大节点数，仅供业务部署规划参考**。**通常情况下，集群不一定能达到所选规模的最大节点数，实际规模与集群中资源对象的类型、数量、大小以及外部对集群控制平面的访问量等多个因素相关。 #### 控制集群资源数据量 Kubernetes集群的稳定性和性能在很大程度上依赖于控制面组件（尤其是kube-apiserver和etcd）对资源对象的管理能力。集群中资源对象（如Pods、Deployments等）的总数据量、单个对象的大小，决定了集群的可扩展性与可靠性。 如果etcd总数据量过大，会增加系统资源占用、引发服务性能瓶颈，包括数据读取和写入延迟、选举延迟等。如果每种资源类型的数据量过大，客户端全量访问该资源时可能会消耗大量系统资源，严重情况下甚至可能导致kube-apiserver无法完成初始化。 因此，建议控制etcd的总数据量、单类资源数据量，以保证大规模集群的性能、稳定性和可用性，如下表。 表1不同集群规模建议etcd数据量上限 | 集群规模 | 50节点 | 200节点 | 1000节点 | 2000节点 | |:---|:---|:---|:---|:---| | etcd数据总容量 | 500Mi | 1Gi | 4Gi | 8Gi | | 单类资源etcd数据量 | 50Mi | 100Mi | 400Mi | 800Mi | ![](https://support.huaweicloud.com/bestpractice-cce/public_sys-resources/note_3.0-zh-cn.png) 当etcd DB存储空间满时，etcd自身会产生No Space告警，CCE组件此时会自动触发内存碎片整理操作，尝试释放碎片化的存储空间，恢复集群的正常运行。如果碎片整理执行过程中发生错误，会在K8s集群中产生Defrag失败告警事件。 单个资源对象的体积（如大型ConfigMap、Secret或CRD实例）同样对集群性能构成显著影响： - etcd存储限制：etcd默认对单个键值对的大小限制为1.5MiB。虽然Kubernetes对象通常远小于此值，但若用户将大文件（如证书、配置文件、脚本）直接嵌入ConfigMap或Secret，可能导致单个对象接近该上限，增加etcd的I/O压力和网络传输开销。 - API请求延迟增加：大型对象在序列化/反序列化、网络传输和内存拷贝过程中消耗更多CPU和带宽，导致kube-apiserver处理单个请求的延迟显著上升。 - Informer缓存膨胀：使用Informer时，大型对象会被完整缓存在客户端内存中。若存在大量大对象，可能导致客户端（如Operator或自定义控制器）内存占用过高，甚至崩溃。 - GRPC传输限制与集群启动风险：kube-apiserver在启动初始化或执行大规模List操作时，会以分页形式从etcd获取数据。etcd对其GRPC消息大小设有默认限制（历史上为2GB）。当单类资源对象（如所有Pod）的总数据量过大，导致单页数据量超过此GRPC限制时，kube-apiserver将无法正常完成启动过程，致使集群状态异常且无法自动恢复。 为了避免这一问题，kube-apiserver将每页获取的对象数量上限设置为10000个。这意味着，单类资源的对象平均大小不应超过GRPC限制/10000。 - 对于早期版本的集群（如 v1.25.16-r10 之前），其GRPC限制为2GB，因此对象平均大小不应超过200KB。 - 对于新版本集群（v1.25.16-r10、v1.27.16-r10、v1.28.15-r0、v1.29.10-r0、v1.30.6-r0、v1.31.1-r0及以上），此限制已优化为依赖的grpc-go库的硬编码上限4GB，对象平均大小可放宽至不超过400KB。 您可以通过如下命令将某个Kubernetes对象导出为JSON文件，通过文件大小即可确定该对象的大小。 ``` kubectl get -n -o json --show-managed-fields > resource.json ls -l resource.json ``` #### 控制资源对象更新频率 在Kubernetes集群中，控制平面在稳态运行时负载较低，能够稳定处理日常任务。但在大规模变更操作期间------如频繁创建/删除资源、节点快速扩缩容------控制平面负载会急剧上升，容易导致集群响应延迟、超时甚至短暂不可用。这类操作通常伴随大量API请求、状态同步和资源调度，显著增加API Server、etcd和Controller Manager等组件的资源消耗。 举例而言，在2000节点集群中稳定运行10000个Pod，控制平面压力可控；而在50节点集群中若一分钟内创建10000个短期Job，则会引发请求峰值，导致API Server延迟升高甚至服务中断。 实测数据也证实了这一点：在v1.32版本集群中批量创建800个Deployment（每Deployment含9个Pod），当QPS达110时，kube-apiserver内存短期内激增约20GB；QPS降至50时，内存仍增长12GB。 因此，在执行大规模资源变更时，必须结合集群当前负载、资源利用率及历史性能指标，合理控制变更速率。建议采用渐进式操作并配合实时监控，以保障控制平面稳定，避免集群性能波动。同时，您还可以使用云原生观测能力监控集群的运行状况，例如通过Prometheus监控控制节点组件指标，详情请参见[启用集群可观测能力]。 #### 拆分集群 Kubernetes架构存在性能瓶颈，单个集群规模无法无限制扩大，如果您的集群规格已经达到2000节点，请拆分业务并使用多个集群进行部署。如果您在拆分集群方面遇到问题，可提交工单以获取技术支持。 #### 启用集群可观测能力 可观测性是保障集群可靠性、稳定性的基础，借助监控、告警和日志，集群管理员可以更好地理解集群的运行状况，快速发现异常并及时解决问题。 **配置监控** - 通过控制台的集群"概览"页面查看控制节点监控信息。 图2查看控制节点监控 ![](https://support.huaweicloud.com/bestpractice-cce/zh-cn_image_0000001898513614.png "点击放大") - 使用Prometheus监控控制节点组件指标，并重点关注kube-apiserver的内存使用量、资源数量、QPS、请求时延。详情请参见[使用Prometheus监控控制节点组件指标](https://support.huaweicloud.com/usermanual-cce/cce_10_0559.html)。 **配置告警** 告警是监控的延伸，在集群异常时及时预警，通知集群管理员尽快介入并处理恢复。您可以结合实际业务场景，针对kube-apiserver的内存使用量、资源数量、QPS、请求时延等指标配置告警，详情请参见[通过CCE配置自定义告警](https://support.huaweicloud.com/usermanual-cce/cce_10_0835.html)。 ![](https://support.huaweicloud.com/bestpractice-cce/public_sys-resources/note_3.0-zh-cn.png) 由于业务场景存在差异，诸如资源数量、QPS、请求时延等维度的监控指标，没有固定的正常与异常的分界线，不影响业务正常运行即属于正常范围。因此，无法定义通用的告警阈值，可以观察业务稳态运行时的指标数据，根据正常波动范围设置合理的告警阈值，或使用单位时间内指标数据的变化量作为告警检测对象。 **配置日志采集** Kubernetes日志可以协助您排查和诊断问题。其中，kube-apiserver组件的日志记录了客户端请求的详细信息，包含请求源、处理耗时和异常原因，可以用于过载问题的溯源分析。详情请参见[收集控制面组件日志](https://support.huaweicloud.com/usermanual-cce/cce_10_0554.html)。 #### 清理集群无效资源 建议及时清理不再使用的Kubernetes资源，如ConfigMap、Secret和PVC等，同时避免出现大量Pending Pod，避免资源数量过大导致控制平面额外消耗资源。 表2资源限制值 | 资源限制 | 说明 | 推荐方案 | |:---|:---|:---| | 单个命名空间下的Service数量 | 在Kubernetes集群中，kubelet会将集群中定义的Service的相关信息转换成环境变量并注入到在该节点上运行的Pod中，让Pod能够通过读取这些环境变量来发现Service，并且能够与Service进行通信。 如果一个命名空间中定义的Service数量过多，kubelet就需要为Pod注入更多的环境变量。这可能会导致Pod启动变慢，甚至在极端情况下，Pod可能无法启动，导致失败。 | 建议每个命名空间的Service数量不超过5000。 您可以选择不填充这些环境变量，将podSpec中的enableServiceLinks设置为false。更多信息，请参见[使用Service连接到应用](https://kubernetes.io/zh-cn/docs/tutorials/services/connect-applications-service/#accessing-the-service)。 | | 集群中Service总数 | 服务数量的增加会，导致kube-proxy的网络规则增多，对网络性能产生影响。 | 建议所有Service的总数量不超过10000。 对LoadBalancer类型的Service，建议总数不超过500。 | | 单个Service中的Endpoint最大数量 | 当一个Service关联了大量的Endpoint时，每次Endpoints对象发生更新，都会引起控制面组件kube-apiserver与节点上的kube-proxy之间同步大量数据，可能对网络和系统资源造成显著压力。 说明： Kubernetes提供[EndpointSlices](https://kubernetes.io/zh-cn/docs/concepts/services-networking/endpoint-slices/)特性来高效更新Endpoint，该特性在v1.19以上默认开启，并在v1.21集群开始进入稳定状态。 | 建议单个Service的Endpoints的后端Pod数量不超过3000。 | | 所有Service的Endpoint总数 | 当Service的Endpoint数量过多时，API Server需要处理更多的数据，可能会造成API Server负载压力过大，并导致网络性能降低。 | 建议所有Service关联的Endpoint的总数量不超过64000。 | | Pending Pod的数量 | 当集群中等待调度的Pod数量过多时，新提交的Pod可能会长时间处于Pending状态，无法及时分配到合适的节点上运行。如果Pod持续无法被调度，调度器会不断地周期性生成事件，导致事件过多。 | 建议Pending Pod的总数量不超过10000。 | #### 优化客户端访问模式 - 如果您需要多次查询集群资源数据，请优先考虑使用客户端缓存机制，避免频繁使用LIST查询。推荐使用Informer、Lister方式与集群通信，请参考[client-go文档](https://pkg.go.dev/k8s.io/client-go/tools/cache)。 如果必须要使用LIST查询，建议合理使用： - 优先查询kube-apiserver缓存，避免额外查询ETCD。v1.23.8-r0、v1.25.3-r0之前的集群版本，需要指定查询参数resourceVersion=0；v1.23.8-r0、v1.25.3-r0及之后的版本，CCE已进行优化，会默认查询缓存并确保缓存数据最新。 - 精确指定查询范围，避免非目标数据额外消耗资源，例如： ``` # client-go查询指定命名空间的Pod代码示例 k8sClient.CoreV1().Pods("").List(metav1.ListOptions{}) # kubectl查询指定命名空间的Pod命令示例 kubectl get pods -n ``` - 使用更高效的Protobuf格式代替JSON格式。默认情况下，Kubernetes返回序列化为JSON的对象，内容类型为application/json，这是API的默认序列化格式。但是，客户端可以使用更有效的Protobuf格式请求这些对象，以获得更好的性能。详情请参见[资源的其他表现形式](https://kubernetes.io/zh-cn/docs/reference/using-api/api-concepts/#alternate-representations-of-resources)。 #### 利用ConsistentListFromCache特性门控 对于版本大于1.31的Kubernetes集群，建议启用ConsistentListFromCache特性门控，更多说明请参见[Kubernetes v1.31：通过基于缓存的一致性读加速集群性能](https://kubernetes.io/zh-cn/blog/2024/08/15/consistent-read-from-cache-beta/)。启用后，kube-apiserver在处理List请求时，会优先尝试从其内部缓存中读取数据，而非每次都穿透到etcd后端。这能显著减少kube-apiserver与etcd之间的网络交互和序列化/反序列化开销，从而提升List请求的响应速度并降低后端存储的压力。 #### 严格控制List请求的频率与范围 建议您遵循以下策略，可以有效减轻List请求对Kubernetes控制面的冲击，保障集群的稳定性和高性能。 - 降低QPS：应极力避免在业务逻辑中循环或高频地调用List API。所有非必要的 List 操作都应被重构为基于 Informer 的事件驱动模式。 - 分页处理：对于已知会返回大量对象的List请求，应使用limit和continue参数进行分页处理，防止单次请求占用过多内存。 #### 相关文档 - [使用CCE需要关注哪些配额限制？](https://support.huaweicloud.com/cce_faq/cce_faq_00154.html) - 关于如何合理规划集群VPC网络及容器网络，请参见[集群网络地址段规划实践](https://support.huaweicloud.com/bestpractice-cce/cce_bestpractice_00004.html)。 - 关于如何保证工作负载的稳定性和可靠性，请参见[工作负载推荐配置](https://support.huaweicloud.com/bestpractice-cce/cce_bestpractice_10059.html)。 - 关于如何预防和避免集群的高危操作，请参见[高危操作一览](https://support.huaweicloud.com/usermanual-cce/cce_10_0054.html)。