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和傳統的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的配置進行配置。
原文鏈接
本文為雲棲社區原創內容,未經允許不得轉載。
Kubernetes 彈性伸縮全場景解析 (四)- 讓核心組件充滿彈性