眾所周知,云服務(wù)架構(gòu)可以隨著應(yīng)用的需求實(shí)時(shí)擴(kuò)展,而無(wú)需人工進(jìn)行配置的更改或逐行增加代碼。其中,自動(dòng)化縮放(Autoscaling)就保證了在無(wú)需人工干預(yù)的情況下,自動(dòng)增加或減少應(yīng)用負(fù)載的能力。顯然,如果調(diào)整得當(dāng),自動(dòng)化縮放可以降低我們維護(hù)應(yīng)用的成本、以及項(xiàng)目實(shí)施的難度。
對(duì)于Kubernetes而言,其自動(dòng)化縮放的過(guò)程通常是:首先確定一組何時(shí)需要為Kubernetes擴(kuò)展應(yīng)用容量的指標(biāo)。接著,設(shè)定一組被用來(lái)判定應(yīng)用是該擴(kuò)展、還是縮容的規(guī)則。最后,使用各種kubernetes API,對(duì)應(yīng)用程序的可用資源進(jìn)行擴(kuò)縮容,以滿足程序執(zhí)行和服務(wù)所需。
自動(dòng)化縮放雖然是一個(gè)看似復(fù)雜的過(guò)程,但是它能夠比其他技術(shù)更好地服務(wù)于特殊類別的應(yīng)用。例如,如果某個(gè)應(yīng)用程序在容量需求上不會(huì)經(jīng)常發(fā)生更改的話,那么我們最好為其調(diào)配至最大的流量資源。類似地,如果您能夠可靠地預(yù)測(cè)到某個(gè)應(yīng)用的負(fù)載,則可以通過(guò)手動(dòng)、而非自動(dòng)的方式來(lái)調(diào)整容量。
除了應(yīng)對(duì)應(yīng)用程序的負(fù)載變化,自動(dòng)調(diào)整功能還能夠有效地進(jìn)行成本和容量管理。例如,集群的自動(dòng)調(diào)整功能允許您通過(guò)調(diào)整集群中的節(jié)點(diǎn)數(shù)量,來(lái)節(jié)省在公共云上的租金。此外,如果您有一個(gè)靜態(tài)的架構(gòu),那么自動(dòng)化調(diào)整將使您能夠動(dòng)態(tài)地管理分配給流量負(fù)載的容量,以便您能夠更好地利用自己的基礎(chǔ)設(shè)施。
在實(shí)際應(yīng)用中,自動(dòng)化縮放主要分為如下兩類:
1. 負(fù)載的自動(dòng)調(diào)整:動(dòng)態(tài)地管理單個(gè)負(fù)載的容量,并進(jìn)行自動(dòng)分配。
2. 群集的自動(dòng)縮放:動(dòng)態(tài)地管理群集的容量。
讓我們首先了解一下在Kubernetes中擴(kuò)展負(fù)載的細(xì)節(jié)。目前,在Kubernetes上可被用于自動(dòng)調(diào)整工作負(fù)載的標(biāo)準(zhǔn)化工具包括:水平Pod自動(dòng)化縮放(Horizontal Pod Autoscaler,HPA)、垂直P(pán)od自動(dòng)化縮放(Vertical Pod Autoscaler,VPA)、以及集群比例自動(dòng)化縮放(Cluster Proportional Autoscaler,CPA)。下面,讓我們通過(guò)一個(gè)群集和簡(jiǎn)單的測(cè)試應(yīng)用程序,來(lái)模擬Kubernetes的自動(dòng)化縮放功能。
創(chuàng)建Linode-Kubernetes引擎集群
由Linode提供的名為L(zhǎng)inode kubernetes引擎(LKE)的托管式Kubernetes產(chǎn)品,非常容易入門(mén)。您可以注冊(cè)一個(gè)免費(fèi)的Linode帳戶,然后按照LKE入門(mén)指南創(chuàng)建一個(gè)集群。
如下圖所示,我創(chuàng)建了一個(gè)由兩個(gè)節(jié)點(diǎn)(稱為L(zhǎng)inodes)組成的集群,每個(gè)節(jié)點(diǎn)都有2個(gè)CPU內(nèi)核和4 GB內(nèi)存:
LKE集群
為了使用該集群,您需要從集群的概述部分下載kubeconfig文件。雖然有好幾種策略可供我們合并kubeconfig文件,但是我更喜歡通過(guò)更新帶有指向kubeconfig文件路徑的KUBECONDIG環(huán)境變量的方式來(lái)實(shí)現(xiàn)。
下面,讓我們來(lái)構(gòu)建一個(gè)簡(jiǎn)單的應(yīng)用程序,以用來(lái)測(cè)試各種自動(dòng)化縮放。
Pressure API
Pressure API應(yīng)用運(yùn)行在兩個(gè)端點(diǎn)上。它屬于.NET REST API,允許您通過(guò)如下兩種途徑,將CPU和內(nèi)存的壓力施加到pod上:
1. /memory/{numMegaBytes}/duration/{durationSec}:此端點(diǎn)將向內(nèi)存添加指定數(shù)量的兆字節(jié),并在指定的持續(xù)時(shí)間內(nèi)保持壓力。
2. /cpu/{threads}/duration/{durationSec}:此端點(diǎn)將在CPU上運(yùn)行指定數(shù)量的線程,并在指定的持續(xù)時(shí)間內(nèi)保持壓力。
以下是該應(yīng)用的完整源代碼:
C#
using System.Xml;
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddEndpointsApiExplorer();
builder.Services.AddSwaggerGen();
var app = builder.Build();
if (app.Environment.IsDevelopment())
{
app.UseSwagger();
app.UseSwaggerUI();
}
app.MapPost("/memory/{numMegaBytes}/duration/{durationSec}", (long numMegaBytes, int durationSec) =>
{
// ReSharper disable once CollectionNeverQueried.Local
List memList = new();
try
{
while (GC.GetTotalMemory(false) <= numMegaBytes * 1000 * 1000)
{
XmlDocument doc = new();
for (var i = 0; i < 1000000; i++)
{
memList.Add(doc.CreateNode(XmlNodeType.Element, "node", string.Empty));
}
}
}
// Don't fail if memory is not available
catch (OutOfMemoryException ex)
{
Console.WriteLine(ex);
}
Thread.Sleep(TimeSpan.FromSeconds(durationSec));
memList.Clear();
GC.Collect();
GC.WaitForPendingFinalizers();
return Results.Ok();
})
.WithName("LoadMemory");
app.MapPost("/cpu/{threads}/duration/{durationSec}", (int threads, int durationSec) =>
{
CancellationTokenSource cts = new();
for (var counter = 0; counter < threads; counter++)
{
ThreadPool.QueueUserWorkItem(tokenIn =>
{
#pragma warning disable CS8605 // Unboxing a possibly null value.
var token = (CancellationToken)tokenIn;
#pragma warning restore CS8605 // Unboxing a possibly null value.
while (!token.IsCancellationRequested)
{
}
}, cts.Token);
}
Thread.Sleep(TimeSpan.FromSeconds(durationSec));
cts.Cancel();
Thread.Sleep(TimeSpan.FromSeconds(2));
cts.Dispose();
return Results.Ok();
})
.WithName("LoadCPU");
app.Run();
您不必?fù)?dān)心應(yīng)用的細(xì)節(jié)。我已經(jīng)在GitHub存儲(chǔ)庫(kù)(https://github.com/rahulrai-in/dotnet-pressure-api)上發(fā)布了可供下載的容器鏡像、及其相關(guān)組件。您可以在K8s的各項(xiàng)規(guī)范中使用該鏡像。同時(shí),下文中使用到的Kubernetes各個(gè)規(guī)范,都被存放在代碼存儲(chǔ)庫(kù)的spec文件夾中。在此,我們使用如下規(guī)范將應(yīng)用部署到LKE集群中:
YAML
apiVersion: apps/v1
kind: Deployment
metadata:
name: pressure-api-deployment
spec:
selector:
matchLabels:
app: pressure-api
replicas: 1
template:
metadata:
labels:
app: pressure-api
spec:
containers:
- name: pressure-api
image: ghcr.io/rahulrai-in/dotnet-pressure-api:latest
ports:
- containerPort: 80
resources:
limits:
cpu: 500m
memory: 500Mi
---
apiVersion: v1
kind: Service
metadata:
name: pressure-api-service
labels:
run: php-apache
spec:
ports:
- port: 80
selector:
app: pressure-api
該應(yīng)用目前雖然可以接受請(qǐng)求,但是只能在集群中被訪問(wèn)到。我稍后將使用一個(gè)臨時(shí)的pod向API發(fā)送各種請(qǐng)求。不過(guò),現(xiàn)在讓我們先來(lái)討論最常見(jiàn)的自動(dòng)化縮放組件:水平Pod自動(dòng)化縮放(HPA)。
水平Pod自動(dòng)化縮放(HPA)
水平Pod自動(dòng)化縮放允許您根據(jù)當(dāng)前的負(fù)載,動(dòng)態(tài)調(diào)整集群中的pod數(shù)量。Kubernetes通過(guò)HorizontalPodAutoscaler資源和綁定到kube-controller-manager的控制器,來(lái)原生地支持其水平自動(dòng)化縮放。而HPA主要依賴Kubernetes Metrics Server來(lái)提供PodMetrics。Metrics Server會(huì)從集群中的每個(gè)節(jié)點(diǎn)上收集CPU和內(nèi)存的使用情況,并通過(guò)Metrics API提供出去。下圖展示了該過(guò)程中涉及的各個(gè)組件:
水平Pod自動(dòng)化縮放
Metrics Server會(huì)去輪詢kubelet端點(diǎn)上的Summary API,以收集在pods中運(yùn)行的容器資源的使用指標(biāo)。在默認(rèn)情況下,HPA控制器將代理Metrics Server,每15秒輪詢一次Kubernetes API服務(wù)器的Metrics API端點(diǎn)。此外,HPA控制器也會(huì)持續(xù)監(jiān)視HorizontalPodAutoscaler資源,以維持自動(dòng)化縮放的配置。接著,HPA控制器會(huì)根據(jù)各種配置(或其他已配置的資源)去更新部署中的pod數(shù)量,以匹配相應(yīng)的需求。最后,部署控制器通過(guò)更新復(fù)制集(ReplicaSet)來(lái)響應(yīng)更改,完成pod數(shù)量的調(diào)整。
作為HPA和VPA的先決條件,您可以根據(jù)官方指南中提到的相關(guān)說(shuō)明,在自己的集群上安裝Metrics Server。如果您在安裝時(shí)遇到TLS問(wèn)題,那么請(qǐng)?jiān)诖a庫(kù)的spec目錄下,按照如下方式使用metrics-server.yaml規(guī)范:
Shell
kubectl apply -f spec/metrics-server.yaml
現(xiàn)在,讓我們根據(jù)如下yaml內(nèi)容,通過(guò)配置HorizontalPodAutoscaler對(duì)象,將部署擴(kuò)展到五個(gè)副本,并根據(jù)內(nèi)存資源的平均利用率,將其縮小至一個(gè)副本:
YAML
apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
name: pressure-api-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: pressure-api-deployment
minReplicas: 1
maxReplicas: 5
metrics:
- type: Resource
resource:
name: memory
target:
type: Utilization
averageUtilization: 40
如果內(nèi)存的平均利用率保持在40%以上,那么HPA將增加副本的數(shù)量,反之亦然。您也可以將該規(guī)則運(yùn)用到CPU利用率上。在這種情況下,HPA控制器將根據(jù)規(guī)則的組合,來(lái)確定并使用副本的最大數(shù)量。
在開(kāi)始之前,讓我們通過(guò)如下命令,在兩個(gè)不同的終端窗口中觀察HPA及其部署,以實(shí)時(shí)查看到副本數(shù)量的變化。
Shell
kubectl get hpa pressure-api-hpa --watch
kubectl get deployment pressure-api-deployment --watch
為了觸發(fā)HPA,我們將啟動(dòng)一個(gè)臨時(shí)的pod,并讓它向/memory/{numBytes}/duration/{durationSec}端點(diǎn)發(fā)送請(qǐng)求。下面的命令將觸發(fā)HPA通過(guò)擴(kuò)展pods來(lái)減少內(nèi)存的壓力。
Shell
kubectl run -i --tty mem-load-gen --rm --image=busybox --restart=Never -- /bin/sh -c "while sleep 0.01; do wget -q -O- --post-data= http://pressure-api-service/memory/1000/duration/180; done"
您可以在終端窗口中觀察到HPA更新部署的副本數(shù)量。下圖展示了活動(dòng)的利用率相對(duì)于目標(biāo)的增長(zhǎng)情況:
運(yùn)行中的HPA
同時(shí),您也可以從下圖中看到復(fù)制副本的變化:
由HPA觸發(fā)的副本數(shù)量的增加
在使用HPA時(shí),請(qǐng)記住如下注意事項(xiàng):
應(yīng)用程序應(yīng)當(dāng)能夠在不同的實(shí)例之間共享負(fù)載。集群應(yīng)該有足夠的容量,來(lái)容納擴(kuò)展的pod數(shù)量。這可以通過(guò)提前配置所需的容量,并使用警報(bào)來(lái)提示平臺(tái)操作員向集群添加更多的容量來(lái)實(shí)現(xiàn)。當(dāng)然,您也可以使用群集自動(dòng)化縮放來(lái)實(shí)現(xiàn),我們將在下文中討論。CPU和內(nèi)存可能并非應(yīng)用程序做出縮放決策的正確指標(biāo)。在這種情況下,您可以將HPA(或VPA)與自定義指標(biāo)結(jié)合使用,并使用自定義的指標(biāo)適配器而非Kubernetes Metrics Server,來(lái)實(shí)現(xiàn)自動(dòng)化的縮放。其中,常用的自定義指標(biāo)適配器有Prometheus適配器和Kubernetes事件驅(qū)動(dòng)自動(dòng)縮放器(Kubernetes Event-Driven Autoscaler,KEDA)。
在繼續(xù)討論VPA之前,請(qǐng)刪除掉剛才創(chuàng)建的HPA,并按照如下命令重置部署的副本數(shù)量:
Shell
kubectl delete hpa/pressure-api-hpa
kubectl scale --replicas=2 deployment/pressure-api-deployment垂直P(pán)od自動(dòng)化縮放(VPA)
垂直P(pán)od自動(dòng)化縮放允許您動(dòng)態(tài)調(diào)整單個(gè)實(shí)例的資源容量。在pods的上下文環(huán)境中,這涉及到更改pod可以使用到的CPU和內(nèi)存資源數(shù)量。與HPA不同,除了Metrics Server外,VPA還需要安裝三個(gè)控制器組件。下圖展示了Kubernetes組件、及其與VPA的交互:
垂直P(pán)od自動(dòng)化縮放
Recommender:根據(jù)pod資源的使用情況,確定最佳的CPU和內(nèi)存值。Admission plug-in:在根據(jù)Recommender的建議創(chuàng)建pod時(shí),更改pod的資源請(qǐng)求和限制。Updater:逐出pod,以便Admission plug-in攔截其重建請(qǐng)求。
請(qǐng)跟隨VPA指南中的安裝說(shuō)明準(zhǔn)備您的集群。安裝完成后,您可以通過(guò)運(yùn)行如下命令,驗(yàn)證VPA組件的運(yùn)行狀況:
Shell
kubectl get pods -l "app in (vpa-recommender,vpa-admission-controller,vpa-updater)" -n kube-system
VPA Pod的健康狀況
下面,讓我們了解一下VPA縮放操作的工作原理。首先,資源請(qǐng)求會(huì)通過(guò)pod規(guī)范中的聲明,以確保Kubernetes保留了pod所需的最少資源。接著,當(dāng)VPA檢測(cè)到pod接近其資源消耗的限制時(shí),它將自動(dòng)計(jì)算出一組新的、更合適的數(shù)值。如果您定義了資源請(qǐng)求、以及在pod規(guī)范中的資源限制,那么VPA將在更新數(shù)值的時(shí)候,保持請(qǐng)求限制(request:limit)的比率。而且,每當(dāng)VPA更新資源請(qǐng)求時(shí),它都會(huì)改變資源的限制。
如下YAML所示,我們將定義一個(gè)VPA的策略,來(lái)自動(dòng)化調(diào)整CPU和內(nèi)存的請(qǐng)求,而無(wú)需向處理負(fù)載添加更多的pod:
YAML
apiVersion: "autoscaling.k8s.io/v1"
kind: VerticalPodAutoscaler
metadata:
name: pressure-api-vpa
spec:
targetRef:
apiVersion: "apps/v1"
kind: Deployment
name: pressure-api-deployment
updatePolicy:
updateMode: Recreate
resourcePolicy:
containerPolicies:
- containerName: "*"
minAllowed:
cpu: 0m
memory: 0Mi
maxAllowed:
cpu: 1
memory: 2000Mi
controlledResources: ["cpu", "memory"]
controlledValues: RequestsAndLimits
該規(guī)范將適用于部署中的所有容器,其最小和最大閾值將確保VPA在合理的范圍內(nèi)運(yùn)行。其中,controlledResources字段指定了由VPA自動(dòng)縮放的資源。
目前,VPA支持四種更新模式。其中,Recreate和Auto模式是激活自動(dòng)化縮放的唯一方式。不過(guò),它們的實(shí)際用例比較有限。Initial模式將在創(chuàng)建資源值時(shí),對(duì)其實(shí)施許可控制,當(dāng)然它也會(huì)阻止Updater逐出任何pod。而Off模式最為實(shí)用。在該模式下,VPA雖然不會(huì)縮放資源,但是會(huì)推薦資源值。因此,在應(yīng)用程序進(jìn)入生產(chǎn)環(huán)境之前,您可以使用該模式在應(yīng)用的全面負(fù)載測(cè)試、以及分析期間,計(jì)算出最佳的資源值,以便將其應(yīng)用于生產(chǎn)部署的規(guī)范中,以節(jié)省工程量。
對(duì)此,我們可以應(yīng)用前面的規(guī)范,并通過(guò)執(zhí)行如下命令,來(lái)監(jiān)控自動(dòng)化的縮放:
Shell
kubectl get vpa/pressure-api-vpa --watch
然后,我們使用如下命令給CPU施加壓力,以激活VPA:
Shell
kubectl run -i --tty mem-load-gen --rm --image=busybox --restart=Never -- /bin/sh -c "while sleep 0.01; do wget -q -O- --post-data= http://pressure-api-service/cpu/10/duration/180; done"
一段時(shí)間后,您可以執(zhí)行如下命令,以查看VPA所生成的建議。
Shell
kubectl describe vpa/pressure-api-vpa
下圖是上述命令的輸出結(jié)果,其中顯示了源于VPA的各項(xiàng)建議:
VPA的建議
可見(jiàn),它建議使用Target值作為CPU和內(nèi)存請(qǐng)求的基線。如果VPA規(guī)范中定義的上限和下限并非最優(yōu)的話,它會(huì)使用Uncapped Target作為基線,以表示沒(méi)有minAllowed和maxAllowed限制的目標(biāo)估值。
此外,由于我們啟用了垂直自動(dòng)化縮放,因此新創(chuàng)建的pod將會(huì)由admission控制器執(zhí)行VPA的各種注釋。您可以通過(guò)如下命令查看pod的注釋:
Shell
kubectl get pod -o jsonpath='{.metadata.annotations}'
下面便是上述命令的輸出(來(lái)自K9s控制臺(tái),https://github.com/derailed/k9s):
Pod的注釋
在討論下一種自動(dòng)化縮放之前,讓我們使用如下命令刪除并重置當(dāng)前部署。
Shell
kubectl delete vpa/pressure-api-vpa
kubectl scale --replicas=1 deployment/pressure-api-deployment集群比例自動(dòng)化縮放(CPA)
集群比例自動(dòng)化縮放(CPA)屬于一種水平pod自動(dòng)化縮放。它會(huì)根據(jù)群集中的節(jié)點(diǎn)數(shù)量來(lái)縮放副本。與其他自動(dòng)化縮放不同的是,它既不依賴于Metrics API,也不需要Metrics Server。此外,CPA并不使用Kubernetes資源來(lái)實(shí)現(xiàn)縮放,而是使用各種標(biāo)志,來(lái)標(biāo)識(shí)目標(biāo)負(fù)載和用于擴(kuò)展配置的ConfigMap。下圖展示了CPA的各個(gè)組件:
集群比例自動(dòng)化縮放
CPA的用例比較有限。例如,CPA通常被用于諸如集群DNS的橫向擴(kuò)展平臺(tái)服務(wù)。它們往往需要隨著部署在集群上的負(fù)載而自動(dòng)進(jìn)行擴(kuò)展。CPA的另一個(gè)用例是,由于不需要使用Metrics Server或Prometheus適配器,因此可以通過(guò)簡(jiǎn)單的機(jī)制,來(lái)擴(kuò)展出各種負(fù)載。
您可以使用CPA的Helm圖表,在集群上安裝CPA,并使用如下命令添加cluster-proportional-autoscaler的Helm存儲(chǔ)庫(kù):
Shell
helm repo add cluster-proportional-autoscaler https://kubernetes-sigs.github.io/cluster-proportional-autoscaler
helm repo update
您可以在圖表值文件中定義自動(dòng)化縮放的規(guī)則,以便能夠根據(jù)指定的配置,創(chuàng)建配置映射。據(jù)此,您可以進(jìn)行后續(xù)的ConfigMap編輯,以更改自動(dòng)化縮放的行為,而不必重新安裝圖表。
請(qǐng)創(chuàng)建一個(gè)名為cpa-values.yaml的文件,并添加如下內(nèi)容:
YAML
config:
ladder:
nodesToReplicas:
- [1, 3]
- [2, 5]
options:
namespace: default
target: "deployment/pressure-api-deployment"
我們可以指定CPA使用如下縮放方法中的一種:
Linear:按照與群集中節(jié)點(diǎn)或核心數(shù)量成正比的方式,縮放應(yīng)用。Ladder:使用步進(jìn)函數(shù)(step function)確定nodes:replicas和/或cores:replicas的比率。
在上面的示例中,如果集群中有一個(gè)節(jié)點(diǎn),那么CPA會(huì)將部署擴(kuò)展為三個(gè)副本。您可以通過(guò)如下命令安裝圖表,并為其提供配置。
Shell
helm upgrade --install cluster-proportional-autoscaler
cluster-proportional-autoscaler/cluster-proportional-autoscaler --values cpa-values.yaml
一旦完成CPA的安裝,您將會(huì)發(fā)現(xiàn),由于我們的集群上有兩個(gè)節(jié)點(diǎn),因此它可以將pressure-api-deployment擴(kuò)展到5個(gè)副本。
同樣,在討論集群自動(dòng)化縮放之前,讓我們使用如下命令來(lái)刪除掉現(xiàn)有部署:
Shell
helm delete cluster-proportional-autoscaler
我們已經(jīng)討論了如何使用核心Kubernetes、以及由社區(qū)構(gòu)建的附加組件,來(lái)自動(dòng)調(diào)整負(fù)載。下面,我們將討論如何擴(kuò)展Kubernetes集群本身。
群集自動(dòng)化縮放(CA)
手動(dòng)增減Kubernetes集群的容量,會(huì)顯著增加集群的管理成本和工程量,因此我們需要讓CA與HPA配合使用。一旦HPA開(kāi)始接近計(jì)算資源的極限,CA就可以計(jì)算出需要滿足的節(jié)點(diǎn)數(shù)量,并向集群中添加新的節(jié)點(diǎn)。此外,當(dāng)CA發(fā)現(xiàn)某些節(jié)點(diǎn)在較長(zhǎng)的時(shí)間內(nèi)未被充分利用時(shí),它可以將pods重新調(diào)度到其他的節(jié)點(diǎn)處,進(jìn)而將未充分利用的節(jié)點(diǎn)從集群中移除。
集群自動(dòng)化縮放在具體實(shí)現(xiàn)上會(huì)因云服務(wù)提供商的不同而不盡相同。例如,Azure和AWS之類的云服務(wù)提供商,就能夠支持Cluster API,并運(yùn)用Kubernetes的operator去管理群集架構(gòu)。群集自動(dòng)化縮放也可以通過(guò)卸載的方式,為群集API的控制器調(diào)整節(jié)點(diǎn)的數(shù)量。在實(shí)施群集自動(dòng)化調(diào)整之前,請(qǐng)認(rèn)真考慮如下方面:
1. 確保能夠掌握應(yīng)用在負(fù)載下的行為,并消除那些阻礙應(yīng)用進(jìn)行水平擴(kuò)展的瓶頸。
2. 了解云服務(wù)提供商可能強(qiáng)制實(shí)施的縮放上限。
3. 了解集群在按需擴(kuò)展時(shí)的速度。
在LKE上啟用群集自動(dòng)化縮放,其實(shí)非常容易。首先,如下圖所示,請(qǐng)導(dǎo)航到集群的概覽頁(yè)面,并單擊Autoscale Pool按鈕。
LKE集群的概覽頁(yè)面
然后,在下面的對(duì)話框中,輸入LKE應(yīng)維護(hù)的最小和最大節(jié)點(diǎn)數(shù):
啟用LKE的群集自動(dòng)化縮放
LKE的集群自動(dòng)化縮放既能夠響應(yīng)那些由于計(jì)算資源不足,而無(wú)法被調(diào)度的Pending pod,又可以通過(guò)監(jiān)控未充分利用的節(jié)點(diǎn),將其從集群中刪除,以縮小集群的整體規(guī)模。
下面,我們來(lái)看一個(gè)被分配了2個(gè)CPU核和4 GB內(nèi)存的雙節(jié)點(diǎn)集群。為了觸發(fā)群集的自動(dòng)化縮放,我們可以通過(guò)如下命令,向應(yīng)用添加更多的副本:
Shell
kubectl scale --replicas=15 deployment/pressure-api-deployment
在命令執(zhí)行完畢后,您將會(huì)在下圖中看到那些被部署的pod已進(jìn)入了掛起狀態(tài):
等待調(diào)度的pod
如下圖所示,LKE不久會(huì)將更多的節(jié)點(diǎn)添加到集群中,并在新的節(jié)點(diǎn)上調(diào)度它們:
LKE擴(kuò)展集群
由于我們指定了讓LKE擴(kuò)展至多四個(gè)節(jié)點(diǎn),因此您會(huì)發(fā)現(xiàn)一些pod仍然處于掛起狀態(tài)。最后,讓我們同樣以如下命令來(lái)清理環(huán)境。
Shell
kubectl delete deployment/pressure-api-deployment小結(jié)
綜上所述,我們討論了水平自動(dòng)化縮放、垂直自動(dòng)化縮放、以及集群自動(dòng)化縮放的相關(guān)概念、用例和注意事項(xiàng)。以LKE為代表的托管式Kubernetes服務(wù),能夠通過(guò)內(nèi)置的自動(dòng)化調(diào)整工具,為您減少各種手動(dòng)管理的工作量。總的說(shuō)來(lái):
如果您的應(yīng)用經(jīng)常受到容量需求變化的影響,那么可以使用HPA來(lái)水平擴(kuò)展它們。VPA可以幫助您確定應(yīng)用程序的最佳資源值。CPA則可以幫助您滿足需要隨著集群中的負(fù)載進(jìn)行擴(kuò)展的應(yīng)用需求。如果負(fù)載可能會(huì)擴(kuò)展到超過(guò)集群本身的容量,那么就需要使用CA來(lái)自動(dòng)調(diào)整集群本身。譯者介紹
陳峻 (Julian Chen),51CTO社區(qū)編輯,具有十多年的IT項(xiàng)目實(shí)施經(jīng)驗(yàn),善于對(duì)內(nèi)外部資源與風(fēng)險(xiǎn)實(shí)施管控,專注傳播網(wǎng)絡(luò)與信息安全知識(shí)與經(jīng)驗(yàn);持續(xù)以博文、專題和譯文等形式,分享前沿技術(shù)與新知;經(jīng)常以線上、線下等方式,開(kāi)展信息安全類培訓(xùn)與授課。
原文標(biāo)題:Practical Introduction to Kubernetes Autoscaling Tools with Linode Kubernetes Engine,作者: Rahul Rai
本文鏈接:http://www.www897cc.com/showinfo-119-2260-0.html使用Linode引擎實(shí)現(xiàn)Kubernetes自動(dòng)縮放的優(yōu)秀實(shí)踐 譯文
聲明:本網(wǎng)頁(yè)內(nèi)容旨在傳播知識(shí),若有侵權(quán)等問(wèn)題請(qǐng)及時(shí)與本網(wǎng)聯(lián)系,我們將在第一時(shí)間刪除處理。郵件:2376512515@qq.com