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:
      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
        serviceAccountName: admin

cluster-proportional-autoscaler的伸縮策略主要有兩種，一種是線性模型，一種是梯度模型。

簡單的理解，線性模型就是 y = rate * x + min，設置最小值，以及伸縮的區間，並根據當前節點的數目，經過線性模型計算所需的核心組件數目。在上面的例子中，咱們用的就是線性模型，線性模型支持的配置參數以下：

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

min、max、以及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 ]
      ]
    }

這個配置表示存在coresToReplicas和nodesToReplicas兩個梯度，其中coresToReplicas的梯度表示，最小爲1個副本；CPU核心數目大於3小於64的時候，爲2個副本；依次類推。一樣nodesToReplicas表示1個節點的時候爲1個副本，2個節點的時候爲2個副本。

最後

至此，cluster-proportional-autoscaler的使用就給你們講解完了，建議優先配置CoreDNS的autoscaler，對於負載不高的場景能夠考慮節點副本1:2的比例，若是負載比較高，能夠1:1的配置進行配置。