天貓精靈Sound Pro體驗：智能音箱沒有音質？來聽聽我的
這幾年除了手機作為智能生活終端最主要的核心之外，第二個可以成為中心點的產品是什么？——是智能音箱。 手機在執行命令的時候有兩種操作方式，手和智能語音助手，而智能音箱只
眾所周知，云服務架構可以隨著應用的需求實時擴展，而無需人工進行配置的更改或逐行增加代碼。其中，自動化縮放(Autoscaling)就保證了在無需人工干預的情況下，自動增加或減少應用負載的能力。顯然，如果調整得當，自動化縮放可以降低我們維護應用的成本、以及項目實施的難度。
對于Kubernetes而言，其自動化縮放的過程通常是：首先確定一組何時需要為Kubernetes擴展應用容量的指標。接著，設定一組被用來判定應用是該擴展、還是縮容的規則。最后，使用各種kubernetes API，對應用程序的可用資源進行擴縮容，以滿足程序執行和服務所需。
自動化縮放雖然是一個看似復雜的過程，但是它能夠比其他技術更好地服務于特殊類別的應用。例如，如果某個應用程序在容量需求上不會經常發生更改的話，那么我們最好為其調配至最大的流量資源。類似地，如果您能夠可靠地預測到某個應用的負載，則可以通過手動、而非自動的方式來調整容量。
除了應對應用程序的負載變化，自動調整功能還能夠有效地進行成本和容量管理。例如，集群的自動調整功能允許您通過調整集群中的節點數量，來節省在公共云上的租金。此外，如果您有一個靜態的架構，那么自動化調整將使您能夠動態地管理分配給流量負載的容量，以便您能夠更好地利用自己的基礎設施。
在實際應用中，自動化縮放主要分為如下兩類：
1. 負載的自動調整：動態地管理單個負載的容量，并進行自動分配。
2. 群集的自動縮放：動態地管理群集的容量。
讓我們首先了解一下在Kubernetes中擴展負載的細節。目前，在Kubernetes上可被用于自動調整工作負載的標準化工具包括：水平Pod自動化縮放(Horizontal Pod Autoscaler，HPA)、垂直Pod自動化縮放(Vertical Pod Autoscaler，VPA)、以及集群比例自動化縮放(Cluster Proportional Autoscaler，CPA)。下面，讓我們通過一個群集和簡單的測試應用程序，來模擬Kubernetes的自動化縮放功能。
創建Linode-Kubernetes引擎集群
由Linode提供的名為Linode kubernetes引擎(LKE)的托管式Kubernetes產品，非常容易入門。您可以注冊一個免費的Linode帳戶，然后按照LKE入門指南創建一個集群。
如下圖所示，我創建了一個由兩個節點(稱為Linodes)組成的集群，每個節點都有2個CPU內核和4 GB內存：
LKE集群
為了使用該集群，您需要從集群的概述部分下載kubeconfig文件。雖然有好幾種策略可供我們合并kubeconfig文件，但是我更喜歡通過更新帶有指向kubeconfig文件路徑的KUBECONDIG環境變量的方式來實現。
下面，讓我們來構建一個簡單的應用程序，以用來測試各種自動化縮放。
Pressure API
Pressure API應用運行在兩個端點上。它屬于.NET REST API，允許您通過如下兩種途徑，將CPU和內存的壓力施加到pod上：
1. /memory/{numMegaBytes}/duration/{durationSec}：此端點將向內存添加指定數量的兆字節，并在指定的持續時間內保持壓力。
2. /cpu/{threads}/duration/{durationSec}：此端點將在CPU上運行指定數量的線程，并在指定的持續時間內保持壓力。
以下是該應用的完整源代碼：
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();
您不必擔心應用的細節。我已經在GitHub存儲庫(https://github.com/rahulrai-in/dotnet-pressure-api)上發布了可供下載的容器鏡像、及其相關組件。您可以在K8s的各項規范中使用該鏡像。同時，下文中使用到的Kubernetes各個規范，都被存放在代碼存儲庫的spec文件夾中。在此，我們使用如下規范將應用部署到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
該應用目前雖然可以接受請求，但是只能在集群中被訪問到。我稍后將使用一個臨時的pod向API發送各種請求。不過，現在讓我們先來討論最常見的自動化縮放組件：水平Pod自動化縮放(HPA)。
水平Pod自動化縮放(HPA)
水平Pod自動化縮放允許您根據當前的負載，動態調整集群中的pod數量。Kubernetes通過HorizontalPodAutoscaler資源和綁定到kube-controller-manager的控制器，來原生地支持其水平自動化縮放。而HPA主要依賴Kubernetes Metrics Server來提供PodMetrics。Metrics Server會從集群中的每個節點上收集CPU和內存的使用情況，并通過Metrics API提供出去。下圖展示了該過程中涉及的各個組件：
水平Pod自動化縮放
Metrics Server會去輪詢kubelet端點上的Summary API，以收集在pods中運行的容器資源的使用指標。在默認情況下，HPA控制器將代理Metrics Server，每15秒輪詢一次Kubernetes API服務器的Metrics API端點。此外，HPA控制器也會持續監視HorizontalPodAutoscaler資源，以維持自動化縮放的配置。接著，HPA控制器會根據各種配置(或其他已配置的資源)去更新部署中的pod數量，以匹配相應的需求。最后，部署控制器通過更新復制集(ReplicaSet)來響應更改，完成pod數量的調整。
作為HPA和VPA的先決條件，您可以根據官方指南中提到的相關說明，在自己的集群上安裝Metrics Server。如果您在安裝時遇到TLS問題，那么請在代碼庫的spec目錄下，按照如下方式使用metrics-server.yaml規范：
Shell
kubectl apply -f spec/metrics-server.yaml
現在，讓我們根據如下yaml內容，通過配置HorizontalPodAutoscaler對象，將部署擴展到五個副本，并根據內存資源的平均利用率，將其縮小至一個副本：
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
如果內存的平均利用率保持在40%以上，那么HPA將增加副本的數量，反之亦然。您也可以將該規則運用到CPU利用率上。在這種情況下，HPA控制器將根據規則的組合，來確定并使用副本的最大數量。
在開始之前，讓我們通過如下命令，在兩個不同的終端窗口中觀察HPA及其部署，以實時查看到副本數量的變化。
Shell
kubectl get hpa pressure-api-hpa --watch
kubectl get deployment pressure-api-deployment --watch
為了觸發HPA，我們將啟動一個臨時的pod，并讓它向/memory/{numBytes}/duration/{durationSec}端點發送請求。下面的命令將觸發HPA通過擴展pods來減少內存的壓力。
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更新部署的副本數量。下圖展示了活動的利用率相對于目標的增長情況：
運行中的HPA
同時，您也可以從下圖中看到復制副本的變化：
由HPA觸發的副本數量的增加
在使用HPA時，請記住如下注意事項：
應用程序應當能夠在不同的實例之間共享負載。集群應該有足夠的容量，來容納擴展的pod數量。這可以通過提前配置所需的容量，并使用警報來提示平臺操作員向集群添加更多的容量來實現。當然，您也可以使用群集自動化縮放來實現，我們將在下文中討論。CPU和內存可能并非應用程序做出縮放決策的正確指標。在這種情況下，您可以將HPA(或VPA)與自定義指標結合使用，并使用自定義的指標適配器而非Kubernetes Metrics Server，來實現自動化的縮放。其中，常用的自定義指標適配器有Prometheus適配器和Kubernetes事件驅動自動縮放器(Kubernetes Event-Driven Autoscaler，KEDA)。
在繼續討論VPA之前，請刪除掉剛才創建的HPA，并按照如下命令重置部署的副本數量：
Shell
kubectl delete hpa/pressure-api-hpa
kubectl scale --replicas=2 deployment/pressure-api-deployment垂直Pod自動化縮放(VPA)
垂直Pod自動化縮放允許您動態調整單個實例的資源容量。在pods的上下文環境中，這涉及到更改pod可以使用到的CPU和內存資源數量。與HPA不同，除了Metrics Server外，VPA還需要安裝三個控制器組件。下圖展示了Kubernetes組件、及其與VPA的交互：
垂直Pod自動化縮放
Recommender：根據pod資源的使用情況，確定最佳的CPU和內存值。Admission plug-in：在根據Recommender的建議創建pod時，更改pod的資源請求和限制。Updater：逐出pod，以便Admission plug-in攔截其重建請求。
請跟隨VPA指南中的安裝說明準備您的集群。安裝完成后，您可以通過運行如下命令，驗證VPA組件的運行狀況：
Shell
kubectl get pods -l "app in (vpa-recommender,vpa-admission-controller,vpa-updater)" -n kube-system
VPA Pod的健康狀況
下面，讓我們了解一下VPA縮放操作的工作原理。首先，資源請求會通過pod規范中的聲明，以確保Kubernetes保留了pod所需的最少資源。接著，當VPA檢測到pod接近其資源消耗的限制時，它將自動計算出一組新的、更合適的數值。如果您定義了資源請求、以及在pod規范中的資源限制，那么VPA將在更新數值的時候，保持請求限制(request:limit)的比率。而且，每當VPA更新資源請求時，它都會改變資源的限制。
如下YAML所示，我們將定義一個VPA的策略，來自動化調整CPU和內存的請求，而無需向處理負載添加更多的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
該規范將適用于部署中的所有容器，其最小和最大閾值將確保VPA在合理的范圍內運行。其中，controlledResources字段指定了由VPA自動縮放的資源。
目前，VPA支持四種更新模式。其中，Recreate和Auto模式是激活自動化縮放的唯一方式。不過，它們的實際用例比較有限。Initial模式將在創建資源值時，對其實施許可控制，當然它也會阻止Updater逐出任何pod。而Off模式最為實用。在該模式下，VPA雖然不會縮放資源，但是會推薦資源值。因此，在應用程序進入生產環境之前，您可以使用該模式在應用的全面負載測試、以及分析期間，計算出最佳的資源值，以便將其應用于生產部署的規范中，以節省工程量。
對此，我們可以應用前面的規范，并通過執行如下命令，來監控自動化的縮放：
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"
一段時間后，您可以執行如下命令，以查看VPA所生成的建議。
Shell
kubectl describe vpa/pressure-api-vpa
下圖是上述命令的輸出結果，其中顯示了源于VPA的各項建議：
VPA的建議
可見，它建議使用Target值作為CPU和內存請求的基線。如果VPA規范中定義的上限和下限并非最優的話，它會使用Uncapped Target作為基線，以表示沒有minAllowed和maxAllowed限制的目標估值。
此外，由于我們啟用了垂直自動化縮放，因此新創建的pod將會由admission控制器執行VPA的各種注釋。您可以通過如下命令查看pod的注釋：
Shell
kubectl get pod -o jsonpath='{.metadata.annotations}'
下面便是上述命令的輸出(來自K9s控制臺，https://github.com/derailed/k9s)：
Pod的注釋
在討論下一種自動化縮放之前，讓我們使用如下命令刪除并重置當前部署。
Shell
kubectl delete vpa/pressure-api-vpa
kubectl scale --replicas=1 deployment/pressure-api-deployment集群比例自動化縮放(CPA)
集群比例自動化縮放(CPA)屬于一種水平pod自動化縮放。它會根據群集中的節點數量來縮放副本。與其他自動化縮放不同的是，它既不依賴于Metrics API，也不需要Metrics Server。此外，CPA并不使用Kubernetes資源來實現縮放，而是使用各種標志，來標識目標負載和用于擴展配置的ConfigMap。下圖展示了CPA的各個組件：
集群比例自動化縮放
CPA的用例比較有限。例如，CPA通常被用于諸如集群DNS的橫向擴展平臺服務。它們往往需要隨著部署在集群上的負載而自動進行擴展。CPA的另一個用例是，由于不需要使用Metrics Server或Prometheus適配器，因此可以通過簡單的機制，來擴展出各種負載。
您可以使用CPA的Helm圖表，在集群上安裝CPA，并使用如下命令添加cluster-proportional-autoscaler的Helm存儲庫：
Shell
helm repo add cluster-proportional-autoscaler https://kubernetes-sigs.github.io/cluster-proportional-autoscaler
helm repo update
您可以在圖表值文件中定義自動化縮放的規則，以便能夠根據指定的配置，創建配置映射。據此，您可以進行后續的ConfigMap編輯，以更改自動化縮放的行為，而不必重新安裝圖表。
請創建一個名為cpa-values.yaml的文件，并添加如下內容：
YAML
config:
ladder:
nodesToReplicas:
- [1, 3]
- [2, 5]
options:
namespace: default
target: "deployment/pressure-api-deployment"
我們可以指定CPA使用如下縮放方法中的一種：
Linear：按照與群集中節點或核心數量成正比的方式，縮放應用。Ladder：使用步進函數(step function)確定nodes:replicas和/或cores:replicas的比率。
在上面的示例中，如果集群中有一個節點，那么CPA會將部署擴展為三個副本。您可以通過如下命令安裝圖表，并為其提供配置。
Shell
helm upgrade --install cluster-proportional-autoscaler
cluster-proportional-autoscaler/cluster-proportional-autoscaler --values cpa-values.yaml
一旦完成CPA的安裝，您將會發現，由于我們的集群上有兩個節點，因此它可以將pressure-api-deployment擴展到5個副本。
同樣，在討論集群自動化縮放之前，讓我們使用如下命令來刪除掉現有部署：
Shell
helm delete cluster-proportional-autoscaler
我們已經討論了如何使用核心Kubernetes、以及由社區構建的附加組件，來自動調整負載。下面，我們將討論如何擴展Kubernetes集群本身。
群集自動化縮放(CA)
手動增減Kubernetes集群的容量，會顯著增加集群的管理成本和工程量，因此我們需要讓CA與HPA配合使用。一旦HPA開始接近計算資源的極限，CA就可以計算出需要滿足的節點數量，并向集群中添加新的節點。此外，當CA發現某些節點在較長的時間內未被充分利用時，它可以將pods重新調度到其他的節點處，進而將未充分利用的節點從集群中移除。
集群自動化縮放在具體實現上會因云服務提供商的不同而不盡相同。例如，Azure和AWS之類的云服務提供商，就能夠支持Cluster API，并運用Kubernetes的operator去管理群集架構。群集自動化縮放也可以通過卸載的方式，為群集API的控制器調整節點的數量。在實施群集自動化調整之前，請認真考慮如下方面：
1. 確保能夠掌握應用在負載下的行為，并消除那些阻礙應用進行水平擴展的瓶頸。
2. 了解云服務提供商可能強制實施的縮放上限。
3. 了解集群在按需擴展時的速度。
在LKE上啟用群集自動化縮放，其實非常容易。首先，如下圖所示，請導航到集群的概覽頁面，并單擊Autoscale Pool按鈕。
LKE集群的概覽頁面
然后，在下面的對話框中，輸入LKE應維護的最小和最大節點數：
啟用LKE的群集自動化縮放
LKE的集群自動化縮放既能夠響應那些由于計算資源不足，而無法被調度的Pending pod，又可以通過監控未充分利用的節點，將其從集群中刪除，以縮小集群的整體規模。
下面，我們來看一個被分配了2個CPU核和4 GB內存的雙節點集群。為了觸發群集的自動化縮放，我們可以通過如下命令，向應用添加更多的副本：
Shell
kubectl scale --replicas=15 deployment/pressure-api-deployment
在命令執行完畢后，您將會在下圖中看到那些被部署的pod已進入了掛起狀態：
等待調度的pod
如下圖所示，LKE不久會將更多的節點添加到集群中，并在新的節點上調度它們：
LKE擴展集群
由于我們指定了讓LKE擴展至多四個節點，因此您會發現一些pod仍然處于掛起狀態。最后，讓我們同樣以如下命令來清理環境。
Shell
kubectl delete deployment/pressure-api-deployment小結
綜上所述，我們討論了水平自動化縮放、垂直自動化縮放、以及集群自動化縮放的相關概念、用例和注意事項。以LKE為代表的托管式Kubernetes服務，能夠通過內置的自動化調整工具，為您減少各種手動管理的工作量。總的說來：
如果您的應用經常受到容量需求變化的影響，那么可以使用HPA來水平擴展它們。VPA可以幫助您確定應用程序的最佳資源值。CPA則可以幫助您滿足需要隨著集群中的負載進行擴展的應用需求。如果負載可能會擴展到超過集群本身的容量，那么就需要使用CA來自動調整集群本身。譯者介紹
陳峻 (Julian Chen)，51CTO社區編輯，具有十多年的IT項目實施經驗，善于對內外部資源與風險實施管控，專注傳播網絡與信息安全知識與經驗;持續以博文、專題和譯文等形式，分享前沿技術與新知;經常以線上、線下等方式，開展信息安全類培訓與授課。
原文標題：Practical Introduction to Kubernetes Autoscaling Tools with Linode Kubernetes Engine，作者: Rahul Rai
本文鏈接：http://www.www897cc.com/showinfo-119-2260-0.html使用Linode引擎實現Kubernetes自動縮放的優秀實踐 譯文
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號