开发者学堂课程【如何通过 Knative 轻松实现应用 Serverless 化交付： Knative 极致 Serverless 体验（一）】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/291/detail/3431
Knative 极致 Serverless 体验（一）
内容介绍
1.为什么需要 Knaltlive
2.Knative Sarving 简介
3.Knatiwe 和云的完美融合
4.动手实践
5.总结
一、为什么需要 Knaltlive
Serverless 当前已是万众期待，未来可期，各种调查报告显示企业和开发者已经在使用 Serverless 构建线上服务，而且这个比例还在不断增加。在这个大趋势下，最初企业线上服务都是基于 VM 的方式使用云资源，都是通过工具裸部署在VM中。直接在VM中启动应用导致线上服务对VM有很强的依赖。然后伴随着容器的崛起，大家开始在容器技术中部署应用。但如果有十几甚至几十个应用需要部署，就需要在 vm 中成百上千进行部署，而 Knaltlives 很好的解决了这个问题。
1、Serverless 应用的共同的特质
（1）按需使用，自动弹性。按需使用云资源，应用量上涨的时候自动扩容，应用量降低的时候自动缩容。所以需要具备自动弹性的能力。
（2）灰度发布。要能支持多版本管理，应用升级的时候可以使用各种灰度发布策略上线新的版本。
（3）流量管理。能够管理流量，对不同版本进行灰度。
（4）负载均衡、服务发现。应用弹性过程中自动增加或者减少，所以说需要具备负载均衡、服务发现
（5）Gateway(网关)多个应用在同一集群中需要对同一应用的不同版本进行管理。
2、弹性和按实例数发布的矛盾
首先需要一个 Deployment 来管理 Workload，还需要通过 Service 对外暴露服务和实现服务发现的能力。应用有重大变更，新版本发布时可能需要暂停观察，待观察确认没问题之后再继续增加灰度的比例。这时就要使用两个 Deployment 才能做到。
v1 Deployment 代表旧版本，灰度的时候逐一减少实例数；
v2 Deployment 代表新版本，灰度的时候逐一增加实例数。
hpa 代表弹性能力，每一个 Deployment 都有一个 hpa 管理弹性配置。这其中其实是有冲突的：假设 v1 Deploymen 原本有三个 pod，灰度的时候升级一个 pod 到 v2，此时其实是 1/3 的流量会打到 v2 版本上。但当业务高峰到来后，因为两个版本都配置了 hpa，所以 v2 和 v1 会同时扩容，最终 v1 和 v2 的 pod 数量就不是最初设置的 1/3 的比例了。
所以传统的这种按照 Deployment 实例数发布的灰度策略和弹性配置天然是冲突的。而如果按照流量比例进行灰度就不会有这个问题，这可能就要引入 Istio 的能力。
3、引入流量管理网管
引入 Istio 作为 Gateway 组件，Istio 除了管理同一个应用的流量灰度，还能对不同的应用进行流量管理。看起来很好，但是仔细分析一下存在什么问题。先梳理一下在原生 K8s 之上手动管理。 Serverless 应用都需要做什么：
· Deployment
· Service
· HPA
· Ingress
· Istio
· VirtualService
· Gateway
这些资源是每一个应用维护一份，如果是多个应用就要维护多份。这些资源散落在 K8s 内，根本看不出来应用的概念，另外管理起来也非常繁琐。
4、在 K8s 之上的应用编排抽象
Serverless 应用需要的是面向应用的管理动作，比如应用托管、升级、回滚、灰度发布、流量管理以及弹性等功能。而 Kubernetes 提供的是 IaaS 的使用抽象。所以 Kubernetes 和 Serverless 应用之间少了一层应用编排的抽象。
而 Knative 就是建立在 Kubernetes 之上的 Serverless 应用编排框架。除了 Knative 以外，社区也有好几款 FaaS 类的编排框架，但这些框架编排出来的应用没有统一的标准，每一个框架都有一套自己的规范，而且和 Kubernetes API 完全不兼容。不兼容的 API 就导致使用难度高、可复制性不强。云原生的一个核心标准就是 Kubernetes 的 API 标准，Knative 管理的 Serverless 应用保持 Kubernetes API 语义不变。和 Kubernetes API 具有良好的兼容性，就是 Knative 的云原生特性所在。
5、Knative 是什么呢?
Knative 主要解决的问题就是在 Kubernetes 之上提供通用的 Serverless 编排、调度服务，给上层的 Serverless 应用提供面向应用层的原子操作。并且通过 Kubernetes 原生 API 暴露服务 API，保持和 Kubernetes 生态工具链的完美融合。Knative 有 Eventing 和 Serving 两个核心模块，本文主要介绍 Serving 的核心架构。
