开发者学堂课程【Kubernetes 云原生管理实践：课时2：Kubernetes 应用的自动水平扩容】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/293/detail/3439
课时2：Kubernetes 应用的自动水平扩容
三、KEDA
1、Kubernetes-based Event Driven Autoscaler扩展原生HPA，对于原生的hpa的扩展，基于原生的hpa，它的api基于hpa的api，但是它进行扩展，很多业务比较复杂，扩缩容的原理或者原则不是靠cpu或者靠内存可以解决，比如有些应用，它用义务通信的方式，用反应式的编程，cpu或者在内存上看不出它有多大的变化，但是它在响应的速度和时间上会有很大的差异，在这种环境下用原生的hpa肯定不够。
2、例子是普罗米修斯所收集的数据进行采样，它设置策略进行扩容，只是把它作为使用的范例，如何把它的scaler作为oam的trait用，把它绑定到应用上，操作或者运用定义的方式跟传统的或者经常看到complice定义或者介绍有巨大的不同。
demo演示的步骤。
##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
kubect1 exec --stdin --tty front-end-xxxxx -- /bin/bash
curl -O hey https:/ 1 storage . googleapis . com/ hey-release/hey linux_ amd64 && chmod a+x hey
./hey -n 2000 http:/ /go-prom-app-v1 : 8080/test
kubectl get pods -W
4、minikube用任何集群都可以，只要是标准的集群即可，只要是hotel命令都可以，安装Keda。Keda是Kubernetes Event-driven Autoscaling业务会产生流量，事件驱动的流量，根据事件驱动进行扩容，道理很简单，关键是生态的建设，Keda想的很好，包括整个微软开源的整个思路，做building block，做很多小的组件，让大家用，跟oam的设计非常契合，oam希望有很多的trait，应用的组件上面，用这种方式扩展云原生的功能和能力，整个的社区基于流量事件进行鉴定。
装好Keda后，安装oam有两步，创建namespace，再安装oam，runtime 大项目叫crossplane，oam是在它下面的实现，因为crossplane项目是自发提出对oam的概念进行实现，慢慢跟微软一起加入，把标准实现出来，所以现在oam和runtime是在crossplane的项目占一部分。可以把runtime想成这stk，在stk的基础上也开发新的功能，这些应用和组件在oam的项目下，不是crossplane下面。安装普罗米修斯，在云上有各种不同的版本，这次用的是比较基础，但是为项目定制的。
apiVersion: core. oam. dev/v1alpha2
kind: TraitDefinition 定义
metadata :
name :
sca ledobjects. keda.k8s. io
spec :
definitionRef:
name: scaledobjects. keda.k8s. io 名字
演示是搬过来的，没有进行任何的改造，Trait 标准化是有要求的，按照oam的规范开发Trait，用户的信用各方面都会好很多，但是为保证 Trait能够最大化的兼容，现在已有的这些cid，也有照搬的能力，硬搬过来，component在文件里面，先定义containerizedwo rkloads，把deployment跟service放在一起，不用写两遍，写两遍很麻烦，定义component，引用kind类型containerizedwo rkload，只有业务代码所关心的部分，component定义跟ppt中相比简单很多，名字只用一次。绑在一起的，componentname名字就是go-prom-app-v1名字，把trait放在下面，把定义拉过来，效果不好，但是好用，如果东西是经过改造的，经过包装，所以声明的东西就不需要了，剩下核心的部分spec部分，策略会留下来。
声明kubectl apply -f Components/ go-prom. yaml
kubectl apply -f definitions /kedahpa . yaml
定义kubectl apply -f appconfig demo1 ·yaml
workload包含两部分，deployment和service，可以看到go-prom-app-v1-5b5d4bbbc4-xvwv8和go-prom-app-v1，
查看hori zontalpodautoscaler. autoscaling/ keda-hpa-go-prom-app-v1
因为现在没有流量，所以只是起来了，查看hpa，可以看到keda-hpa-go-prom-app-v1符合hpa的api，只是注册，没有真的逻辑，真正的业务逻辑在describe hori zontalpodautoscaler . autoscaling/keda-hp中，这是基本的情况，加流量，用另外容器进行操作，用kubectl apply - f frontend. yaml在集群里面，一般看到实验里面都会创建ingress，但是很多时候应用并不是一定非有这些东西，做演示的软件往往为了显示自己的功能，它会把所有的东西都给拉满，但是实际上应用时并没有这么多的东西，在这种情况下是尽量的缩减，这是非常简单的例子，进入kubect1 exec --stdin --tty front-end-xxxxx -- /bin/bash，进来之后下载工具hey，在短期内会产生流量，
curl -O hey https:/ 1 storage . googleapis . com/
hey-release/hey linux_ amd64 && chmod a+x hey
对hey进行操作，
./hey -n 2000 http:/ /go-prom-app-v1 : 8080/test
可以看到已经对流量起到反应，
开始不停的往上扩容，本身应用是预料之中的，因为keda项目已经测试过，不是测扩容和缩容，主要用oam，component方式进行扩容和缩容，比传统的以平台或者以集群为中心的角度出发去做事情容易很多，这是主要的信息。
