开发者学堂课程【Kubernetes 云原生管理实践：Kubernetes 应用的自动水平扩容】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/751/detail/13221
Kubernetes 应用的自动水平扩容
内容介绍：
二、KEDA 的介绍
二、KEDA 的介绍
1、微软做的一个开源项目叫做 KEDA。KEDA 是 Kubernetes-based Event Driver Autoscaler，是对原生 HPA 的扩展，是基于原生 HPA，API 还是符合 HPA 的 API 的。但是他进行了扩展，为什么进行扩展？是因为很多业务比较复杂，扩缩容的原理或原则不是靠 CPU，或者是靠内存可以解决的。比如说有些应用，用义务通信的方式，反应式的编辑造成了他本身的 CPU、内存上面看不出来它有多大的变化，但是他响应的速度和时间会有很大的差异。在这种情况下，用原生的 HPA 是不够的。
2、例子用的是在 scaler 里面有一个，基于普罗米修斯收集应用。
这是普罗米修斯可收集的一些数据，进行采样，然后设置一些策略进行扩容。怎么把 scaler 作为 OAM 的 trait 用，把它绑定到应用上。在这个过程中，这种操作或这种应用定义的方式，跟传统的或经常看到的 Kubernetes 对于应用的定义或者介绍是有巨大的不同的。例子如下。
3、##Install Keda
helm install keda keda/keda
##Install OAM
kubectl create namespace oam-system
helm install oam--namespace oam-system crossplane-master/oam-kubernetes-runtime--devel
##Install prometheus
kubectl apply-f prometheus. yaml
##Create application
kubectl apply-f Components/go-prom. yaml
kubectl apply-f definitions/kedahpa. yaml
kubectl apply-f appconfig/demo1. yaml
##Generate load
kubectl apply-f frontend. yaml
kubectl exec--stdin--tty front-end-xxxxx--/bin/bash
curl-o hey https://storage.googleapis.com/hey-release/hey _ linux _ and 64&&chmod a+x hey ./hey-n 2000 http://go-prom-app-v1:8080/test
kubect1 get pods-w
第一步装 keda，然后装 oam。这有一个 minikube，可以用任何集群，只要是标准的 Kubernetes 集群。在安装过程中看一下 keda 项目，项目叫 Event – driven。
业务会产生一些事件驱动的流量，根据事件的驱动来进行扩缩容，道理很简单，关键是生态的建设。keda 做很多小的组件，给用户使用，这与 OAM 的设计是非常契合的。OAM 希望大家有自己的 trait，绑定到应用的组件上，用这种方式扩展云原生的功能和能力。keda 社区有很多 scaler，基于流量事件来进行监听。
4、keda 安装完成，下一步装 OAM ，OAM分两步，第一步是创建一个 namespace。有一个 runtime，大项目叫 crossplane，crossplan 是 CNCF 里面的 send box。OAM是在 crossplane 下的实现。crossplane 最早提出对 OAM 概念进行实现，OAM 现在是 crossplane 的一部分。大家可以吧 runtime 想成 SDK，在 SDK 的基础上开发一些新的功能，这些应用和组件在 OAM 的项目下，不是在 crossplane 的下。现在 OAM 的 runtime 也部署完成，接下来安装 prometheus，prometheus 在云上有各种不同的版本，我们使用的是比较基础、为这个项目定制的版本。下一步安装 components 和 trait definition。
这是 KEDA 的 CRD，他的名字叫 scaledobjects.keda ，给它定义了一个 trait。给大家演示的例子相当于是搬运来的，没有进行任何改造。trait 在定义上有一定要求，一般要按照 OAM 的规范开发 trait，用户的清澈度各方面都会好很多。但是为了保证 trait 最大化的兼容，已有的 CRD，也有照搬的能力。
5、component 在这个文件里，我把两个放在了一起，一个是先定义 workload，定义 containerizedworkload，就是把 deployment 和 service 放在一起，这样就不用写两遍了，写两遍很麻烦，这两个放在一起是非常好的。
定义 containerizedworkload 以后，下面定义 component。Components 引用他的 kind，类型是 containerizedworkload，在 spec 定义下，只有业务代码关心的内容。
spec:
containers:
-name:go-prom-app
image:szihai/okod:v1
imagePullPolicy:Always
ports:
-name:http
containerPort: 8080
其他运维的内容没有写在这里，跟 deployment 相比， components 定义简单很多。名字 go-prom-app-v1 只用了一次，这个也很重要，如果名字对不上，是一件很麻烦的事情。这就是 trait 跟 component 这两部分。
6、下一步是把他们绑在一起，Components 名字是 go-prom-app-v1 ，定义完以后，把 trait 放在下面，trait 有好几个，不只是一个，下面是他的定义。
traits:
-trait:
apiVersion:keda.k8s. io/v1alpha1
kind:Scaled0bject
metadata:
name:prometheus-scaledobject
namespace:default
labels:
deploymentName:go-prom-app-v1
因为这个定义是搬运过来的，效果不是很好，如果他经过改造或包装，声明的内容可以都不要了。只剩下核心的 spec 这部分。
这部分是策略，是没办法舍弃的。先声明一下 components 和 trait，接下来再来定义应用 demo1。Workload 包括两部分 deployment 和 Service，因为现在没有流量，他只是创建完成了。keda 的 abletoscale 也是符合 HPA 的 API 的，
但他只是注册上去，并没有逻辑，真正的业务逻辑是在这个 CRD 运行，这就是基本的情况。
7、接下来加载流量，用另外一个容器进行操作。有一个叫做 fronted 的小容器，在集群里面操作。为什么用这种方式？实验里面都会创建一个 ingress 等，但很多时候，应用并不一定非有这些东西，做演示的那些软件往往为了显示自己的功能，会把所有的东西拉满，但实际应用的时候没有这么多东西，在这种情况下尽量缩减。这是非常简单的例子，现在进入 forn- end 里面，把ID 7b949dd5f4-bnt7s 复制进去。进来以后需要下载一个工具叫 hey，他会在短期内产生流量，接下来用 hey 对它进行操作。启用之后它会不断地对流量进行扩容。
keda 这个项目已经测试过，不是测扩容和缩容这件事，
以上内容主要是用 OAM，用 touch、trait、component 的方式来进行扩容或缩容，比传统的以平台或集群的角度来做这件事情容易很多。
