开发者学堂课程【通过 Knative 轻松实现应用 Serverless 化交付：Knative 灰度发布和自动弹性】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/753/detail/13228
Knative 灰度发布和自动弹性
内容介绍：
一、上期回顾
二、Service 生命周期
三、基于流量的灰度发布
四、自动弹性—KPA
一、上期回顾
Knative 冷启动
1.当前社区 Knative 0到1冷启动问题
//主要是由于电路过长，请求延迟，另外，Pod 启动也很耗时，针对这些问题，使用保留实例平衡成本和冷启动
2.使用保留实例平衡成本和冷启动
二、Service 生命周期
Service
·直接面向开发者操作的资源对象
·Route:Configuration=1:1
apiversion:servingknativedev/v1
kind:Service metadata:
name:coffee
spec:
template:
spec:
containers:
-image:registry.cn-hangzhou.aliyuncs.com/knative-sample/helloworld-qo:160e4dc8
env:
name: TARGET
value:"coffee"
//Knative 提供了基于流量的自动扩容能力，可以根据应用的请求，在高峰时刻，自动扩容实例，在流量减少时自动缩容。此外，Knative 还提供了根据流量自动发布能力，可以根据流量百分比进行灰度发布，在介绍之前，首先深入分析 Service 服务的生命周期，Knative Service 是直接面向开发者操作的资源对象，他负责对 Route 和 Configuration 进行管控，一个 Service 分别对应一个 Route 和 Configuration。每次更新 Configuration 都会创建新的 Revision，每次 Configuration 更新都会创建唯一的 Revision，Configuration 可以认为是版本控制器，负责管理多个 Revision 版本。Route 主要负责 Configuration 的流量管理，控制流量分发到不同的 Revision 上，支持按照百分比进行流量分发，这里可以通过不同的 traffic 对不同的 Revision，不同流量比例控制流量分发。例如，可以对一个新的 Revision 设置90%，原有的 Revision 不会立刻下掉10%进行比例控制，一个Revision 可以认为是一个 Configuration 的快照，通过 Revision 可以进行版本追踪以及回滚。
三、基于流量的灰度发布
//通过上面已经对 Knative Service 模型有了深入了解，假如一开始创建了VE版本的 Revision，这时候有新的版本的变更，那么只需要更新 Service 中的 Configuration 就可以创建出 vr 版本，然后可以通过 Route 对 vr 设置不同流量的比例灰度。这里 ve 是70%，vr 是30%，那么流量会按照7：3这个比例分发到这两个排名上。一旦新的 vr 版本验证没有问题，接下来就可以调整流量比例继续灰度，直到新版本vr达到100%，在这个灰度过程中，一旦发现新版本有异常，可以调整流量比例进行回归操作。除此之外，可以在 Route 的 traffic 中对 Revision 打一个 tag，打完 tag 的 Revision 可以通过 tag 的 url 进行单独测试，测试过程不会对正常流量防卫。
四、自动弹性—KPA
//KnativePod 提供基于流量的自动扩容 KPA 的能力，以及基于 cpu 和 number 的HPA 的弹性能力，Knative 还提供了弹性的扩展能力，基于不同的指标，自定义弹性的实现。
//Knative Service 默认使用 KPA，上图展示了 Knative 的工作机制，route 负责接入流量，当没有业务请求时缩用到零，缩用到零后 route 接入的请求会转到 Activator 上，当第一个请求进来之后，Activator 会保持住当前的链接。然后通知Autoscaler 去做扩容。Autoscaler 把第一个扩容完成之后，当前的 Pod ready，然后 Activator 把相应的流量转发 Pod 上，从而做到缩用到零也不会损失流量的目的，当后续有流量进来以后，流量会直接到 Pod 上，这时候会直接采用 Pod 指标，根据这个指标进行1到N的扩缩容操作。
