开发者学堂课程【如何通过 Knative 轻松实现应用 Serverless 化交付： Knative 灰度发布和自动弹性（一）】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/291/detail/3434
Knative 灰度发布和自动弹性（一）
内容介绍
一.前言
二.service 服务的生命周期
三.基于流量的灰度发布的做法
四.自动弹性
五.KPA 的纵横机制
六.自动弹性 HPA
七.如何自定义扩缩容插件
八.实例演示
九.总结
一、前言
Connective 的冷启动，是社区的 connective 从0~1冷启动的问题，主要是由于电路过长，请求延迟的原因。
另外pod的启动也很耗时。针对这些问题，使用保留实例，平衡成本的方法解决冷启动的问题，
二、service 服务的生命周期
作为 Service 的 Route，就离不开按需分配资源的能力。Connective 提供了基于流量的自动扩容能力，可以根据应用的请求，在高峰时刻自动控融实例，暂流量减少时自动缩容。此外肯 Connective 还提供了基于流量的灰度发布能力,可以根据流量百分比进行灰度发布。
service 是直接面向开发者操作的资源对象，负责对 route 和 configuration 进行管控，一个 service 分别对应一个 Route 和一个 configuration。
每次 service 变化需要创建新的 word 的就会更新，然后每次更新都会创建一个唯一的 revision，configuration 可以认为是版本控制器，负责管理多个 revision 版本，Route 主要负责流量管理，控制流量分发到不同的人物身上，并且支持按照百分比进行流量分发。可以通过在 traffic 中对不同的设置不同流量比例即可控制流量分发。例如可以对一个新的 revision，设置90%,revision,通过 revision 可以实现历史版本追踪，以及灰度发布过程中进行回轨等操作。
三、基于流量的灰度发布的做法
假如一开始创建了个 v 版本的 revolution，这时候如果有新的版本变更，那么只需要更新 surface 中的 congratulation，就可以创建出v2版本。
然后可以通过route对v1，v2是指不同流量的比例灰度，这里v1是70%，v2是30%，那么流量会按照7:3这个比例分发到这两个版本上，一旦新的v2版本验证没有问题，接下来就可以通过调整流量比例，继续灰度，直到新版本 VR 达到100%。在这个灰度过程中，一旦发现新版本有异常，可以调整通过调整流量比例进行回归操作。除此之外，可以打一个 tag，通过tag的URL进行单独对 revision 版本进行测试，这个测试过程不会影响对正常流量的访问。
四、自动弹性
Knative 提供基于流量的自动扩容 KPA 的能力，以及基于 CPU 和 memory 的 HPAA 的弹性能力。除此以外，Connective 还提供了弹性的扩展能力。可以基于不同的指标，自定义弹性的实现。设备中，默认使用 KPA 上图，就展示了 Connective outset 的一个工作机制。Route 负责接入流量,Activator 负责做弹性的一个伸缩。当没有业务请求的时候会诉讼到0，诉讼到0后，Route 进来的请求会转到 activity 的上。
当第一个请求进来之后，activity 会保持住当前的链接，然后通知Activator来迅速扩容，Activator 会把第一个 pod 控制完成之后，等当前的 pod ready， outset,activity 会把相应的流量转发到这些 ready 的 pod 上，从而做到了诉讼到0也不会损失流量的目的。当后续有流量进来以后，流量会直接到 Route 到 pod 上，这时候 outset 会直接采用 put 中的指标，根据这个指标进行一到n的扩缩容操作。
五、KPA 的纵横机制
第一行 KPA 控制器，在 KPA 主要包括两个资源，Decider 等于以及 metiric CRD 以及一个 Scale 的操作。
通过 Decider 获取扩速融,minister 主要采集指标的一些资源，通过 mutual 会采集到pod指标。
第二行根据指标计算 pod，Decider 创建之后会创建出来一个定时器，该定时器会默认间隔两秒，然后计算 pod 的指标，那么这个指标是如何获取的，这就涉及到第三行指标采集，这里是通过两种方式收集 pod 的指标。一是 POS 指标收集，这里通过暴露指标接口，向外部服务，如 Activator 可以调用该接口，直接推送密推和信息。第二是拉获取指标，通过服务接口，遵循相关的指标进行收集。
第一纵可以认为是0~1的扩容，第一步会进行指标采集，在 put 数为0的时候，流量请求通过为 pod 模式，这时候流量是通过 Activator 的进行接管的，在 Activator 中会根据请求的指标信息，调用相关的 KPA 提供的指标接口，将指标信息发送给 KPA 中的 controller。第二步，根据指标计算 pod 数，根据 POS 或者的指标数计算出期望的 pod 得数，然后修改第四个期望的相应的 pod 值，然后触发,做重新的一个调和，最后进行扩容。在 KPA control 中会执行调和的方法,通过对当前 revision 执行 Scale 进行扩容完成之后，然后切换成一个 Scale 模式，这就是最终实现了一个0~1的扩容操作。
然后第二纵是一到 n 的扩容，第一步采集指标，但是这里是通过 pod 的方式，所有的 pod 的 pass9090端口，然后获取相应的指标信息。第二步计算指标计相应的pod数，这个拿到指标信息之后，可以计算出期望的 pod 数，同样的修改 Decider 的期望值，然后最后也是进行一步相应的扩容操作,重新调和相应的 revision 信息，然后最终实现一到 n 的一个扩容操作。
这就是介绍的一个通过纵横方式分析了一下 KPA 的一个实现机制
