應用現代化中的彈性伸縮

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

為什么需要彈性伸縮呢？

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

?提高資源利用率：根據實際資源負載動態調整資源規模，避免基礎設施資源浪費，降低TCO。

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

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

Horizontal Pod Autoscaling

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

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

由上圖看出，HPA持續監控Metrics-Server的指標情況，然后計算所需的副本數動態調整資源副本，實現設置目標資源值的水平伸縮。

但也有一定局限性：

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

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

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

KEDA

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

架構

KEDA自身有幾個組件：

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

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

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

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

? Scalers: 監視事件源，獲取指標并根據事件觸發伸縮。

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

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

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

CRD

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

? ScaledJobs：事件源和Kubernetes Jobs之間的映射。根據事件觸發調整Job規模。

? TriggerAuthentications：觸發器的認證參數

? 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部分聲明對應的觸發器，在進行這些參數設置后，一個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監控Web應用http請求指標。為尋求演示效果，此處部署了一個有點擊，互動的Demo APP，

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

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

KubeSphere支持Cron、Prometheus，和自定義觸發器：

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

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

現在并發訪問Web App：

可以在自定義監控看到監控指標的變化：

Web App的副本數開始橫向擴展：

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

在訪問停止后，可以看到監控指標的數值在慢慢變小：

Deployment開始縮容：

Kafka & KEDA

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

打開KubeSphere應用商店，查看DMP數據庫中心：

選擇Kafka，進行安裝

安裝好Kafka后，創建一個測試的Kafka Topic，Topic分區設置為5，副本設置為1：

創建Kafka Producer服務：

向主題發送訂單：

創建Consumer服務：

發送新訂單看Consumer服務是否消費：

現在可以來做自動伸縮了，創建一個ScaledObject，設置最小副本數為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

創建自定義伸縮：

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

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

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

審核編輯：劉清