天天看點

Kubernetes 彈性伸縮全場景解析 (四)- 讓核心元件充滿彈性前言cluster-proportional-autoscaler 的使用最後

前言

在本系列的前三篇文章中,我們介紹了彈性伸縮的整體布局以及 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 的配置進行配置。

繼續閱讀