自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

先發(fā)制人遇事不慌:Kubernetes集群主動(dòng)擴(kuò)展?

云計(jì)算
本文介紹了Cluster autoscaler并不追蹤C(jī)PU或內(nèi)存用量,而是會(huì)監(jiān)控未決的Pod,?我們可以用可用內(nèi)存和CPU的總量來創(chuàng)建一個(gè)Pod,從而主動(dòng)配置Kubernetes節(jié)點(diǎn)等內(nèi)容。

當(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)無法進(jìn)一步擴(kuò)展了。

延伸閱讀,了解Akamai cloud-computing

出海云服務(wù),選擇Akamai Linode!

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

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

主動(dòng)擴(kuò)展(Proactive scaling),或者:

  • 理解集群Autoscaler的工作原理并最大限度提升其效用;
  • 使用Kubernetes scheduler為節(jié)點(diǎn)分配另一個(gè)Pod;以及

主動(dòng)配置工作節(jié)點(diǎn),以改善擴(kuò)展效果。注意:本文涉及的所有代碼都已發(fā)布至LearnK8s GitHub。

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í),我們就說這個(gè)Pod是不可調(diào)度的。
我們可以這樣創(chuàng)建一個(gè)集群來測(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é):

  • 每個(gè)節(jié)點(diǎn)有4GB內(nèi)存和2個(gè)vCPU(例如“g6-standard-2”實(shí)例)
  • 集群中只有一個(gè)節(jié)點(diǎn),并且
  • 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)。

隨后很快:

  • 幾分鐘后,Autoscaler創(chuàng)建了一個(gè)額外的Pod,并且
  • 第四個(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)單來說:是的!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)能夠被充分使用起來。

隨后還需要確保當(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)建出來,并在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é)合在一起來看。HPA可用于提高部署中的副本數(shù)量。

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

這樣HPA就可以繼續(xù)創(chuàng)建更多副本。

可以這樣新建一個(gè)集群來測(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

接下來使用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. 無法拆箱即用。需要安裝Metrics Server來匯總并暴露出指標(biāo)。
  2. PromQL查詢無法做到拆箱即用。

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

  • Scaler
  • Metrics Adapter
  • Controller

KEDA架構(gòu)

我們可以通過Helm安裝KEDA:

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

安裝好Prometheus和KEDA之后,來創(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ì)象來封裝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

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

集群和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):

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

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

總結(jié)

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

  • Cluster autoscaler并不追蹤C(jī)PU或內(nèi)存用量,而是會(huì)監(jiān)控未決的Pod。
  • 我們可以用可用內(nèi)存和CPU的總量來創(chuàng)建一個(gè)Pod,從而主動(dòng)配置Kubernetes節(jié)點(diǎn)。
  • Kubernetes節(jié)點(diǎn)會(huì)為Kubelet、操作系統(tǒng)以及排空閾值保留一定的資源。
  • 我們可以結(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ù)吧↓↓↓

出海云服務(wù),選擇Akamai Linode!

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

責(zé)任編輯:張燕妮
相關(guān)推薦

2023-11-08 11:32:49

2021-01-26 11:37:40

FedoraChrome谷歌

2010-02-05 15:54:22

2024-03-13 10:50:55

2017-06-28 14:52:38

安全

2017-02-22 21:51:24

2022-01-22 00:17:07

物聯(lián)網(wǎng)網(wǎng)絡(luò)安全漏洞

2021-06-22 10:20:30

5G物聯(lián)網(wǎng)生態(tài)系統(tǒng)

2023-07-24 15:24:31

2017-04-13 10:15:18

機(jī)器人工作

2021-08-05 10:56:54

谷歌開發(fā)人員Linux

2018-01-07 01:32:31

2023-09-07 10:31:50

AIGCChatGPT

2023-07-10 13:32:00

2024-02-22 15:45:56

2022-07-01 17:57:45

KubernetesAPI

2011-02-15 09:35:25

2020-07-17 13:28:49

系統(tǒng)程序員開發(fā)

2011-06-17 10:10:02

點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號(hào)