ACK Pro大规模集群使用建议

索引

• 谨慎使用ACK Pro大规模集群的原因
• 建议一：避免单个集群规模过大，合理拆分集群
• 建议二：严格控制单个集群中资源数量和大小
• 建议三：将ACK集群升级至最新K8s版本
• 建议四：关注ACK Pro托管版集群控制平面的指标
• 建议五：优化客户端访问模式

谨慎使用ACK Pro大规模集群的原因

ACK集群的可用性和性能与集群中资源（Nodes、DaemonSets、Pods、Configmaps、CRD等）数量、资源访问频率、访问模式紧密相关。不同的变量组合下，APIServer承载的压力和性能也极为不同。所以集群管理者需要密切关注集群规模变化，合理设计和使用规模化集群，以确保集群可靠运行工作负载。

推荐您在使用大规模集群（节点规模大于100，Kubernentes资源量较大）时，遵循以下最佳实践原则，以提升集群整体稳定性。

建议一：避免单个集群规模过大，合理拆分集群

当单个集群规模过大时，不仅会给Master资源容量和性能带来挑战，也会增加集群业务层面的故障爆炸半径。单个集群节点数上限为5000。建议选择多个集群承载业务，尤其避免在业务层面All in one cluster的架构设计。

建议二：严格控制单个集群中资源数量和大小

对于集群中的资源，ACK Pro版集群对其设置了容量限制。详细信息，请参见容量限制。

及时清理不使用的Kubernetes资源，例如ConfigMap、Secret和PVC等。大量的Pending Pod会对kube-apsierver、kube-controller-manager和kube-scheduler等持续产生压力，影响ACK集群的可用性及性能。建议将Pending Pod数量保持在1000以下。

建议三：将ACK集群升级至最新K8s版本

建议将ACK集群升级至最新版本。最新版本往往有更好的性能优化，以及CPU、内存消耗优化。

关于ACK发布Kubernetes的版本说明，请参见Kubernetes版本发布说明。关于集群升级，请参见升级ACK集群K8s版本。

建议四：关注ACK Pro托管版集群控制平面的指标

• kube-apiserver CPU和内存资源水位指标。示例如下。
• kube-apiserver的全部LIST请求中穿透到etcd的LIST请求。示例如下。

建议五：优化客户端访问模式

• 优先使用client-go的List-Watch模式，通过本地Cache查询数据，避免List请求直接访问APIServer。
• 对于未访问本地缓存的请求：
  • 通过在List请求中设置resourceVersion=0参数来改进组件。 请求会从kube-apiserver Cache中查询，减少APIServer与etcd之间的内部交互次数，例如8sClient.CoreV1().Pods("").List(metav1.ListOptions{ResourceVersion: "0"})。
  • 尽量避免全量List资源，设置合理的List Filter。
• 使用Protobuf代替JSON访问非CRD资源。默认情况下，Kubernetes返回序列化为JSON的对象时，内容类型为application/json，此为API的默认序列化格式。客户端可以使用更有效的Protobuf请求这些对象，以优化大规模性能、减少网络传输数据量。并非所有API资源类型都支持Protobuf，作为客户端则应在请求Accept请求头中指定多种内容类型以支持回退到JSON，例如Accept: application/vnd.kubernetes.protobuf, application/json。
• 避免在多个地方创建用于监听对象的控制器（例如DaemonSet）。控制器监听的对象可能会频繁更改，占用资源，影响集群性能。
  重要 建议在单个节点上创建一个中心化控制器，实现对象数据的监听及处理。
• 如果Pod中运行的逻辑不需要访问Kubernetes API，建议关闭default service account挂载。