挖掘Kubernetes 弹性伸缩：利用 KEDA实现基于事件驱动的自动缩放器
简介与总结
前两篇关于HPA的文章，我们了解到HPA的实现原理，通过对服务CPU的metrics的监控实现了Deployment的弹性伸缩，我们本篇文章来实现基于事件驱动的HPA，基于事件可以让HPA更“理解”业务，实现更加基于业务的弹性伸缩。接下来就让我们一探究竟吧~
KEDA是什么？
KEDA（Kube.NETes 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 这类有状态服务伸缩，如何实现伸缩过程中的数据一致性及可用性是需要各个服务需要考虑的问题，但我相信在不久的将来，有状态服务的伸缩也可以像现如今的无状态服务一样顺滑~
