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

前言

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

cluster-proportional-autoscaler 是根据集群中节点的数目进行 Pod 副本数水平伸缩的组件。这个组件的产生主要是为了解决集群的核心组件负载弹性的问题。在一个 Kubernetes 集群中，除了 APIServer 等耳熟能详的 Control Pannel 组件，还有不少系统组件是部署在 worker 上的，例如 CoreDNS、Ingress Controller、Istio 等等。

这些核心组件大部分和咱们的应用接入层息息相关，也就是说每当咱们的系统处理了一条外部的请求，可能都会调用这些组件。因为这些组件的负载过大，颇有可能形成应用的QPS达到瓶颈。那么一个集群该运行多少个核心组件副本呢？

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

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

cluster-proportional-autoscaler 的使用

cluster-proportional-autoscaler 和传统的 Kubernetes 组件设计有所不一样，咱们已经见惯了各类 Controller、CRD 或者 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
}

min、max、以及 preventSinglePointFailure 都比较好理解，coresPerReplica 的意思是按照核心数目来计算副本集，nodesPerReplica 是按照节点数目来计算副本集。

用一个实际的例子进行举例，例如当前集群有两个节点，每一个节点的配置是 4C8G，那么若是按照 coresPerReplica 这个指标计算，则须要弹出 42/2=4 个副本。若是按照 nodesPerReplica 来计算，则须要弹出 21 = 2 个副本。此时 cluster-proportional-autoscaler 会取二者之间的大的数值，也就是 4 做为最后的伸缩数目进行扩容。

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

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

这个配置表示存在 coresToReplicas 和 nodesToReplicas 两个梯度，其中 coresToReplicas 的梯度表示：最小为 1 个副本；CPU 核心数目大于 3 小于 64 的时候，为 2 个副本；依次类推。

一样 nodesToReplicas 表示 1 个节点的时候为 1 个副本，2 个节点的时候为 2 个副本。

最后

至此，cluster-proportional-autoscaler 的使用就给你们讲解完了，建议优先配置 CoreDNS 的 autoscaler，对于负载不高的场景能够考虑节点副本 1:2 的比例，若是负载比较高，能够 1:1 的配置进行配置。

 

本文做者：一绿舟

原文连接

本文为云栖社区原创内容，未经容许不得转载。