挖掘Kubernetes 彈性伸縮：利用 KEDA實現基于事件驅動的自動縮放器
作者：Willie
在本文中，我們利用KADA實現了基于事件的彈性伸縮，更加緊密的擁抱業務，基于服務的“事件”實現伸縮，使得伸縮更加合理，高效。但事實上，針對像Mysql 這類有狀態服務伸縮，如何實現伸縮過程中的數據一致性及可用性是需要各個服務需要考慮的問題，但我相信在不久的將來，有狀態服務的伸縮也可以像現如今的無狀態服務一樣順滑。
簡介與總結
前兩篇關于HPA的文章，我們了解到HPA的實現原理，通過對服務CPU的metrics的監控實現了Deployment的彈性伸縮，我們本篇文章來實現基于事件驅動的HPA，基于事件可以讓HPA更“理解”業務，實現更加基于業務的彈性伸縮。接下來就讓我們一探究竟吧~
KEDA是什么？
KEDA（Kubernetes Event-driven Autoscaling）是云原生計算基金會孵化項目，是一個Kubernetes基于事件驅動的自動縮放器。借助 KEDA，可以根據需要處理的事件數量來驅動 Kubernetes 中任何容器的擴展。KEDA是一個單一用途的輕量級組件，可以部署到任何 Kubernetes 集群中。KEDA 與標準 Kubernetes 組件（例如Horizontal Pod Autoscaler）一起可以擴展K8S功能。借助 KEDA，您可以明確映射要使用事件驅動規模的應用程序，而其他應用程序繼續運行。這讓 KEDA 成為一個靈活且安全的選項，可以與任意數量的任何其他 Kubernetes 應用程序或框架一起運行。下圖展示了 KEDA 如何與 Kubernetes Horizontal Pod Autoscaler、外部事件源和 Kubernetes 的etcd結合使用數據存儲：
圖片
概述: KEDA 使用三個組件來完成其任務：
- Scaler：連接到外部服務（例如，MYsql）并獲取指標（例如，表的數據量）
- Operator（代理）：負責“激活”一個 Deployment/Stafulset 并創建一個 Horizontal Pod Autoscaler 對象
- Metrics Adapter：將來自外部源的指標呈現給 Horizontal Pod Autoscaler KEDA Operator 由一個控制器組成，該控制器實現“協調循環”，并充當激活和停用部署以從零擴展或從零擴展的代理。這是由安裝 KEDA 時運行的 KEDA-operator 容器實現的。ScaledObject它通過創建(HPA)對資源的創建做出“反應”并創建Horizontal Pod Autoscaler。
看到這里就大致了解到了KEDA的主要工作是通過獲取各個服務具體的“指標”暴露給HPA以實現彈性擴展。
最佳實踐
描述
上面了解到了KEDA的架構，我們接下來通過安裝Mysql和KEDA，然后創建一個自定義資源 ScaledObject實現對Mysql"事件"的監控，并將指標暴露給HPA，以實現彈性伸縮，接下來就動手試試吧~
安裝KEDA
在K8S集群中部署KEDA，因為我的K8S的版本是1.23，安裝KEDA2.9版本（具體版本配套關系詳見官網keda.sh：
#Including admission webhooks
#kubectl apply --server-side -f https://github.com/kedacore/keda/releases/download/v2.9.3/keda-2.9.3.yaml查看keda 狀態
# kubectl get po -n keda
NAME READY STATUS RESTARTS AGE
keda-admission-webhooks-5f7cdd4745-7zhxn 1/1 Running 0 4d9h
keda-metrics-apiserver-5c55d5d55f-gwv29 1/1 Running 0 4d9h
keda-operator-c8d6bd9bb-ct978 1/1 Running 0 4d9h
keda-operator-metrics-apiserver-769bb99569-knh7g 1/1 Running 0 4d9h安裝Mysql
# helm repo add bitnami https://charts.bitnami.com/bitnami
#helm pull bitnami/mysql
#tar -xf mysql-9.3.3.tgz
#vim mysql/value.yaml
global:
imageRegistry: ""
## E.g.
## imagePullSecrets:
## - myRegistryKeySecretName
##
imagePullSecrets: []
storageClass: "nfs-storage" ##配置自己的存儲配置，其余可暫不配置
# 開始安裝mysql
#helm install mysql ./mysql -n mysql --create-namespace
# kubectl get po -n mysql
NAME READY STATUS RESTARTS AGE
mysql-0 1/1 Running 1 (5h29m ago) 5h31m創建ScaledObject
（詳細描述可參考鏈接）
# cat mysql-example.yaml
apiVersion: v1
kind: Secret
metadata:
name: mysql-secrets
namespace: mysql
type: Opaque
data:
mysql_conn_str: cm9vdDptcXZkRmFtUWlXQHRjcChteXNxbC5teXNxbC5zdmMuY2x1c3Rlci5sb2NhbDozMzA2KS90ZXN0X2Ri # mysql的connectionString格式 user:password@tcp(mysql:3306)/stats_db base64編碼值
---
apiVersion: keda.sh/v1alpha1
kind: TriggerAuthentication
metadata:
name: keda-trigger-auth-mysql-secret
namespace: mysql
spec:
secretTargetRef:
- parameter: connectionString
name: mysql-secrets
key: mysql_conn_str
---
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
name: mysql-scaledobject
namespace: mysql
spec:
scaleTargetRef:
kind: statefulset #擴容的控制器的類型，默認是deployment
name: mysql
triggers:
- type: mysql
metadata:
queryValue: "4" #在 HPA 中用作targetValue或targetAverageValue（取決于觸發指標類型）的閾值。（這個值可以是浮點數）
query: "SELECT COUNT(*) FROM test;" #應返回單個數值的 MySQL 查詢，此為本次測試的enent
authenticationRef:
name: keda-trigger-auth-mysql-secret
#創建ScaledObject
#kubectl apply -f mysql-example.yaml
#查看ScaledObject
# kubectl get scaledobject -n mysql
NAME SCALETARGETKIND SCALETARGETNAME MIN MAX TRIGGERS AUTHENTICATION READY ACTIVE FALLBACK AGE
mysql-scaledobject apps/v1.statefulset mysql mysql keda-trigger-auth-mysql-secret True True False 4h54m
#同時也會創建HPA
# kubectl get hpa -n mysql
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
keda-hpa-mysql-scaledobject statefulset/mysql 3/4 (avg) 1 100 1 4h54m測試
上面的配置中我們以test表中的行數作為"事件"，并且閾值為4
#select * from test;
+----+------------+-----------+------------+-------------------+------+----------+
| id | created_at | update_at | panel_name | link | icon | tag_name |
+----+------------+-----------+------------+-------------------+------+----------+
| 6 | NULL | NULL | kubesre | www.kubesre.com/ | ECS | |
| 7 | NULL | NULL | kubesre | www.kubesre.com/ | ECS | |
| 8 | NULL | NULL | kubesre | www.kubesre.com/ | ECS | |
+----+------------+-----------+------------+-------------------+------+----------+
#添加數據
mysql> INSERT INTO `test` VALUES (1, NULL, NULL, 'kubesre', 'www.kubesre.com/', 'ECS', '');
Query OK, 1 row affected (0.01 sec)
mysql> INSERT INTO `test` VALUES (2, NULL, NULL, 'kubesre', 'www.kubesre.com/', 'ECS', '');
Query OK, 1 row affected (0.01 sec)
mysql> INSERT INTO `test` VALUES (3, NULL, NULL, 'kubesre', 'www.kubesre.com/', 'ECS', '');
Query OK, 1 row affected (0.00 sec)
mysql> INSERT INTO `test` VALUES (4, NULL, NULL, 'kubesre', 'www.kubesre.com/', 'ECS', '');
Query OK, 1 row affected (0.01 sec)
mysql> INSERT INTO `test` VALUES (5, NULL, NULL, 'kubesre', 'www.kubesre.com/', 'ECS', 'Pod');
Query OK, 1 row affected (0.00 sec)
mysql> select * from test;
+----+------------+-----------+------------+-------------------+------+----------+
| id | created_at | update_at | panel_name | link | icon | tag_name |
+----+------------+-----------+------------+-------------------+------+----------+
| 1 | NULL | NULL | kubesre | www.kubesre.com/ | ECS | |
| 2 | NULL | NULL | kubesre | www.kubesre.com/ | ECS | |
| 3 | NULL | NULL | kubesre | www.kubesre.com/ | ECS | |
| 4 | NULL | NULL | kubesre | www.kubesre.com/ | ECS | |
| 5 | NULL | NULL | kubesre | www.kubesre.com/ | ECS | Pod |
| 6 | NULL | NULL | kubesre | www.kubesre.com/ | ECS | |
| 7 | NULL | NULL | kubesre | www.kubesre.com/ | ECS | |
| 8 | NULL | NULL | kubesre | www.kubesre.com/ | ECS | |
+----+------------+-----------+------------+-------------------+------+----------+
# kubectl get hpa -n mysql
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
keda-hpa-mysql-scaledobject statefulset/mysql 4/4 (avg) 1 100 2 4h56m
# kubectl get po -n mysql
NAME READY STATUS RESTARTS AGE
mysql-0 1/1 Running 1 (5h45m ago) 5h47m
mysql-1 0/1 Running 0 55s
由于我集群本身的原因，mysql-1 沒有起來，但是我們看到了今天實驗目的已經成功結論
在本文中，我們利用KADA實現了基于事件的彈性伸縮，更加緊密的擁抱業務，基于服務的“事件”實現伸縮，使得伸縮更加合理，高效。但事實上，針對像Mysql 這類有狀態服務伸縮，如何實現伸縮過程中的數據一致性及可用性是需要各個服務需要考慮的問題，但我相信在不久的將來，有狀態服務的伸縮也可以像現如今的無狀態服務一樣順滑~
責任編輯：武曉燕
來源：
云原生運維圈
