文档首页/ 云容器引擎 CCE/ 最佳实践/ 集群/ 集群过载保护最佳实践
更新时间：2024-06-21 GMT+08:00
查看PDF
分享

集群过载保护最佳实践

随着业务不断扩展，Kubernetes集群规模不断增大，导致集群控制平面负载压力增大。当集群规模超过Kubernetes控制平面的承载能力时，可能会出现集群因过载而无法提供服务的情况。本文帮助您了解集群过载的现象、影响范围和影响因素，并详细介绍CCE集群的过载保护能力，同时梳理了集群过载保护的建议措施。

什么是集群过载

集群过载时，会出现Kubernetes API响应延迟增加、控制节点资源水位升高的现象。在过载状况极端的情况下，可能会出现 Kubernetes API 无法响应，控制节点无法使用，甚至整个集群无法正常工作的情况。

集群过载会对集群控制平面及依赖该平面的业务产生影响。以下列举了一些可能受到影响的场景：

  • Kubernetes资源管理：在进行创建、删除、更新或查询 Kubernetes 资源的操作时，可能会出现失败的情况。
  • Kubernetes分布式选主：在基于Kubernetes Lease选主的分布式应用中，可能会因Lease续期请求超时而导致主实例重启。

    例如npd插件的controller组件，Lease续期失败后进行主备切换，即主实例重启备实例接管工作，业务无感知。

  • 集群管理：集群严重过载时，可能会处于不可用状态，此时无法进行集群管理操作，例如创建或删除节点等。

常见的导致集群过载的原因：

  • 集群资源数据量过大

    etcd和kube-apiserver是集群控制平面的两个核心组件，etcd是后台数据库，负责存储所有集群数据，而kube-apiserver则是控制平面的入口，负责处理请求。为了减轻etcd的负担，kube-apiserver缓存了集群数据。此外，集群中的其他核心组件也会缓存集群中的各种资源，并监听这些资源的变化。

    因此，集群资源数据量过大，会导致控制平面持续处于资源高水位状态，超过承载能力时就会出现集群过载现象。

  • 客户端查询数据量过大：如发起大量LIST请求，或单个LIST请求查询大量数据。

    假设客户端通过Field Selectors指定查询集群中的部分pod数据，并且需要查询etcd（客户端也可以指定从kube-apiserver缓存查询）。由于etcd无法按Field过滤数据，因此kube-apiserver需要从etcd查询全量Pod数据。然后，kube-apiserver会对结构化的Pod数据进行过滤、复制、序列化等操作。最后，响应客户端请求。

    由此可见，客户端LIST请求可能需要由多个控制平面组件来处理，并且处理的数据量更多、数据类型更复杂。因此，客户端查询大量数据，会导致etcd和apiserver持续处于资源高水位状态，超过承载能力时就会出现集群过载现象。

CCE集群过载保护能力

  • 过载控制：CCE集群从v1.23版本开始支持集群过载控制，在集群控制平面的资源压力较大时，通过减少处理系统外LIST请求来缓解压力。该功能需要开启集群的过载控制开关，详情请参见集群过载控制。
  • LIST请求处理优化：CCE集群从v1.23.8-r0、v1.25.3-r0版本开始对LIST请求处理进行了优化，即使客户端未指定resourceVersion查询参数， kube-apiserver也会基于其缓存响应请求，避免额外查询etcd，并能确保响应数据最新。此外，通过对kube-apiserver缓存增加Namespace索引，当客户端查询指定Namespace的指定资源时，无需再基于全量数据过滤属于此Namespace的资源，可以有效降低响应延迟时间和控制平面内存开销。
  • 服务端精细化限流策略：通过API 优先级和公平性（APF）对请求并发限制进行精细化控制，详情请参见API优先级和公平性（APF）。

集群防过载建议

以下将给出几种过载防护措施与建议：

使用新版本集群

CCE集群版本迭代过程中，会不断带来新的过载保护相关功能及优化，建议您及时升级至最新版本集群。详情请参见升级集群。

启用集群过载控制

过载控制开启后，将根据控制节点的资源压力，动态调整系统外LIST请求的并发限制，维护控制节点和集群的可靠性。

详情请参见集群过载控制。

启用集群可观测能力

可观测性是保障集群可靠性、稳定性的基础，借助监控、告警和日志，集群管理员可以更好地理解集群的运行状况，快速发现异常并及时解决问题。

配置监控

  • 通过控制台的集群总览页面查看控制节点监控信息。
    图1 查看控制节点监控
  • 使用Prometheus监控Master节点组件指标，并重点关注kube-apiserver的内存使用量、资源数量、QPS、请求时延。详情请参见使用Prometheus监控Master节点组件指标。

配置告警

告警是监控的延伸，在集群异常时及时预警，通知集群管理员尽快介入并处理恢复。您可以结合实际业务场景，针对kube-apisever的内存使用量、资源数量、QPS、请求时延等指标配置告警，详情请参见通过CCE配置自定义告警。

由于业务场景存在差异，诸如资源数量、QPS、请求时延等维度的监控指标，没有固定的正常与异常的分界线，不影响业务正常运行即属于正常范围。因此，无法定义通用的告警阈值，可以观察业务稳态运行时的指标数据，根据正常波动范围设置合理的告警阈值，或使用单位时间内指标数据的变化量作为告警检测对象。

配置日志采集

Kubernetes日志可以协助您排查和诊断问题。其中，kube-apiserver组件的日志记录了客户端请求的详细信息，包含请求源、处理耗时和异常原因，可以用于过载问题的溯源分析。详情请参见收集控制面组件日志。

控制集群资源数据量

集群资源数据量过大会降低etcd的性能，包括数据读取和写入延迟。除了总数据量以外，单类资源的数据量过大也会导致客户端全量查询该资源时控制平面消耗大量资源。因此，建议控制etcd的数据量及单类资源的数据量，如下表。

表1 不同集群规模建议etcd数据量上限

集群规模

50节点

200节点

1000节点

2000节点

etcd数据总容量

500Mi

1Gi

4Gi

8Gi

单类资源etcd数据量

50Mi

100Mi

400Mi

800Mi

清理集群无效资源

建议及时清理不再使用的Kubernetes资源，如ConfigMap、Secret和PVC等，同时避免出现大量Pending Pod，避免资源数量过大导致控制平面额外消耗资源。

优化客户端访问模式

  • 如果您需要多次查询集群资源数据，请优先考虑使用客户端缓存机制，避免频繁使用LIST查询。推荐使用Informer、Lister方式与集群通信，请参考client-go文档。

    如果必须要使用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("<your-namespace>").List(metav1.ListOptions{})
# kubectl查询指定命名空间的Pod命令示例
kubectl get pods -n <your-namespace>
  • 使用更高效的Protobuf格式代替JSON格式。默认情况下，Kubernetes返回序列化为JSON的对象，内容类型为application/json，这是API的默认序列化格式。但是，客户端可以使用更有效的Protobuf格式请求这些对象，以获得更好的性能。详情请参见资源的其他表现形式。

调整集群管理规模

如果集群控制节点资源水位线持续高位，比如持续出现内存使用率大于85%，建议您及时扩大集群管理规模，避免突发流量导致集群过载，详情请参见变更集群规格。

  • 集群管理规模越大，控制节点规格越高、性能也更佳。
  • CCE集群管理规模指的是集群支持管理的最大节点数，仅供业务部署规划参考。通常情况下，集群不一定能达到所选规模的最大节点数，实际规模与集群中资源对象的类型、数量、大小以及外部对集群控制平面的访问量等多个因素相关。

拆分集群

Kubernetes架构存在性能瓶颈，单个集群规模无法无限制扩大，如果您的集群规格已经达到2000节点，请拆分业务并使用多个集群进行部署。如果您在拆分集群方面遇到问题，可提交工单以获取技术支持。

总结

实际业务运行过程中，Kubernetes集群的性能和可用性受多种因素的影响，例如集群规模、集群资源数量和大小、集群资源访问量等。CCE服务基于长期云原生实践，持续对集群性能和可用性进行优化，并总结梳理了上述集群过载保护措施，您可根据实际业务情况进行应用，以保障业务长期稳定可靠运行。

父主题： 集群

相关文档