前言

在本系列的前三篇文章中，我們介紹了彈性伸縮的整體布局以及 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-autoscalernamespace: kube-systemlabels:k8s-app: dns-autoscaler spec:selector:matchLabels:k8s-app: dns-autoscalertemplate:metadata:labels:k8s-app: dns-autoscalerspec:serviceAccountName: admincontainers:- name: autoscalerimage: registry.cn-hangzhou.aliyuncs.com/ringtail/cluster-proportional-autoscaler-amd64:v1.3.0resources: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 的配置進行配置。

《新程序員》：云原生和全面數字化實踐50位技術專家共同創作，文字、視頻、音頻交互閱讀

總結

以上是生活随笔為你收集整理的Kubernetes 弹性伸缩全场景解析 （四）- 让核心组件充满弹性的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。