當(dāng)集群資源不足時(shí)，Cluster Autoscaler會(huì)提供新節(jié)點(diǎn)并將其加入集群。使用Kubernetes時(shí)你可能會(huì)注意到，創(chuàng)建節(jié)點(diǎn)并將其加入集群的過程可能需要花費(fèi)數(shù)分鐘。在這段時(shí)間里，應(yīng)用程序很容易被連接淹沒，因?yàn)橐呀?jīng)無(wú)法進(jìn)一步擴(kuò)展了。

虛擬機(jī)的配置可能需要花費(fèi)數(shù)分鐘，在這期間可能無(wú)法擴(kuò)展應(yīng)用

如何消除如此長(zhǎng)的等待時(shí)間？

主動(dòng)擴(kuò)展（Proactive scaling），或者：

1. 理解集群Autoscaler的工作原理并最大限度提升其效用；
2. 使用Kubernetes scheduler為節(jié)點(diǎn)分配另一個(gè)Pod；以及
3. 主動(dòng)配置工作節(jié)點(diǎn)，以改善擴(kuò)展效果。

注意：本文涉及的所有代碼都已發(fā)布至LearnK8s GitHub。

Linode可以支持這些解決方案。近期Lincode加入了 Akamai解決方案大家庭，現(xiàn)在注冊(cè)Linode，就可免費(fèi)獲得價(jià)值100美元的使用額度，可以隨意使用Linode云平臺(tái)提供的各種服務(wù)。立即點(diǎn)擊這里了解詳情并注冊(cè)吧↓↓↓

進(jìn)一步了解Akamai Linode云計(jì)算服務(wù)與能力！

Cluster Autoscaler如何在Kubernetes中生效

Cluster Autoscaler在觸發(fā)自動(dòng)擴(kuò)展時(shí)并不檢查內(nèi)存或CPU的可用數(shù)，而是會(huì)對(duì)事件作出反應(yīng)，檢查所有不可調(diào)度的Pod。當(dāng)調(diào)度器找不到能容納某個(gè)Pod的節(jié)點(diǎn)時(shí)，我們就說(shuō)這個(gè)Pod是不可調(diào)度的。

我們可以這樣創(chuàng)建一個(gè)集群來(lái)測(cè)試看看。

bash
$ linode-cli lke cluster-create \
 --label learnk8s \
 --region eu-west \
 --k8s_version 1.23 \
 --node_pools.count 1 \
 --node_pools.type g6-standard-2 \
 --node_pools.autoscaler.enabled enabled \
 --node_pools.autoscaler.max 10 \
 --node_pools.autoscaler.min 1 \
$ linode-cli lke kubeconfig-view "insert cluster id here" --text | tail +2 | base64 -d > kubeconfig

請(qǐng)留意下列細(xì)節(jié)：

1. 每個(gè)節(jié)點(diǎn)有4GB內(nèi)存和2個(gè)vCPU（例如“g6-standard-2”實(shí)例）
2. 集群中只有一個(gè)節(jié)點(diǎn)，并且
3. Cluster autoscaler被配置為從1個(gè)節(jié)點(diǎn)擴(kuò)展至10個(gè)節(jié)點(diǎn)

我們可以用下列命令驗(yàn)證安裝已成功完成：

bash
$ kubectl get pods -A --kubecnotallow=kubeconfig

用環(huán)境變量導(dǎo)出kubeconfig文件通常是一種很方便的做法，為此我們可以運(yùn)行：

bash
$ export KUBECONFIG=${PWD}/kubeconfig
$ kubectl get pods

部署應(yīng)用程序

讓我們部署一個(gè)需要1GB內(nèi)存和250m* CPU的應(yīng)用程序。

注意：m = 內(nèi)核的千分之一容量，因此250m = CPU的25%容量。

yaml
apiVersion: apps/v1
kind: Deployment
metadata:
 name: podinfo
spec:
 replicas: 1
 selector:
 matchLabels:
 app: podinfo
 template:
 metadata:
 labels:
 app: podinfo
 spec:
 containers:
 - name: podinfo
 image: stefanprodan/podinfo
 ports:
 - containerPort: 9898
 resources:
 requests:
 memory: 1G
 cpu: 250m

用下列命令將資源提交至集群：

bash
$ kubectl apply -f podinfo.yaml

隨后很快會(huì)發(fā)現(xiàn)一些情況。首先，三個(gè)Pod幾乎會(huì)立即開始運(yùn)行，另有一個(gè)Pod處于“未決”狀態(tài)。

隨后很快：

1. 幾分鐘后，Autoscaler創(chuàng)建了一個(gè)額外的Pod，并且
2. 第四個(gè)Pod會(huì)被部署到一個(gè)新節(jié)點(diǎn)中。

最終，第四個(gè)Pod被部署到一個(gè)新節(jié)點(diǎn)中

第四個(gè)Pod為何沒有部署到第一個(gè)節(jié)點(diǎn)中？讓我們一起看看已分配的資源。

Kubernetes節(jié)點(diǎn)中資源的分配

Kubernetes集群中部署的Pod會(huì)消耗內(nèi)存、CPU以及存儲(chǔ)資源。而且在同一個(gè)節(jié)點(diǎn)上，操作系統(tǒng)和Kubelet也需要消耗內(nèi)存和CPU。

在Kubernetes工作節(jié)點(diǎn)上，內(nèi)存和CPU會(huì)被拆分為：

1. 運(yùn)行操作系統(tǒng)和系統(tǒng)守護(hù)進(jìn)程（如SSH、Systemd等）所需的資源。
2. 運(yùn)行Kubernetes代理程序（如Kubelet、容器運(yùn)行時(shí)以及節(jié)點(diǎn)故障檢測(cè)程序等）所需的資源。
3. 可用于Pod的資源。
4. 為排空閾值（Eviction threshold）保留的資源。

Kubernetes節(jié)點(diǎn)中分配和保留的資源

如果集群運(yùn)行了DaemonSet（如kube-proxy），那么可用內(nèi)存和CPU數(shù)量還將進(jìn)一步減少。

那么我們不妨降低需求，以確保能將所有Pod都放入同一個(gè)節(jié)點(diǎn)中：

yaml
apiVersion: apps/v1
kind: Deployment
metadata:
 name: podinfo
spec:
 replicas: 4
 selector:
 matchLabels:
 app: podinfo
 template:
 metadata:
 labels:
 app: podinfo
 spec:
 containers:
 - name: podinfo
 image: stefanprodan/podinfo
 ports:
 - containerPort: 9898
 resources:
 requests:
 memory: 0.8G # <- lower memory
 cpu: 200m # <- lower CPU
我們可以使用下列命令修改這個(gè)部署：
bash
$ kubectl apply -f podinfo.yaml

選擇恰當(dāng)數(shù)量的CPU和內(nèi)存以優(yōu)化實(shí)例的運(yùn)行，這是個(gè)充滿挑戰(zhàn)的工作。Learnk8s計(jì)算器工具可以幫助我們更快速地完成這項(xiàng)工作。

一個(gè)問題解決了，但是創(chuàng)建新節(jié)點(diǎn)花費(fèi)的時(shí)間呢？

遲早我們會(huì)需要四個(gè)以上的副本，我們是否真的需要等待好幾分鐘，隨后才能創(chuàng)建新的Pod？

簡(jiǎn)單來(lái)說(shuō)：是的！Linode必須從頭開始創(chuàng)建和配置新虛擬機(jī)，隨后將其連接到集群。這個(gè)過程經(jīng)常會(huì)超過兩分鐘。

但其實(shí)還有替代方案：我們可以在需要時(shí)主動(dòng)創(chuàng)建已經(jīng)配置好的節(jié)點(diǎn)。

例如：我們可以配置讓Autoscaler始終準(zhǔn)備好一個(gè)備用節(jié)點(diǎn)。當(dāng)Pod被部署到備用節(jié)點(diǎn)后，Autoscaler可以主動(dòng)創(chuàng)建另一個(gè)備用節(jié)點(diǎn)。然而Autoscaler并沒有內(nèi)置這樣的功能，但我們可以很容易地重新創(chuàng)建。

我們可以創(chuàng)建一個(gè)請(qǐng)求數(shù)與節(jié)點(diǎn)資源相等的Pod：

yaml
apiVersion: apps/v1
kind: Deployment
metadata:
 name: overprovisioning
spec:
 replicas: 1
 selector:
 matchLabels:
 run: overprovisioning
 template:
 metadata:
 labels:
 run: overprovisioning
 spec:
 containers:
 - name: pause
 image: k8s.gcr.io/pause
 resources:
 requests:
 cpu: 900m
 memory: 3.8G

用下列命令將資源提交至集群：

bash
kubectl apply -f placeholder.yaml

這個(gè)Pod完全不執(zhí)行任何操作。

用占位Pod保護(hù)節(jié)點(diǎn)上的所有資源

該節(jié)點(diǎn)的作用只是確保節(jié)點(diǎn)能夠被充分使用起來(lái)。

隨后還需要確保當(dāng)工作負(fù)載需要擴(kuò)展時(shí)，這個(gè)占位Pod能夠被快速清除。為此我們可以使用Priority Class。

yaml
apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
 name: overprovisioning
value: -1
globalDefault: false
description: "Priority class used by overprovisioning."
---
apiVersion: apps/v1
kind: Deployment
metadata:
 name: overprovisioning
spec:
 replicas: 1
 selector:
 matchLabels:
 run: overprovisioning
 template:
 metadata:
 labels:
 run: overprovisioning
 spec:
 priorityClassName: overprovisioning # <--
 containers:
 - name: pause
 image: k8s.gcr.io/pause
 resources:
 requests:
 cpu: 900m
 memory: 3.8G
用下列命令將其提交至集群：
bash
kubectl apply -f placeholder.yaml

至此，配置工作已全部完成。

我們可能需要等待一會(huì)讓Autoscaler創(chuàng)建節(jié)點(diǎn)，隨后我們將有兩個(gè)節(jié)點(diǎn)：

1. 一個(gè)包含四個(gè)Pod的節(jié)點(diǎn)
2. 一個(gè)包含一個(gè)占位Pod的節(jié)點(diǎn)

如果將部署擴(kuò)展為5個(gè)副本會(huì)怎樣？是否要等待Autoscaler創(chuàng)建另一個(gè)新節(jié)點(diǎn)？

用下列命令測(cè)試看看吧：

bash
kubectl scale deployment/podinfo --replicas=5

我們將會(huì)看到：

1. 第五個(gè)Pod會(huì)立即創(chuàng)建出來(lái)，并在10秒內(nèi)變?yōu)椤罢谶\(yùn)行”的狀態(tài)。
2. 占位Pod會(huì)被清除，以便為第五個(gè)Pod騰出空間。

占位Pod會(huì)被清除，以便為常規(guī)Pod騰出空間

隨后：

1. Cluster autoscaler會(huì)注意到未決的占位Pod并配置一個(gè)新的節(jié)點(diǎn)。
2. 占位Pod會(huì)被部署到新創(chuàng)建的節(jié)點(diǎn)中。

未決的Pod觸發(fā)了Cluster autoscaler新建節(jié)點(diǎn)

在可以有更多節(jié)點(diǎn)時(shí)，為何又要主動(dòng)創(chuàng)建出一個(gè)節(jié)點(diǎn)？

我們可以將占位Pod擴(kuò)展到多個(gè)副本，每個(gè)副本都會(huì)預(yù)配置一個(gè)Kubernetes節(jié)點(diǎn)，準(zhǔn)備接受標(biāo)準(zhǔn)工作負(fù)載。然而這些節(jié)點(diǎn)雖然是閑置的，但它們產(chǎn)生的費(fèi)用依然會(huì)計(jì)入云服務(wù)賬單。因此一定要慎重，不要?jiǎng)?chuàng)建太多節(jié)點(diǎn)。

將Cluster Autoscaler與Horizontal Pod Autoscaler配合使用

為理解這項(xiàng)技術(shù)的含義，我們可以將Cluster autoscaler和Horizontal Pod Autoscaler（HPA）結(jié)合在一起來(lái)看。HPA可用于提高部署中的副本數(shù)量。

隨著應(yīng)用程序收到越來(lái)越多流量，我們可以讓Autoscaler調(diào)整處理請(qǐng)求的副本數(shù)量。當(dāng)Pod耗盡所有可用資源后，會(huì)觸發(fā)Cluster autoscaler新建一個(gè)節(jié)點(diǎn)，這樣HPA就可以繼續(xù)創(chuàng)建更多副本。

可以這樣新建一個(gè)集群來(lái)測(cè)試上述效果：

bash
$ linode-cli lke cluster-create \
 --label learnk8s-hpa \
 --region eu-west \
 --k8s_version 1.23 \
 --node_pools.count 1 \
 --node_pools.type g6-standard-2 \
 --node_pools.autoscaler.enabled enabled \
 --node_pools.autoscaler.max 10 \
 --node_pools.autoscaler.min 3 \
$ linode-cli lke kubeconfig-view "insert cluster id here" --text | tail +2 | base64 -d > kubeconfig-hpa

用下列命令驗(yàn)證安裝過程已成功完成：

bash
$ kubectl get pods -A --kubecnotallow=kubeconfig-hpa

使用環(huán)境變量導(dǎo)出kubeconfig文件是一種方便的做法，為此我們可以運(yùn)行：

bash
$ export KUBECONFIG=${PWD}/kubeconfig-hpa
$ kubectl get pods

接下來(lái)使用Helm安裝Prometheus并查看該部署的相關(guān)指標(biāo)。我們可以在官網(wǎng)上了解安裝Helm的詳細(xì)方法。

bash
$ helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
$ helm install prometheus prometheus-community/prometheus
Kubernetes為HPA提供了一個(gè)控制器，借此可以動(dòng)態(tài)增減副本數(shù)量。然

而HPA也有一些局限性：

1. 無(wú)法拆箱即用。需要安裝Metrics Server來(lái)匯總并暴露出指標(biāo)。
2. PromQL查詢無(wú)法做到拆箱即用。

好在我們可以使用KEDA，它通過一些實(shí)用功能（包括從Prometheus讀取指標(biāo)）擴(kuò)展了HPA控制器的用法。KEDA是一種Autoscaler，可適用于下列三個(gè)組件：

1. Scaler
2. Metrics Adapter
3. Controller

KEDA架構(gòu)

我們可以通過Helm安裝KEDA：

bash
$ helm repo add kedacore https://kedacore.github.io/charts
$ helm install keda kedacore/keda

安裝好Prometheus和KEDA之后，來(lái)創(chuàng)建一個(gè)部署吧。

在這個(gè)實(shí)驗(yàn)中，我們將使用一個(gè)每秒可以處理固定數(shù)量請(qǐng)求的應(yīng)用。每個(gè)Pod每秒最多可以處理十個(gè)請(qǐng)求，如果Pod收到第11個(gè)請(qǐng)求，會(huì)將請(qǐng)求掛起，稍后再處理。

yaml
apiVersion: apps/v1
kind: Deployment
metadata:
 name: podinfo
spec:
 replicas: 4
 selector:
 matchLabels:
 app: podinfo
 template:
 metadata:
 labels:
 app: podinfo
 annotations:
 prometheus.io/scrape: "true"
 spec:
 containers:
 - name: podinfo
 image: learnk8s/rate-limiter:1.0.0
 imagePullPolicy: Always
 args: ["/app/index.js", "10"]
 ports:
 - containerPort: 8080
 resources:
 requests:
 memory: 0.9G
---
apiVersion: v1
kind: Service
metadata:
 name: podinfo
spec:
 ports:
 - port: 80
 targetPort: 8080
 selector:
 app: podinfo

使用下列命令將資源提交至集群：

bash
$ kubectl apply -f rate-limiter.yaml

為了生成一些流量，我們可以使用Locust。下列YAML定義將創(chuàng)建一個(gè)分布式負(fù)載測(cè)試集群：

yaml
apiVersion: v1
kind: ConfigMap
metadata:
 name: locust-script
data:
 locustfile.py: |-
 from locust import HttpUser, task, between
 class QuickstartUser(HttpUser):
 @task
 def hello_world(self):
 self.client.get("/", headers={"Host": "example.com"})
---
apiVersion: apps/v1
kind: Deployment
metadata:
 name: locust
spec:
 selector:
 matchLabels:
 app: locust-primary
 template:
 metadata:
 labels:
 app: locust-primary
 spec:
 containers:
 - name: locust
 image: locustio/locust
 args: ["--master"]
 ports:
 - containerPort: 5557
 name: comm
 - containerPort: 5558
 name: comm-plus-1
 - containerPort: 8089
 name: web-ui
 volumeMounts:
 - mountPath: /home/locust
 name: locust-script
 volumes:
 - name: locust-script
 configMap:
 name: locust-script
---
apiVersion: v1
kind: Service
metadata:
 name: locust
spec:
 ports:
 - port: 5557
 name: communication
 - port: 5558
 name: communication-plus-1
 - port: 80
 targetPort: 8089
 name: web-ui
 selector:
 app: locust-primary
 type: LoadBalancer
---
apiVersion: apps/v1
kind: DaemonSet
metadata:
 name: locust
spec:
 selector:
 matchLabels:
 app: locust-worker
 template:
 metadata:
 labels:
 app: locust-worker
 spec:
 containers:
 - name: locust
 image: locustio/locust
 args: ["--worker", "--master-host=locust"]
 volumeMounts:
 - mountPath: /home/locust
 name: locust-script
 volumes:
 - name: locust-script
 configMap:
 name: locust-script

運(yùn)行下列命令將其提交至集群：

bash
$ kubectl locust.yaml
Locust會(huì)讀取下列l(wèi)ocustfile.py文件，該文件存儲(chǔ)在一個(gè)ConfigMap中：
py
from locust import HttpUser, task, between
class QuickstartUser(HttpUser):
 @task
 def hello_world(self):
 self.client.get("/")

該文件并沒有什么特別的作用，只是向一個(gè)URL發(fā)出請(qǐng)求。若要連接至Locust儀表板，我們需要提供其負(fù)載均衡器的IP地址。為此可使用下列命令獲取地址：

bash
$ kubectl get service locust -o jsnotallow='{.status.loadBalancer.ingress[0].ip}'

隨后打開瀏覽器并訪問該IP地址即可。

此外還需要注意一個(gè)問題：Horizontal Pod Autoscaler。KEDA autoscaler會(huì)用一個(gè)名為ScaledObject的特殊對(duì)象來(lái)封裝Horizontal Autoscaler。

yaml
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
name: podinfo
spec:
scaleTargetRef:
 kind: Deployment
 name: podinfo
minReplicaCount: 1
maxReplicaCount: 30
cooldownPeriod: 30
pollingInterval: 1
triggers:
- type: prometheus
 metadata:
 serverAddress: http://prometheus-server
 metricName: connections_active_keda
 query: |
 sum(increase(http_requests_total{app="podinfo"}[60s]))
 threshold: "480" # 8rps * 60s

KEDA可以連接由Prometheus收集的指標(biāo)，并將其發(fā)送給Kubernetes。最后，它還將使用這些指標(biāo)創(chuàng)建一個(gè)Horizontal Pod Autoscaler (HPA)。

我們可以用下列命令手工檢查HPA：

bash
$ kubectl get hpa
$ kubectl describe hpa keda-hpa-podinfo

并使用下列命令提交該對(duì)象：

bash
$ kubectl apply -f scaled-object.yaml

接下來(lái)可以測(cè)試擴(kuò)展效果了。請(qǐng)?jiān)?/span>Locust儀表板中用下列設(shè)置啟動(dòng)一項(xiàng)實(shí)驗(yàn)：

1. Number of users：300
2. Spawn rate：0.4
3. Host：http://podinfo

集群和Horizontal pod autoscaler的結(jié)合

可以看到，副本的數(shù)量增加了！

效果不錯(cuò)，但有個(gè)問題不知道你是否注意到。

當(dāng)該部署擴(kuò)展到8個(gè)Pod后，需要等待幾分鐘，隨后才能在新節(jié)點(diǎn)中創(chuàng)建新的Pod。在這段時(shí)間里，每秒處理的請(qǐng)求數(shù)量也不再增加了，因?yàn)楫?dāng)前的8個(gè)副本每個(gè)都只能處理10個(gè)請(qǐng)求。

讓我們?cè)囋嚳词湛s容量并重復(fù)該實(shí)驗(yàn)：

bash
kubectl scale deployment/podinfo --replicas=4 # or wait for the autoscaler to remove pods

這次，我們將用一個(gè)占位Pod實(shí)現(xiàn)超量配置（Overprovision）：

yaml
apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
 name: overprovisioning
value: -1
globalDefault: false
description: "Priority class used by overprovisioning."
---
apiVersion: apps/v1
kind: Deployment
metadata:
 name: overprovisioning
spec:
 replicas: 1
 selector:
 matchLabels:
 run: overprovisioning
 template:
 metadata:
 labels:
 run: overprovisioning
 spec:
 priorityClassName: overprovisioning
 containers:
 - name: pause
 image: k8s.gcr.io/pause
 resources:
 requests:
 cpu: 900m
 memory: 3.9G

運(yùn)行下列命令將其提交至集群：

bash
kubectl apply -f placeholder.yaml

打開Locust儀表板并用下列設(shè)置重復(fù)實(shí)驗(yàn)：

1. Number of users：300
2. Spawn rate：0.4
3. Host：http://podinfo

在超量配置的情況下進(jìn)行集群和Horizontal pod autoscaler的結(jié)合

這一次，新節(jié)點(diǎn)將在后臺(tái)創(chuàng)建，每秒請(qǐng)求數(shù)量將持續(xù)增減，不會(huì)原地踏步。很棒！

總結(jié)

本文介紹了下列內(nèi)容：

1. Cluster autoscaler并不追蹤C(jī)PU或內(nèi)存用量，而是會(huì)監(jiān)控未決的Pod。
2. 我們可以用可用內(nèi)存和CPU的總量來(lái)創(chuàng)建一個(gè)Pod，從而主動(dòng)配置Kubernetes節(jié)點(diǎn)。
3. Kubernetes節(jié)點(diǎn)會(huì)為Kubelet、操作系統(tǒng)以及排空閾值保留一定的資源。
4. 我們可以結(jié)合使用Prometheus和KEDA，從而通過PromQL查詢擴(kuò)展自己的Pod。

這篇文章的內(nèi)容感覺還行吧？有沒有想要立即在Linode平臺(tái)上親自嘗試一下？別忘了，現(xiàn)在注冊(cè)可以免費(fèi)獲得價(jià)值100美元的使用額度，快點(diǎn)自己動(dòng)手體驗(yàn)本文介紹的功能和服務(wù)吧↓↓↓

進(jìn)一步了解Akamai Linode云計(jì)算服務(wù)與能力！

歡迎關(guān)注Akamai知乎機(jī)構(gòu)號(hào) ，第一時(shí)間了解高可用的MySQL/MariaDB參考架構(gòu)，以及豐富的應(yīng)用程序示例。