knative系列(Knative入门系列6：Knative的使用)
一、【Knative系列】理解 Knative Serving扩缩容系统的设计
Knative Serving是 Knative系统的核心，而理解 Knative Serving系统内的组件能更容易了理解 Knative Serving系统的实现：
了解其中的控制流和数据流的走向，了解其在扩缩容过程中的作用。因篇幅有限，这里只对组件进行简要描述，后续会针对每个组件进行详细的单独讲解。
queue-proxy是一个伴随着用户容器运行的 Sidecar容器，跟用户容器运行在同一个 Pod中。每个请求到达业务容器之前都会经过 queue-proxy容器，
这也是它问什么叫 proxy的原因。
queue-proxy的主要作用是统计和限制到达业务容器的请求并发量，当对一个 Revision设置了并发量之后（比如设置了5）， queue-proxy会确保不会同时有超过5个请求打到业务容器。当有超过5个请求到来时， queue-proxy会先把请求暂存在自己的队列 queue里，（这也是为什么名字里有个 queue的缘故）。 queue-proxy同时会统计进来的请求量，同时会通过指定端口提供平均并发量和 rps（每秒请求量）的查询。
Autoscaler是 Knative Serving系统中一个重要的 pod，它由三部分组成：
PodAutoscaler reconciler会监测 PodAutoscaler（KPA）的变更，然后交由 Collector和 Decider处理
Collector主要负责从应用的 queue-proxy那里收集指标， Collector会收集每个实例的指标，然后汇总得到整个系统的指标。为了实现扩缩容，会搜集所有应用实例的样本，并将收集到的样本反映到整个集群。
Decider得到指标之后，来决定多少个Pod被扩容出来。简单的计算公式如下：
另外，扩缩容的量也会受到 Revision中最大最小实例数的限制。同时 Autoscaler还会计算当前系统中剩余多少突发请求容量（可扩缩容多少实例）进来决定请求是否走 Activator转发。
Activator是整个系统中所用应用共享的一个组件，是可以扩缩容的，主要目的是缓存请求并给 Autoscaler主动上报请求指标
Activator主要作用在从零启动和缩容到零的过程，能根据请求量来对请求进行负载均衡。当 revision缩容到零之后，请求先经过 Activator而不是直接到 revision。当请求到达时， Activator会缓存这这些请求，同时携带请求指标（请求并发数）去触发 Autoscaler扩容实例，当实例 ready后， Activator才会将请求从缓存中取出来转发出去。同时为了避免后端的实例过载， Activator还会充当一个负载均衡器的作用，根据请求量决定转发到哪个实例（通过将请求分发到后端所有的Pod上，而不是他们超过设置的负载并发量）。 Knative Serving会根据不同的情况来决定是否让请求经过 Activator，当一个应用系统中有足够多的pod实例时， Activator将不再担任代理转发角色，请求会直接打到 revision来降低网络性能开销。
跟 queue-proxy不同， Activator是通过 websocket主动上报指标给 Autoscaler，这种设计当然是为了应用实例尽可能快的冷启动。 queue-proxy是被动的拉取： Autoscaler去 queue-proxy指定端口拉取指标。
API: podautoscalers.autoscaling.internal.knative.dev
PodAutoscaler是对扩缩容的一个抽象，简写是 KPA或 PA，每个 revision
会对应生成一个 PodAutoscaler。
可通过下面的指令查看
API: serverlessservices.networking.internal.knative.dev
ServerlessServices是 KPA产生的，一个 KPA生成一个 SKS， SKS是对 k8s service之上的一个抽象，
主要是用来控制数据流是直接流向服务 revision（实例数不为零）还是经过 Activator（实例数为0）。
对于每个 revision，会对应生成两个k8s service，一个 public service，一个 private service.
private service是标准的 k8s service，通过label selector来筛选对应的deploy产生的pod，即 svc对应的 endpoints由 k8s自动管控。
public service是不受 k8s管控的，它没有 label selector，不会像 private service一样自动生成 endpoints。 public service对应的 endpoints
由 Knative SKS reconciler来控制。
SKS有两种模式： proxy和 serve
下面看几种情况下的数据流向，加深对Knative扩缩容系统机制的理解。
稳定状态下的工作流程如下：
缩容到零过程的工作流程如下：
冷启动过程的工作流程如下：
当 revision缩容到零之后，此时如果有请求进来，则系统需要扩容。因为 SKS在 proxy模式，流量会直接请求到 Activator。 Activator会统计请求量并将指标主动上报到 Autoscaler，同时 Activator会缓存请求，并 watch SKS的 private service，直到 private service对应的endpoints产生。
Autoscaler收到 Activator发送的指标后，会立即启动扩容的逻辑。这个过程的得出的结论是至少一个Pod要被创造出来， AutoScaler会修改 revision对应 Deployment的副本数为为N（N>0）, AutoScaler同时会将 SKS的状态置为 serve模式，流量会直接到导到 revision对应的 pod上。
Activator最终会监测到 private service对应的endpoints的产生，并对 endpoints进行健康检查。健康检查通过后， Activator会将之前缓存的请求转发到
健康的实例上。
最终 revison完成了冷启动（从零扩容）。
二、IBM、谷歌等一票大佬共同研发的Knative,究竟是什么
Knative是什么？
要了解这个问题，你必须先了解什么是Kubernetes？以及Kubernetes最大的问题是什么？
Kubernetes是一个开源的，用于管理云平台中多个主机上的容器化的应用，Kubernetes的目标是让部署容器化的应用简单并且高效（powerful）,Kubernetes提供了应用部署，规划，更新，维护的一种机制。
那么问题来了！Kubernetes有一个最大的槽点就是入门门槛略高，而Knative正是为了解决这个问题来的。
Knative的⽬标是在基于 Kubernetes之上为整个开发⽣命周期提供帮助。它的具体实现⽅式是：⾸先使你作为开发⼈员能够以你想要的语⾔和以你想要的⽅式来编写代码，其次帮助你构建和打包应⽤程序，最后帮助你运⾏和伸缩应⽤程序。
为此，Knative将重点放在三个关键组件上： Build（构建）你的应⽤程序，为其提供流量 Serving（服务），以及确保应⽤程序能够轻松地⽣产和消费 Event（事件）。
Build（构建）
通过灵活的插件化的构建系统将⽤户源代码构建成容器。⽬前已经⽀持多个构建系统，⽐如 Google的 Kaniko，它⽆需运⾏ Docker daemon就可以在 Kubernetes集群上构建容器镜像。
Serving（服务）
基于负载⾃动伸缩，包括在没有负载时缩减到零。允许你为多个修订版本（revision）应⽤创建流量策略，从⽽能够通过 URL轻松路由到⽬标应⽤程序。
Event（事件）
使得⽣产和消费事件变得容易。抽象出事件源，并允许操作⼈员使⽤⾃⼰选择的消息传递层。
Knative是以 Kubernetes的⼀组⾃定义资源类型（CRD）的⽅式来安装的，因此只需使⽤⼏个 YAML⽂件就可以轻松地开始使⽤ Knative。
可以看出，knative是为了解决容器为核心的 serverless应用的构建、部署和运行的问题。
Knative提供了一组标准中间件，专注于在云原生平台上构建和运行应用的通用任务，比如源码到容器的构建、将服务绑定到事件生态系统（通过事件触发工作负载的执行）、管理部署期间的路由和流量以及工作负载的自动扩展。该框架为用户提供了“部署任何负载都需要的熟悉的、惯用的语言支持以及标准化的模式，这些负载包括传统的应用，也包括函数或容器应用”。
相对于传统的 Serverless解决方案，Knative的优良性得到开发者和企业认可，这也是其短时间内得到业内各大厂商追捧的主要原因。
Knative的优势
便利性： Knative以 Kubernetes和 istio作为其底层框架，因此无论是线上还是线下，任何 Kubernetes集群，无论是云上 Kubernetes服务还是自建 Kubernetes集群，都能通过安装 istio和 knative插件快速的搭建 serverless平台。
标准化： Knative联合 CNCF，把所有事件标准化，统一为 CloudEvent，提供事件的跨平台，同时让函数和具体的调用方能够解耦。
服务间解耦：使用 Knative使得应用不在与底层依赖服务强绑定，可以跨云实现业务互通
成熟的生态： Knative基于 Kubernetes体系构建，与 kubernetes生态结合更紧密；
自动伸缩：监控应用的请求，并自动扩缩容,得益于 Istio能力加持，天生支持蓝绿发布、回滚功能，方便应用发布流程。
应用监控：支持日志的收集、查找和分析，并支持 VAmetrics数据展示、调用关系 tracing。
不难看出，Knative虽然很年轻，但其成长速度非常快。其作为当今云原生态领域发展最快的开源项目之一，不仅通过提供简化工作流程的工具来解决这些问题，而且还为Kubernetes集群带来了非服务器工作负载的强大功能。目前已有不少项目加入到了年轻的Knative生态系统，且趋势是不断增加的。
目前Knative还在不断的更新优化中，每一次更新优化都离客户的最终诉求更近了一步，Knative的未来必定是一片坦途，相信将来通福云以及整个行业将会看到很多选项和机会将Knative运用起来。