降本提效是創(chuàng)新開發(fā)的永恒話題。過去多年來，開發(fā)者紛紛擁抱容器技術以提高部署效率，降低運維負擔。隨著像Docker這類容器引擎使用量不斷增長，作為Docker管理系統(tǒng)的Kubernetes（簡稱K8s）順勢而出，幫助開發(fā)者構建并簡化復雜的容器編排工作。

延伸閱讀，點擊鏈接了解 Akamai Cloud Computing

本文Akamai將帶大家一起看看，如何準確確定Kubernetes集群的規(guī)模，并根據(jù)需求更靈活、動態(tài)地對集群規(guī)模進行縮放，從而在滿足負載需求的同時最大限度降低成本。

一、高效確定Kubernetes集群的最優(yōu)規(guī)模

每當我們需要創(chuàng)建Kubernetes集群時，肯定首先都會問自己：該用什么類型的工作節(jié)點？具體需要多少個？

例如，當我們正在使用Linode Kubernetes引擎（LKE）等托管式Kubernetes服務，到底該使用8個2GB的Linode實例，還是2個8GB的Linode實例來實現(xiàn)所需計算能力？

在回答這個問題之前需要注意：無論自建K8s集群或任何云平臺上托管的K8s，并非所有工作節(jié)點中的資源都可以用于運行工作負載。

1.Kubernetes節(jié)點預留

在Kubernetes節(jié)點中，CPU和內存會被劃分給：

• 操作系統(tǒng)
• Kubelet、CNI、CRI、CSI（和系統(tǒng)守護程序）
• Pod
• 驅逐閾值

假設有個只有一個Linode 2GB計算實例的集群（包含1個vCPU和2GB內存），以下資源會被保留給kubelet和操作系統(tǒng)：

• 500MB內存。
• 60m的CPU。

此外，還有100MB內存為驅逐閾值保留。

總的來說，此時我們有30%的內存和6%的CPU是不能被工作負載使用的。

每個云提供商都有各自定義限制的方式，但在CPU方面他們似乎不約而同進行了以下限制：

• 第一個核心的6％；
• 下一個核心的1％（最多2個核心）；
• 接下來的2個核心的0.5％（最多4個）；以及
• 四個以上核心的0.25％。

至于內存方面的限制，不同提供商之間有很大差異。但一般來說，內存的預留往往遵循以下限制：

• 前4GB內存的25％；
• 接下來4GB內存的20％（最多8GB）；
• 接下來8GB內存的10％（最多16GB）；
• 下一個112GB內存的6％（最多128GB）；以及
• 超過128GB的任何內存的2％。

既然知道了工作節(jié)點內資源的分配方式，那么我們該選擇哪種實例？答案因具體情況而異，我們需要根據(jù)工作負載的實際情況來選擇最佳工作節(jié)點。

2.剖析應用程序

Kubernetes中有兩種方法來指定容器可以使用多少內存和CPU：

• 請求：通常與正常操作時的應用程序消耗量相匹配。
• 限制：設置允許的最大資源數(shù)量。

Kubernetes調度程序使用請求來確定在集群中分配Pod的位置。由于調度程序不知道消耗情況（Pod尚未啟動），因此它需要一個提示。這些“提示”就是請求；我們可以為內存和CPU分別設置請求。

kubelet使用限制在內存使用超出允許范圍時停止進程。如果使用的CPU時間超過允許的范圍，kubelet也會限制該進程。但是，該如何選擇適當?shù)恼埱蠛拖拗浦的兀?/p>

我們可以測量工作負載性能（例如平均值、95和99百分位數(shù)等）并將其用作請求和限制。為了簡化該過程，可以通過兩個便利的工具來加速分析：

• Vertical Pod Autoscaler
• Kubernetes Resource Recommender

VPA會收集內存和CPU利用率數(shù)據(jù)，并運行一個回歸算法，為我們的部署建議請求和限制。這是一個官方的Kubernetes項目，也可以用于自動調整值：我們可以讓控制器直接在YAML中更新請求和限制。

KRR的工作原理類似，但它利用了我們通過Prometheus導出的數(shù)據(jù)。作為第一步，工作負載應該被配置為將度量數(shù)據(jù)導出到Prometheus。一旦存儲了所有度量數(shù)據(jù)，就可以使用KRR來分析數(shù)據(jù)并建議請求和限制。

在具備了（粗略的）資源需求概念后，終于可以繼續(xù)選擇一個實例類型了。

3.選擇實例類型

假設估算自己的工作負載需要2GB的內存請求，并且估計至少需要約10個副本。我們可以排除大多數(shù)小于2GB的小型實例。此時也許可以直接使用某些大型實例，例如Linode 32GB。

接下來，可以將內存和CPU除以可部署在該實例上的最大Pod數(shù)量（例如在LKE中的110個），以獲得內存和CPU的單元數(shù)量。

例如，Linode 32GB的CPU和內存單元為：

• 內存單元為257MB（即（32GB – 3.66GB預留）/ 110）
• CPU單元為71m（即（8000m – 90m預留）/ 110）

在最后一步中，我們可以使用這些單元來估算有多少工作負載可以適應節(jié)點。

假設想要部署一個Spring Boot，請求為6GB和1 vCPU，這相當于：

• 適合6GB的最小單元是24個單元（24 * 257MB = 6.1GB）
• 適合1 vCPU的最小單元是15個單元（15 * 71m = 1065m）

這些數(shù)字表明，內存耗盡之前受限會將CPU耗盡，并且最多可以在集群中部署（110/24）4個應用程序。

當我們在此實例上運行四個工作負載時，將使用：

• 24個內存單元* 4 = 96個單元，有14個未使用（約12％）
• 15個vCPU單元 * 4 = 60個單元，有50個未使用（約45％）

還不錯，但能做得更好嗎？讓我們嘗試使用Linode 64GB實例（64GB / 16 vCPU）。

假設要部署相同的應用程序，數(shù)字會發(fā)生一些變化：

• 內存單元約為527MB（即（64GB – 6.06GB預留）/ 110）。
• CPU單元約為145m（即（16000m – 110m預留）/ 110）。
• 適合6GB的最小單元是12個單元（12 * 527MB = 6.3GB）。
• 適合1 vCPU的最小單元是7個單元（7 * 145m = 1015m）。

可以在這個實例中放多少工作負載？由于將耗盡內存，并且每個工作負載需要12個單元，所以最大應用程序數(shù)是9（即110/12）。

計算效率/浪費比例將會發(fā)現(xiàn)：

• 12個內存單元 * 9 = 108個單元，有2個未使用（約2％）
• 7個vCPU單元 * 9 = 63個單元，有47個未使用（約42％）

雖然浪費的CPU數(shù)量幾乎與前一個實例相同，但內存利用率得到了顯著改善。

最后，我們還可以比較一下成本：

• Linode 32GB實例最多可以容納4個工作負載。在這樣的總容量下，每個Pod的成本為每月48美元（即實例成本192美元除以4個工作負載）。
• Linode 64 GB實例最多可以容納9個工作負載。在這樣的總容量下，每個Pod的成本為每月42.6美元（即實例成本384美元除以9個工作負載）。

換句話說，選擇較大的實例可以為我們每月每個工作負載節(jié)省多達6美元。

4.使用計算器對比不同節(jié)點

如果想測試更多實例該怎么辦？進行這些計算需要很多工作。我們可以使用learnsk8s計算器加快該過程。

使用該計算器的第一步是輸入內存和CPU請求。系統(tǒng)會自動計算保留的資源并提供利用率和成本建議。此外還有一些額外的實用功能：按照應用程序用量分配最接近的CPU和內存請求。如果應用程序偶爾會突發(fā)高CPU或內存使用率，也可以靈活應對。

但是當所有Pod都將所有資源使用到極限會發(fā)生什么？這可能導致超額承諾。我們可以通過門戶中的小組件了解CPU和內存超額承諾的百分比。那么當超額承諾時具體又會發(fā)生什么？

• 如果內存超額承諾，kubelet將驅逐Pod并將其移動到集群中的其他位置。
• 如果CPU超額承諾，工作負載將按比例使用可用的CPU。

最后，我們還可以使用DaemonSets和Agent小組件，這是一個方便的機制，可以模擬在所有節(jié)點上運行的Pod。例如，LKE將Cilium和CSI插件部署為DaemonSets。這些Pod使用的資源對工作負載不可用，應從計算中減去。該小組件可以幫我們做到這一點！

二、按需開關更省錢

為了盡可能降低基礎設施成本，我們可以在不使用某些資源時將其關閉。然而此時的挑戰(zhàn)之處在于，必要時該如何將資源自動打開。接下來我們一起看看如何使用Linode Kubernetes Engine（LKE）部署一個Kubernetes集群，并使用Kubernetes Events-Driven Autoscaler（KEDA）將其收縮到“零”，然后恢復原狀。

1.為何要收縮到零

假設我們在Kubernetes上運行了一個常見的資源密集型應用，但我們只需要在工作時間里運行。此時可能會希望在大家都下班后將其關閉，并在上班時間自動重新打開。

雖然可以使用CronJob來縮放實例，但這只是權宜之計，只能按照預先設定的時間表照計劃運行。

周末怎么辦？公共假期又如何處理？如果整個團隊都生病無法到崗呢？

與其編制一個不斷增長的規(guī)則列表，不如根據(jù)流量來擴展我們的工作負載。當流量增加時，可以擴展副本數(shù)量；當沒有流量時，可以將整個應用關閉。當應用關閉后又收到新的傳入請求后，Kubernetes會啟動至少一個副本來處理這些流量。

接下來一起看看該如何攔截去往應用程序的所有流量，監(jiān)控流量，并設置Autoscaler調整副本數(shù)量或關閉應用。

2.創(chuàng)建集群

首先需要創(chuàng)建一個Kubernetes集群。可使用下列命令創(chuàng)建一個集群并保存kubeconfig文件。

$ linode-cli lke cluster-create \
 --label cluster-manager \
 --region eu-west \
 --k8s_version 1.23
$ linode-cli lke kubeconfig-view "insert cluster id here" --text | tail +2 | base64 -d > kubeconfig

通過下列命令驗證安裝過程已成功完成：

$ kubectl get pods -A --kubecnotallow=kubeconfig

用環(huán)境變量導出kubeconfig文件通常是一種比較方便的做法。為此可以運行：

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

接著需要部署應用程序。

3.部署應用程序

apiVersion: apps/v1
kind: Deployment
metadata:
 name: podinfo
spec:
 selector:
 matchLabels:
 app: podinfo
 template:
 metadata:
 labels:
 app: podinfo
 spec:
 containers:
 - name: podinfo
 image: stefanprodan/podinfo
 ports:
 - containerPort: 9898
---
apiVersion: v1
kind: Service
metadata:
 name: podinfo
spec:
 ports:
 - port: 80
 targetPort: 9898
 selector:
 app: podinfo
使用下列命令提交YAML文件：
terminal|command=1|title=bash
$ kubectl apply -f 1-deployment.yaml

隨后即可訪問該應用，為此請打開瀏覽器并訪問localhost:8080。

$ kubectl port-forward svc/podinfo 8080:80

接著應該就能看到這個應用了。

接下來需要安裝KEDA，也就是本例中將會用到的Autoscaler。

4.KEDA：Kubernetes事件驅動的Autoscaler

Kubernetes提供的Horizontal Pod Autoscaler（HPA）可以作為控制器動態(tài)增減副本數(shù)量。然而HPA有一些不足之處：

• 無法拆箱即用，需要安裝Metrics Server匯總和暴露指標。
• 無法縮放至零副本。
• 只能根據(jù)指標縮放副本，并且無法攔截HTTP流量。

好在并非只能使用官方提供的Autoscaler，我們還可以使用KEDA。KEDA是一種為下列三個組件打造的Autoscaler：

• Scaler
• Metrics Adapter
• Controller

Scaler類似于適配器，可以從數(shù)據(jù)庫、消息代理、遙測系統(tǒng)等處收集指標。例如，HTTP Scaler這個適配器就可以攔截并收集HTTP流量。我們可以在這里看到一個 使用RabbitMQ的Scaler范例。

Metrics Adapter負責以Kubernetes指標管道可以使用的格式導出Scaler所收集的指標。

最后，Controller可以將所有這些組件緊密結合在一起：

• 使用適配器收集指標，并將其暴露給指標API。
• 注冊并管理KEDA指定的自定義資源定義（CRD），例如ScaledObject、TriggerAuthentication等。
• 代替我們創(chuàng)建并管理Horizontal Pod Autoscaler。

理論上的介紹就是這些了，一起看看它們實際上是如何起效的。

我們可以使用Helm快速安裝Controller，詳細的說明和介紹請參閱Helm官網。

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

KEDA默認并不包含HTTP Scaler，因此需要單獨安裝：

$ helm install http-add-on kedacore/keda-add-ons-http

隨后就可以擴展我們的應用了。

5.定義Autoscaling策略

KEDA的HTTP加載項會暴露出一個CRD，借此我們可以描述應用程序的擴展方式。一起看一個例子：

kind: HTTPScaledObject
apiVersion: http.keda.sh/v1alpha1
metadata:
 name: podinfo
spec:
 host: example.com
 targetPendingRequests: 100
 scaleTargetRef:
 deployment: podinfo
 service: podinfo
 port: 80
 replicas:
 min: 0
 max: 10

該文件會指示攔截器將有關http://example.com的請求轉發(fā)給podinfo服務。

其中還包含了需要擴展的部署的名稱，本例中為podinfo。

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

$ kubectl apply -f scaled-object.yaml

提交了上述定義后，Pod被刪除了！為何會這樣？

在創(chuàng)建了HTTPScaledObject后，KEDA會立即將該部署收縮到零，因為目前沒有流量。

為了進行擴展，我們必須向應用發(fā)出HTTP請求。試試看連接到該服務并發(fā)出一個請求。

$ kubectl port-forward svc/podinfo 8080:80

這個命令被掛起了！

這種現(xiàn)象是合理的，因為目前沒有可以為請求提供服務的Pod。但Kubernetes為何沒有將該部署擴展為1？

6.測試KEDA攔截器

在使用Helm安裝加載項時，會創(chuàng)建一個名為keda-add-ons-http-interceptor-proxy的Kubernetes服務。為了讓自動擴展能夠正常起效，HTTP流量必須首先通過該服務進行路由。我們可以用kubectl port-forward進行測試：

$ kubectl port-forward svc/keda-add-ons-http-interceptor-proxy 8080:8080

這一次我們無法在瀏覽器中訪問該URL。

一個KEDA HTTP攔截器可以處理多個部署，那么它如何知道要將流量路由到哪里？

kind: HTTPScaledObject
apiVersion: http.keda.sh/v1alpha1
metadata:
 name: podinfo
spec:
 host: example.com
 targetPendingRequests: 100
 scaleTargetRef:
 deployment: podinfo
 service: podinfo
 port: 80
 replicas:
 min: 0
 max: 10

針對這種情況，HTTPScaledObject使用了一個host 段。在本例中，我們需要假裝請求來自http://example.com。為此需要設置Host頭：

$ curl localhost:8080 -H 'Host: example.com'

我們將收到一個回應，盡管略微有些延遲。

檢查Pod會發(fā)現(xiàn)，部署已經被擴展至一個副本：

$ kubectl get pods

那么剛才到底發(fā)生了什么？

在將流量路由至KEDA的服務時，攔截器會追蹤尚未收到回復的未決HTTP請求數(shù)量。KEDA Scaler會定期檢查攔截器的隊列大小，并存儲相關指標信息。

KEDA Controller會監(jiān)控指標，并根據(jù)需要增大或減小副本數(shù)量。本例中有一個未決請求，此時KEDA Controller將部署擴展為一個副本就已足夠。

我們可以通過下列方式獲取每個攔截器的未決HTTP請求隊列狀態(tài)：

$ kubectl proxy &
$ curl -L localhost:8001/api/v1/namespaces/default/services/keda-add-ons-http-interceptor-admin:9090/proxy/queue
{"example.com":0,"localhost:8080":0}

由于這種設計的存在，我們必須慎重決定該用何種方式將流量路由給應用。KEDA只能在流量可被攔截的情況下才會對部署進行擴展。

如果有一個現(xiàn)有的入口Controller，并且希望使用該Controller將流量轉發(fā)給應用，那么還需要修改入口清單，將流量轉發(fā)給HTTP加載項服務。一起看一個例子。

7.將KEDA HTTP加載項與入口配合使用

我們可以使用Helm安裝Nginx-ingress controller：

$ helm upgrade --install ingress-nginx ingress-nginx \
 --repo https://kubernetes.github.io/ingress-nginx \
 --namespace ingress-nginx --create-namespace

隨后寫一個入口清單，將流量路由給podinfo：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
 name: podinfo
spec:
 ingressClassName: nginx
 rules:
 - host: example.com
 http:
 paths:
 - path: /
 pathType: Prefix
 backend:
 service:
 name: keda-add-ons-http-interceptor-proxy # <- this
 port:
 number: 8080

通過下列命令可以獲取負載均衡器的IP地址：

LB_IP=$(kubectl get services -l "app.kubernetes.io/compnotallow=controller" -o jsnotallow="{.items[0].status.loadBalancer.ingress
[0].ip}" -n ingress-nginx)

最后使用下列命令向應用發(fā)出一個請求：

curl $LB_IP -H "Host: example.com"

起作用了！如果等待足夠長的時間，我們還將注意到，該部署最終被收縮到零。

三、通過Autoscaler實現(xiàn)Kubernetes的伸縮

在設計Kubernetes集群時，我們可能經常需要回答以下問題：

• 集群伸縮需要多長時間？
• 在新Pod創(chuàng)建之前需要等待多長時間？

有四個主要因素會影響集群的伸縮：

• Horizontal Pod Autoscaler的反應時間；
• Cluster Autoscaler的反應時間；
• 節(jié)點預配時間；以及
• Pod創(chuàng)建時間。

下文將依次討論這些因素。

默認情況下，kubelet每10秒從Pod中提取一次CPU使用情況數(shù)據(jù)，而Metrics Server每1分鐘從kubelet獲取一次這些數(shù)據(jù)。Horizontal Pod Autoscaler每30秒檢查一次CPU和內存度量。

如果度量超過閾值，Autoscaler會增加Pod的副本數(shù)，并在采取進一步行動之前暫停3分鐘。在最糟糕的情況下，可能要等待長達3分鐘才能添加或刪除Pod，但平均而言，用戶應該期望等待1分鐘后Horizontal Pod Autoscaler即可觸發(fā)伸縮。

Horizontal Pod Autoscaler的反應時間

Cluster Autoscaler會檢查是否有待處理的Pod，并增加集群的大小。檢測到需要擴展集群可能需要：

• 在具有少于100個節(jié)點和3000個Pod的集群上最多需要30秒，平均延遲約為5秒；或
• 在具有100個以上節(jié)點的集群上最多需要60秒的延遲，平均延遲約為15秒。

Cluster Autoscaler的反應時間

Linode上的節(jié)點預配，也就是從Cluster Autoscaler觸發(fā)API到新創(chuàng)建節(jié)點上可以調度Pod，這一過程需要大約3-4分鐘時間。

Linode的預配時間

簡而言之，對于小規(guī)模集群，我們會面臨：

• HPA延遲：1m +
• CA延遲：0m30s +
• 云提供商：4m +
• 容器運行時：0m30s +

——————————————

總計6m

端到端Autoscaler反應時間

對于具有100個以上節(jié)點的集群，總延遲可能為6分30秒…… 這是一個相當長的時間，那么該如何解決這個問題？可以主動調整工作負載，或者如果非常了解流量模式，也可以提前伸縮。

1.使用KEDA進行預伸縮

如果流量的變化模式可預測，那么在高峰之前擴展工作負載（和節(jié)點）就是可行的。

Kubernetes沒有提供根據(jù)日期或時間擴展工作負載的機制，但我們可以使用上文提到的KEDA實現(xiàn)目標。

使用Helm安裝KEDA：

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

安裝好Prometheus和KEDA后，創(chuàng)建一個部署。

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

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

$ kubectl apply -f deployment.yaml

KEDA在現(xiàn)有的Horizontal Pod Autoscaler之上工作，并使用名為ScaleObject的自定義資源定義（CRD）進行包裝。下列ScaledObject使用Cron Scaler定義了更改副本數(shù)的時間窗口：

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
 name: cron-scaledobject
 namespace: default
spec:
 maxReplicaCount: 10
 minReplicaCount: 1
 scaleTargetRef:
 name: podinfo
 triggers:
 - type: cron
 metadata:
 timezone: Europe/London
 start: 23 * * * *
 end: 28 * * * *
 desiredReplicas: "5"

用下列命令提交對象：

$ kubectl apply -f scaled-object.yaml

接下來會發(fā)生什么？什么也不會發(fā)生。自動伸縮只會在23 * * * *到28 * * * *之間觸發(fā)。在Cron Guru的幫助下，我們可以將這兩個Cron表達式翻譯成：

• 從第23分鐘開始（例如2:23、3:23等）。
• 在第28分鐘停止（例如2:28、3:28等）。

如果等到開始時間，我們將注意到副本數(shù)增加到5。

使用KEDA通過Cron表達式進行伸縮

在第28分鐘后，副本數(shù)是否恢復到1？是的，自動伸縮器會恢復為minReplicaCount中指定的副本數(shù)。

如果在其中一個時間間隔內增加副本數(shù)會發(fā)生什么？如果在23和28分鐘之間，我們將部署的副本數(shù)擴展到10，KEDA將覆蓋我們的更改并設置計數(shù)。如果在第28分鐘后重復相同實驗，副本數(shù)將設置為10。

在了解了理論后，讓我們看一些實際用例。

2.在工作時間內伸縮

假設我們在開發(fā)環(huán)境中部署了一個應該在工作時間段內處于活躍狀態(tài)，并且在夜間應該關閉的工作負載。

可以使用以下ScaledObject：

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
 name: cron-scaledobject
 namespace: default
spec:
 maxReplicaCount: 10
 minReplicaCount: 0
 scaleTargetRef:
 name: podinfo
 triggers:
 - type: cron
 metadata:
 timezone: Europe/London
 start: 0 9 * * *
 end: 0 17 * * *
 desiredReplicas: "10"

默認副本數(shù)為零，但在工作時間（上午9點到下午5點）期間，副本會擴展到10個。

僅在工作時間內擴展工作負載

我們還可以擴展Scaled Object以排除周末：

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
 name: cron-scaledobject
 namespace: default
spec:
 maxReplicaCount: 10
 minReplicaCount: 0
 scaleTargetRef:
 name: podinfo
 triggers:
 - type: cron
 metadata:
 timezone: Europe/London
 start: 0 9 * * 1-5
 end: 0 17 * * 1-5
 desiredReplicas: "10"

這樣，工作負載將僅在周一至周五的9點到17點活躍。由于可以組合多個觸發(fā)器，因此還可以包括一些例外情況。

3.在周末伸縮

我們可能計劃在星期三讓工作負載保持更長時間，為此可使用以下定義：

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
 name: cron-scaledobject
 namespace: default
spec:
 maxReplicaCount: 10
 minReplicaCount: 0
 scaleTargetRef:
 name: podinfo
 triggers:
 - type: cron
 metadata:
 timezone: Europe/London
 start: 0 9 * * 1-5
 end: 0 17 * * 1-5
 desiredReplicas: "10"
 - type: cron
 metadata:
 timezone: Europe/London
 start: 0 17 * * 3
 end: 0 21 * * 3
 desiredReplicas: "10"

在此定義中，工作負載會在周一至周五的9點到17點之間處于活動狀態(tài)，但星期三會從9點持續(xù)到21點。

總結

按需縮放是一種有效降低成本的方法。Kubernetes作為一種容器編排平臺，提供了自動化管理和部署容器化應用程序的功能，使得按需縮放變得更加容易實現(xiàn)。

根據(jù)本文提供的思路，我們可以根據(jù)應用程序的需求變化情況，動態(tài)調整資源，并在需要時自動擴展或縮減規(guī)模，從而降低成本并提高資源利用率。

本文所涉及的內容，不僅適用于Linode平臺上提供的托管式Kubernetes集群，也同樣適用于大家在本地環(huán)境或其他云平臺上部署的集群。希望這些內容對大家有所幫助，也歡迎關注Akamai機構號，了解更多通過云平臺降本增效的技巧。

—————————————————————————————————————————————————

如您所在的企業(yè)也在考慮采購云服務或進行云遷移，

點擊鏈接了解Akamai Linode的解決方案