2.Knative
Knative还在不断变化中，一些设计文档也并没有对外开放，读起来就相对k8s难一些，但整体代码量相比较也少了一些，在后续的文章里面我们还是先管中窥豹，逐个组件进行代码阅读，但因为没有相关的Proposal, 主要是参考冬岛大神的相关文章来进行代码的阅读，只是个人理解，如有不对，欢迎指教，接下来我们看看knative是如何完成上面提到的功能与实现按需分配关键组件, 我们从流量入口开始依次介绍各个组件
2.1 基于Istio实现南北向流量的管控
在k8s中南北向流量通常由Ingress来进行管控，而在kantive流量管控的实现，主要是依赖于istio, Istio是一个ServiceMesh框架，Knative中与其集成主要是使用了istio的南北向流量管控的功能，其实就是利用istio对应的ingress的功能, 主要功能分为下面两个部分
2.1.1 版本部署管理
Knative里面支持蓝绿、金丝雀等发布策略，其核心就是通过自己的revision版本管理和istio中的ingress的路由配置功能，即我们可以根据自己的需要设定对应的流量策略，从而进行版本的发布配置管理
2.1.2 自动伸缩(至零)
Knative自动伸缩有两个特点：按需自动分配、缩容至零，按需分配时指的knative可以根据应用的并发能力，来自动计算实现自动扩容，而且整个基本上是秒级，不同于HPA, 其次是就是缩容至零，即可以将对应的业务容器Pod，全部干掉，但是新进入请求之后会立即进行分配，并不影响正常访问(可能初期延迟会相对高一些)
2.2 Queue slidecar
在上面到过可观测性需求，在应用服务中通常可以分为三个部分：日志、监控、分布式跟踪，为了实现这些功能Knative实现了Queue组件，其职责目前理解主要是分为两个部分：完成观测性数据收集、代理业务容器的访问, Queue组件通过代理的方式实现上面提到指标的统计, 并将对应的数据汇报给后端的日志/监控/分布式跟踪服务, 同时还需要向autoscaler同步当前的并发监控, 以便实现自动伸缩功能, Queue主要是代理应用容器, 而Kantive支持缩容至零的特性, 在缩容至零的时候, Knative就会使用一个Activator Pod来替代Queue和应用容器，从而实现缩容至零
2.3 Activator
Activator容器是缩容至零的关键，当业务容器没有访问的时候，Knative就会将对应的ingress流量指向Activator组件，当缩容至零的时候，如果此时又业务请求，Activator会立即通知autoscaler立刻拉起业务容器，并将流量转发真正的业务容器，这样既可以完成流量的无损转发，又可以实现按需付费，再也不用为没有访问量的业务，一直启动着Pod了, Activator并不负责实际的伸缩决策，伸缩组件主要是通过Autoscaler来实现
2.4 Autoscaler
Autoscaler是Knative中实现自动扩容的关键，其通过Activator和Queue两个组件传递过来的监控数据并根据配置来计算，实时动态的调整业务容器的副本数量，从而实现自动伸缩
2.5 Controller
Controller是Knative对应资源的控制器，其本身的功能跟k8s中其他的组件的实现类似，根据资源的当前状态和期望状态来进行一致性调整，从而实现最终一致性
2.6 webhook
Knative是基于k8s的CRD实现的，其webhook主要包含对应资源数据的验证和修改等admission相关
