Kubernetes 弹性伸缩全场景解析 (四)- 让核心组件充满弹性-阿里云开发者社区

开发者社区> 阿里云容器服务 ACK> 正文

Kubernetes 弹性伸缩全场景解析 (四)- 让核心组件充满弹性

简介: #### 前言 在本系列的前三篇中,我们介绍了弹性伸缩的整体布局以及HPA的一些原理,HPA的部分还遗留了一些内容需要进行详细解析。在准备这部分内容的期间,会穿插几篇弹性伸缩组件的最佳实践。今天我们要讲解的是 **cluster-proportional-autoscaler** 。

前言

在本系列的前三篇中,我们介绍了弹性伸缩的整体布局以及HPA的一些原理,HPA的部分还遗留了一些内容需要进行详细解析。在准备这部分内容的期间,会穿插几篇弹性伸缩组件的最佳实践。今天我们要讲解的是

cluster-proportional-autoscalercluster-proportional-autoscaler是根据集群中节点的数目进行Pod副本数水平伸缩的组件,这个组件的产生主要是为了解决集群的核心组件负载弹性的问题。在一个Kubernetes集群中,除了APIServer等耳熟能详的Control Pannel组件,还有很多系统组件是部署在worker上的,例如CoreDNSIngress ControllerIstio等等。这些核心组件大部分和我们的应用接入层息息相关,也就是说每当我们的系统处理了一条外部的请求,可能都会调用这些组件。那么这就有可能由于这些组件的负载过大,造成应用的QPS达到瓶颈。那么一个集群该运行多少个核心组件副本呢?

很遗憾,这个问题是没有统一答案的,因为不同的类型的应用、不同的网络模型、不同的调度分布,都有可能会带来不同的挑战。在本篇文章中,我们不谈具体的指标和数据,只探讨解法。在本系列后面的文章中,会为大家深入解析。

大部分的情况下,核心组件的副本数目和集群的节点数目是成正比的,一个集群的节点数目越多,核心组件所需要的副本数就越多。今天我们以CoreDNS为例,通过cluster-proportional-autoscaler,来实现一个动态的、基于节点数目的核心组件动态伸缩。

cluster-proportional-autoscaler的使用

cluster-proportional-autoscaler和传统的Kubernetes组件设计有所不同,我们已经见惯了各种ControllerCRD或者Operator,而cluster-proportional-autoscaler走了另外一条非常简单的路。使用cluster-proportional-autoscaler只需要部署一个Yaml并选择一个伸缩的监听对象以及伸缩策略即可。如果需要有多个组件进行伸缩,那就部署多个Yaml,每个Yaml包含一个cluster-proportional-autoscaler。一个使用cluster-proportional-autoscaler弹性伸缩coredns的模板如下。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: dns-autoscaler
  namespace: kube-system
  labels:
    k8s-app: dns-autoscaler
spec:
  selector:
    matchLabels:
       k8s-app: dns-autoscaler
  template:
    metadata:
      labels:
        k8s-app: dns-autoscaler
    
    spec:
      serviceAccountName: admin
      containers:
      - name: autoscaler
        image: registry.cn-hangzhou.aliyuncs.com/ringtail/cluster-proportional-autoscaler-amd64:v1.3.0
        resources:
            requests:
                cpu: "200m"
                memory: "150Mi"
        command:
          - /cluster-proportional-autoscaler
          - --namespace=kube-system
          - --configmap=dns-autoscaler
          - --target=Deployment/coredns
          - --default-params={"linear":{"coresPerReplica":16,"nodesPerReplica":2,"min":1,"max":100,"preventSinglePointFailure":true}}
          - --logtostderr=true
          - --v=2
         
        

cluster-proportional-autoscaler的伸缩策略主要有两种,一种是线性模型,一种是梯度模型。

简单的理解,线性模型就是 y = rate * x + min,设置最小值,以及伸缩的区间,并根据当前节点的数目,通过线性模型计算所需的核心组件数目。在上面的例子中,我们用的就是线性模型,线性模型支持的配置参数如下:

{
      "coresPerReplica": 2,
      "nodesPerReplica": 1,
      "min": 1,
      "max": 100,
      "preventSinglePointFailure": true
}

minmax、以及preventSinglePointFailure都比较好理解,coresPerReplica的意思是按照核心数目来计算副本集,nodesPerReplica是按照节点数目来计算副本集。用一个实际的例子进行举例,例如当前集群有两个节点,每个节点的配置是4C8G,那么如果按照coresPerReplica这个指标计算,则需要弹出4*2/2=4个副本。如果按照nodesPerReplica来计算,则需要弹出2*1 = 2个副本。此时cluster-proportional-autoscaler会取两者之间的大的数值,也就是4作为最后的伸缩数目进行扩容。

梯度模型就是分级的机制,每个梯度对应了一个副本,例如:

{
      "coresToReplicas":
      [
        [ 1, 1 ],
        [ 64, 3 ],
        [ 512, 5 ],
        [ 1024, 7 ],
        [ 2048, 10 ],
        [ 4096, 15 ]
      ],
      "nodesToReplicas":
      [
        [ 1, 1 ],
        [ 2, 2 ]
      ]
    }

这个配置表示存在coresToReplicasnodesToReplicas两个梯度,其中coresToReplicas的梯度表示,最小为1个副本;CPU核心数目大于3小于64的时候,为2个副本;依次类推。同样nodesToReplicas表示1个节点的时候为1个副本,2个节点的时候为2个副本。

最后

至此,cluster-proportional-autoscaler的使用就给大家讲解完了,建议优先配置CoreDNS的autoscaler,对于负载不高的场景可以考虑节点副本1:2的比例,如果负载比较高,可以1:1的配置进行配置。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
阿里云容器服务 ACK
使用钉钉扫一扫加入圈子
+ 订阅

云端最佳容器应用运行环境,安全、稳定、极致弹性

官方博客
官网链接