开发者学堂课程【通过 Knative 轻松实现应用 Serverless 化交付：Knative 极致 Serverless 体验】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/753/detail/13226
Knative 极致 Serverless 体验
主要内容
一、目录
二、Serverless 重要性
三、Serverless 特征
四、弹性和按实例数发布的矛盾
五、在 K8s 之上的应用编排抽象
六、Knative 是什么
一、目录
会从以下四个方面展开进行介绍
1.为什么需要 Knative
2.Knative Serving 简介
3. Knative 和云的完美融合
4.动手实践
二、Serverless 重要性
●Gartner 认为 Serverless 将在2019-2022年成熟，预计到2020将超过20%企业使用 Serverless 计算服务
● Forrester 报告显示49%的公司正在使用或在未来1年内将使用 Serverless 计算
● O'Reilly Serverless Survey 2019 1500名受访者的调研结果显示40%的受访者所在公司已经在使用 Serverless 技术，超过三分之二的受访者认为他们的组织对Serverless 的采用至少大部分是成功的
●Serverless 已经是万众期待，未来可期的状态
serverless 是万众期待的，各种调查报告显示，企业级开发者已经在使用 servlet，构建线上服务，而且比例还在不断增加，在大趋势下，可以看一下演进方向，起初企业上云都是基于VMs方式来使用云资源，企业线上服务都是通过 laas 等工具部署在 VMs 中的，直接启动应用导致线上服务对 vms 环境配置有很强的依赖，伴随着容器技术的崛起，开始通过容器方式在 VM 中部署应用，但如果是十几或者几十个应用需要部署，那就需要在成百上千的 vm 中，快速部署升级应用，这是一件非常令人头痛的事情，而 kubemetes 很好的解决了这件事情，所以现在大多数人通过kubemetes 使用云资源，随着 kubemetes 的流行，各大云厂商都提供了serverless kubemetes 服务，用户无需维护 kubemetes 集群，即可直接通过kubemetes 使用云的能力。
三、Serverless 特征
1.按需使用，自动弹性
按需使用云资源，当用量上涨的时候，自动扩容，用量下降的时候自动缩容，所以需要自动弹性的能力
2.灰度发布
要能支持多产品管理，应用升级的时候，可以使用多种灰度发布策略上线新的版本
3.流量管理
流量管理能够管理南北流量，可以按照流量百分比对不同版本进行灰度
4.负载均衡、服务发现
应用弹性过程中自动增加，或者减少，流量管理需要具备负载均衡和服务发现的能力
Gateway (网关)
多个应用在同一个集群中，需要接入层网管，对多个应用进行同一个应用的不同版本进行流量的管理
随着 knative 和云原生技术的崛起，能想到的第一个是是否可以直接在kubemetes上面部署 serverless 应用，下面看一下如果要在原生的 kubemetes 部署 serverless 应用需要做到什么。
四、弹性和按实例数发布的矛盾
首先需要一个 Deployment 来管理 cloud，通过 service 对外包服务，和实现服务能力，应用有重大变更，新版本发布时，可能需要暂停观察，在观察确认没有问题之后，再继续增加灰度的比例，这时候就需要两个 deployment 才能做到，V1代表旧的版本，灰度的时候减少实例数。v2代表新的版本，灰度的时候增加实例数。HP代表弹性能力，每一个 Deployment 都有一个 HP 弹性管理配置，这里面是存在冲突的，假如 V1deployment 有三个 pod，灰度的时候升级一个POD的到V2，此时实例是6/3的流量达到 V2版本以上，但当业务高峰来临时，如果两个版本都配置了apv，那么 V2会同时扩容，最终v2的数量就不是最初设定的1/3比例了，所以传统Deployment发布的实例数和弹性配置天然是冲突的。而如果按照流量比例进行灰度，就不会有这种问题，如果按照流量比例进行灰度的话，可能需要引入 Istio 能力。
引入 Istio 进行组件，Istio 除了管理同一个应用的流量灰度，还能对不同的应用进行流量管理，这看起来很不错但其实在仔细分析以后，它存在如下几个问题，首先如果是在原生上面进行创建的话，需要做这些资源的管控，Deployment service，hpa，ingress，Istio包括 virtual service 和 gateway 都是需要的，这些资源是每个应用独一份，但是多个应用的话，就要有多份的配置。这些资源散落在kbs内，根本无法体现出应用的概念，另外管理起来也是非常繁琐。
五、在K8s之上的应用编排抽象
1.现状
●用户使用云正在向面向服务的方式转变，弹性越来越重要
●通过 k8s API 实现服务全生命周期管理比较复杂
●需要面向 Serverless 应用的抽象，而不是面向底层资源的抽象
2.提出问题?
如何才能让用户以及上层 PaaS 平台以面向服务的方式使用云的能力?
Serverless 需要的是面向，应用的管理动作，比如进行托管、升级和灰度发布、流量管理以及弹性等能力，而 kubemetes 提供的使用抽象，所以 kubemetes 和之间少了一层应用编排抽象，knative 就是在 kubemetes 上的 serverless 应用编排框架，除了 knative 以外，也设计了好几款 fast，一些编排框架，但是这些框架没有统一的标准，每一套框架都有自己的一套规范，而且和 kubemetes API 不兼容，不兼容的 API 就会造成可复用性性不强。核心标准就是 kubemetes API 标准，knative 管理的 serverless 应用，保持 kubemetes API 领域不变，而和kubemetes API 有更好的兼容性，这也是 knative 特质所在。
六、Knative 是什么
Kubernetes-based platform to build, deploy,and manage modern serverless workloads.
基于 Kubernetes 平台，用于构建、部署和管理现代 Serverless 工作负载
Knative 主要是在 Kubernetes 提供通用的 serverless 编排调度服务，给上层的serverless 应用提供面向应用层的原子操作，并且通过 kubemetes 原生API暴露服务 API，保持和 kubemetes 生态的完美融合。
