开发者学堂课程【通过 Knative 轻松实现应用 Serverless 化交付：Knative 灰度发布和自动弹性】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/753/detail/13228
Knative 灰度发布和自动弹性
内容介绍：
五、KPA 的纵横实现
六、自动弹性-HPA
七、自动弹性-自定义扩缩容插件
八、示例演示
九、总结
五、KPA的纵横实现
//通过三横两纵，来分析 KPA 的实现机制。三横：首先 KPA 控制器，通过 revision创建 Pod，在 KPA 控制器上主要包括两个资源，decider 以及 metric，以及Scale，首先介绍这两个资源，decider 是做扩缩容角色的资源，通过 decider获取扩缩容 pod，metric 主要采集指标的资源，通过 metric 采集到 pod 指标，Scale根据扩缩容的最小实例数，最大实例数，确定最终要扩容的pod实例数，修改deployment 的值，最终实现 pod 的扩缩容。第二横，根据指标计算 pod 数，关于 decider 的故事，decider 创建之后会创建一个定时器，该定时器会默认间隔两秒，计算 pod 的指标。指标是如何获取的呢？涉及第三行，指标采集，通过两种方式收集 pod 的指标，一是 push 指标收集，通过暴露指标接口，向外部服务如Activator 调用接口，直接推送信息。二是 pull 获得指标，允许相关的指标进行收集。接下来说两纵，第一纵可以认为是零到一的扩容，第一步会进行指标采集，在pod 数为零的时候，流量请求通过为模式，这时候流量通过 autoscaler 进行接管，在 autoscaler 中会根据请求的指标信息，调用相关的 KPA 指标接口，将指标信息发送给 KPA，第二步，根据指标计算 pod 数，修改 decider 中相应的 pod 值，触发进行重新调和，最后进行扩容。在 KPA 指标中，调和的方法，通过对 Revision 执行 scale 进行扩容，扩容完成之后，切换成模式，最终实现零到一的扩容操作。第二纵，一到 n 的扩容，第一步采集指标，获取相应的指标信息，第二步计算相应的 pod 数，拿到指标信息后，计算 pod 数，同样修改 decider 期望值，最后也是进行一步相应的扩容操作，在 KPA 中重新调整信息，最终实现一到 n 的扩容操作，这就是通过纵横实现 KPA 机制。
六、自动弹性-HPA
//利用 HPA 通过检测到 number 的使用率，修改相应数量进行扩容，设置 cpu 和 number 的指标信息，这里不做过多解读。
七、自动弹性-自定义扩缩容插件
//接下来介绍如何自定义扩缩容插件，除了 KPA 和 HPA，在实际运用中会遇到不同的指标收集扩缩容策略，这时候需要自定义一个扩缩容插件，Knative 中天然提供插件机制，需要做扩缩容操作，或者定义扩缩容组件的话，如何进行？关键两点，只需要指标采集，然后调整 Pod 实例数，修改相应的信息，最终实现自定义扩缩容能力。
八、示例演示
·灰度发布
·自动扩缩容
//分别介绍灰度发布和自动扩缩容的实例，接下来进行演示。首先演示下灰度发布，这里会创建两个实例，分别对应 ve 和 vr 版本，ve 版本会打印一个 hello coffee ve，在 vr 版本打印 hello coffee vr 。首先创建 ve 版本的 coffee，创建完成后观察下 pod 的启动情况，可以看到 pod 在启动中，启动完服务后可以进行访问，访问当前的服务是否是 ve 版本，可以看到当前是ve版本的打印，接下来做一次版本的变更，变成 vr 版本，首先看当前 Revision 的名称，对相应的 Revision 做一个流量比例的设置，然后进行 vr 版本的创建，同时对 vr 版本和 ve 版本设置不同的流量比例。把新的版本做一次变更，新的 vr 版本创建完可以看到 vr 版本的 pod 开始启动，访问之后，通过保留实例，创建一个正常的实例出来。可以看到 ve vr 版本出现了，以50%的比例出现，发现当前比例没有问题，那么将比例调整到100%，把新的 vr 版本调成100%，可以观察一下流量的情况，只需要改一下 traffic 的值，新的版本改成100%，原来版本设置为零，发现都会打到 vr 版本上去，这就是灰度发布的流程。接下来会做一个压测，看一下当前 KPA 的扩缩容能力，当前默认基于流量的 KPA 策略，可以看到新的 vr 版本已经创建出来。演示到此结束。
九、总结
//今天讲了基于流量的灰度发布以及自动弹性，自动弹性介绍了 Knative 基于流量请求的 KPA 以及 HPA ，同时也介绍了如何扩展自定义扩缩容的插件。
