應用現(xiàn)代化中的彈性伸縮簡介

應用現(xiàn)代化中的彈性伸縮

這兩年應用現(xiàn)代化的步伐飛快，19年我在很多企業(yè)部署虛擬化，介紹虛擬網(wǎng)絡和虛擬存儲。23年，這些企業(yè)都已經(jīng)上了云原生或考慮云原生了。對于高流量的Web應用程序，實時數(shù)據(jù)分析，大規(guī)模數(shù)據(jù)處理、移動應用程序等業(yè)務，容器比虛擬機更適合，因為它輕量級，快速響應，可輕松移植，并具有很強的彈性伸縮能力。

為什么需要彈性伸縮呢？

?峰值負載應對：促銷活動、節(jié)假日購物季或突發(fā)事件根據(jù)需求快速擴展資源，保證應用可用性和性能。

?提高資源利用率：根據(jù)實際資源負載動態(tài)調整資源規(guī)模，避免基礎設施資源浪費，降低TCO。

?應對故障和容錯：多實例部署和快速替換，提高業(yè)務連續(xù)性和可用性。

?跟隨需求變化：匹配前端的業(yè)務需求及壓力，快速調整規(guī)模，提高事件應對能力，滿足需求和期望。

Horizontal Pod Autoscaling

Kubernetes自身提供一種彈性伸縮的機制，包括Vertical Pod Autoscaler (VPA)和Horizontal Pod Autoscaler (HPA)。HPA根據(jù) CPU 、內存利用率增加或減少副本控制器的 pod 數(shù)量，它是一個擴縮資源規(guī)模的功能特性。

HPA依賴Metrics-Server捕獲CPU、內存數(shù)據(jù)來提供資源使用測量數(shù)據(jù)，也可以根據(jù)自定義指標（如Prometheus）進行擴縮。

由上圖看出，HPA持續(xù)監(jiān)控Metrics-Server的指標情況，然后計算所需的副本數(shù)動態(tài)調整資源副本，實現(xiàn)設置目標資源值的水平伸縮。

但也有一定局限性：

?無外部指標支持。如不同的事件源，不同的中間件/應用程序等，業(yè)務端的應用程序變化及依賴是多樣的，不只是基于CPU和內存擴展。

?無法1->0。應用程序總有0負載的時候，此時不能不運行工作負載嗎？

所以就有了Kubernetes-based Event-Driven Autoscaling（KEDA）！

KEDA

KEDA基于事件驅動進行自動伸縮。什么是事件驅動？我理解是對系統(tǒng)上的各種事件做出反應并采取相應行動（伸縮）。那么KEDA就是一個HPA+多種觸發(fā)器。只要觸發(fā)器收到某個事件被觸發(fā)，KEDA就可以使用HPA進行自動伸縮了，并且，KEDA可以1-0，0-1!

架構

KEDA自身有幾個組件：

?Agent: KEDA激活和停止Kubernetes 工作負載（keda-operator主要功能）

? Metrics: KEDA作為一個Kubernetes指標服務器，向Horizontal Pod Autoscaler提供豐富的事件數(shù)據(jù)，從源頭上消費事件。（keda-operator-metrics-apiserver主要作用）。

? Admission Webhooks: 自動驗證資源變化，以防止錯誤配置。

? Event sources: KEDA 更改 pod 數(shù)量的外部事件/觸發(fā)源。如Prometheus、Kafka。

? Scalers: 監(jiān)視事件源，獲取指標并根據(jù)事件觸發(fā)伸縮。

? Metrics adapter:從Scalers獲取指標并發(fā)送給HPA。

? Controller: 根據(jù)Adapter提供的指標進行操作，調諧到 ScaledObject 中指定的資源狀態(tài)。Scaler根據(jù) ScaledObject 中設置的事件源持續(xù)監(jiān)視事件，發(fā)生任何觸發(fā)事件時將指標傳遞給Metrics Adapter。Metrics Adapter調整指標并提供給Controller組件，Controller根據(jù) ScaledObject 中設置的縮放規(guī)則擴大或縮小Deployment。

總的來說，KEDA設置一個ScaledObject，定義一個事件觸發(fā)器，可以是來自消息隊列的消息、主題訂閱的消息、存儲隊列的消息、事件網(wǎng)關的事件或自定義的觸發(fā)器。基于這些事件來自動調整應用程序的副本數(shù)量或處理程序的資源配置，以根據(jù)實際負載情況實現(xiàn)彈性伸縮。

CRD

? ScaledObjects：代表事件源（如 Rabbit MQ）和 Kubernetes Deployment、StatefulSet 或任何定義 / 規(guī)模子資源的自定義資源之間的所需映射。

? ScaledJobs：事件源和Kubernetes Jobs之間的映射。根據(jù)事件觸發(fā)調整Job規(guī)模。

? TriggerAuthentications：觸發(fā)器的認證參數(shù)

? ClusterTriggerAuthentications：集群維度認證

部署KEDA

helmrepoaddkedacorehttps://kedacore.github.io/charts
helmrepoupdate
kubectlcreatenamespacekeda
helminstallkedakedacore/keda--namespacekeda

kubectlapply-fhttps://github.com/kedacore/keda/releases/download/v2.10.1/keda-2.10.1.yaml
root@node-1:/#kubectlgetall-nkeda
NAMEREADYSTATUSRESTARTSAGE
pod/keda-metrics-apiserver-7d89dbcb54-v22nl1/1Running044s
pod/keda-operator-5bb9b49d7c-kh6wt0/1Running044s
NAMETYPECLUSTER-IPEXTERNAL-IPPORT(S)AGE
service/keda-metrics-apiserverClusterIP10.233.44.19443/TCP,80/TCP45s
NAMEREADYUP-TO-DATEAVAILABLEAGE
deployment.apps/keda-metrics-apiserver1/11145s
deployment.apps/keda-operator0/11045s
NAMEDESIREDCURRENTREADYAGE
replicaset.apps/keda-metrics-apiserver-7d89dbcb5411145s
replicaset.apps/keda-operator-5bb9b49d7c11045s

#kubectlgetcrd|grepkeda
clustertriggerauthentications.keda.sh2023-05-11T0906Z
scaledjobs.keda.sh2023-05-11T0907Z
scaledobjects.keda.sh2023-05-11T0907Z
triggerauthentications.keda.sh2023-05-11T0907Z

KubeSphere部署KEDA

kubectleditcc-nkubesphere-system(kubesphere3.4+)
spec:
···
autoscaling:
enabled:true
···

擴展工作負載CRD

ScaledObject對象主要定義要擴展的目標對象，如Deployment、Statefulset、CRD等，Triggers部分聲明對應的觸發(fā)器，在進行這些參數(shù)設置后，一個KEDA的自定義伸縮就可以啟用了。

apiVersion:keda.sh/v1alpha1
kind:ScaledObject
metadata:
name:{scaled-object-name}
spec:
scaleTargetRef:
apiVersion:{api-version-of-target-resource}#Optional.Default:apps/v1
kind:{kind-of-target-resource}#Optional.Default:Deployment
name:{name-of-target-resource}#Mandatory.MustbeinthesamenamespaceastheScaledObject
envSourceContainerName:{container-name}#Optional.Default:.spec.template.spec.containers[0]
pollingInterval:30#Optional.Default:30seconds
cooldownPeriod:300#Optional.Default:300seconds
idleReplicaCount:0#Optional.Default:ignored,mustbelessthanminReplicaCount
minReplicaCount:1#Optional.Default:0
maxReplicaCount:100#Optional.Default:100
fallback:#Optional.Sectiontospecifyfallbackoptions
failureThreshold:3#Mandatoryiffallbacksectionisincluded
replicas:6#Mandatoryiffallbacksectionisincluded
advanced:#Optional.Sectiontospecifyadvancedoptions
restoreToOriginalReplicaCount:true/false#Optional.Default:false
horizontalPodAutoscalerConfig:#Optional.SectiontospecifyHPArelatedoptions
name:{name-of-hpa-resource}#Optional.Default:keda-hpa-{scaled-object-name}
behavior:#Optional.UsetomodifyHPA'sscalingbehavior
scaleDown:
stabilizationWindowSeconds:300
policies:
-type:Percent
value:100
periodSeconds:15
triggers:
#{listoftriggerstoactivatescalingofthetargetresource}

Demo

KEDA目前支持53種Scalers，如Kafka，Elasticsearch，MySQL，RabbitMQ，Prometheus等等。此處演示一個Prometheus和Kafka的例子。

Prometheus & KEDA

部署一個Web應用，使用Prometheus監(jiān)控Web應用http請求指標。為尋求演示效果，此處部署了一個有點擊，互動的Demo APP，

進入KubeSphere項目，新建一個自定義伸縮：

設置最小副本數(shù)為1，最大副本數(shù)為10，輪詢間隔5秒，等待時間為1分鐘：

KubeSphere支持Cron、Prometheus，和自定義觸發(fā)器：

觸發(fā)器設置Prometheus，設置請求為30s內的增長率總和，當閾值大于3時事件驅動觸發(fā)縮放：

設置一些其他設置，如資源刪除后是否恢復指本來的副本數(shù)，以及擴縮策略設置：

現(xiàn)在并發(fā)訪問Web App：

可以在自定義監(jiān)控看到監(jiān)控指標的變化：

Web App的副本數(shù)開始橫向擴展：

最終擴展到ScaledObject中定義的10個副本：

在訪問停止后，可以看到監(jiān)控指標的數(shù)值在慢慢變?。?/p>

Deployment開始縮容：

Kafka & KEDA

KEDA使用Kafka事件源演示的整體拓撲如下：

打開KubeSphere應用商店，查看DMP數(shù)據(jù)庫中心：

選擇Kafka，進行安裝

安裝好Kafka后，創(chuàng)建一個測試的Kafka Topic，Topic分區(qū)設置為5，副本設置為1：

創(chuàng)建Kafka Producer服務：

向主題發(fā)送訂單：

創(chuàng)建Consumer服務：

發(fā)送新訂單看Consumer服務是否消費：

現(xiàn)在可以來做自動伸縮了，創(chuàng)建一個ScaledObject，設置最小副本數(shù)為0，最大為10，輪詢間隔為5s，Kafka LagThreshold為10：

apiVersion:keda.k8s.io/v1alpha1
kind:ScaledObject
metadata:
name:kafka-scaledobject
namespace:default
labels:
deploymentName:kafka-consumer-deployment#RequiredNameofthedeploymentwewanttoscale.
spec:
scaleTargetRef:
deploymentName:kafka-consumer-deployment#RequiredNameofthedeploymentwewanttoscale.
pollingInterval:5
minReplicaCount:0#OptionalDefault0
maxReplicaCount:10#OptionalDefault100
triggers:
-type:kafka
metadata:
#Required
BootstrapeServers:radondb-kafka-kafka-external-bootstrap.demo:9092#Kafkabootstrapserverhostandport
consumerGroup:order-shipper#Makesurethatthisconsumergroupnameisthesameoneastheonethatisconsumingtopics
topic:test
lagThreshold:"10"#Optional.Howmuchthestreamislaggingonthecurrentconsumergroup

創(chuàng)建自定義伸縮：

現(xiàn)在，讓我們向隊列提交大約 100,000 條訂單消息，看看自動縮放的實際效果。你會看到隨著隊列中多余消息的增長，將會產(chǎn)生更多的 kafka-consumer pod。

此處我們看到最大到5個副本，沒有到10個副本，因為默認最大副本數(shù)不會超過Kafka主題分區(qū)數(shù)量，上面設置了分區(qū)為5，可以激活allowIdleConsumers: true來禁用這個默認行為。重新編輯自定義伸縮后，最大副本變化成10：

在無消息消費時，副本變化為0：

審核編輯：劉清