开发者学堂课程【如何通过 Knative 轻松实现应用 Serverless 化交付： Knative 极致 Serverless 体验（二）】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/291/detail/3431
Knative 极致 Serverless 体验（二）
二、Knative Serving 简介
1、Knative Serving 架构
（1）Serving 核心是 Knative Service，Knative Controller 通过 Service 的配置自动操作 Kubernetes Service 和 Deployment，从而实现简化应用管理的目标。
（2）Knative Service 对应一个叫做 Configuration 的资源，每次 Service 变化如果需要创建新的 Workload 就更新 Configuration，（3 ）每次 Configuration 更新都会创建一个唯一的 Revision。
Revision 可以认为是 Configuration 的版本管理机制。理论上 Revision 创建完以后是不会修改的。
（4）Route 主要负责 Knative 的流量管理，Knative Route Controller 通过 Route 的配置自动生成 Knative Ingress 配置，Ingress Controller 基于 Ingress 策略实现路由的管理。
Knative Serving 对应用 Workload 的 Serverless 编排是从流量开始的。流量首先达到 Knative 的 Gateway，Gateway 根据 Route 的配置自动把流量根据百分比拆分到不同的 Revision 上，然后每一个 Revision 都有一个自己独立的弹性策略。当过来的流量请求变多时，当前 Revision 就开始自动扩容。每一个 Revision 的扩容策略都是独立的，相互不影响。
基于流量百分比对不同的 Revision 进行灰度，每一个 Revision 都有一个独立的弹性策略。Knative Serving 通过对流量的控制实现了流量管理、弹性和灰度三者的完美结合。
到此 Knative Serving 的核心模块和基本原理已经介绍完毕，应该对 Knative 已经有了初步了解。在介绍原理的过程中你可能也感受到了，要想把 Knative 用起来还是需要维护很多 Controller 组件、Gateway 组件（比如 Istio)的，并且要持续地投入 IaaS 成本和运维成本。
2、平台成本和复杂度
Gateway 组件假设使用 istio 实现的话，Istio 本身就需要十几个 Controller，如果要做高可用可能就需要二十几个 Controller。Knative Serving Controller 全都高可用部署也需要十几个。这些 Controller 的 IaaS 成本和运维成本都比较多。另外冷启动问题也很明显，虽然缩容到零可以降低业务波谷的成本，但是第一批流量也可能会超时。
三、Knative 和云的完美融合
1、Gateway 和云的融合
为了解决上述问题，我们把 Knative 和阿里云做了深度的融合。用户还是按照 Knative 的原生语义使用，但底层的 Controller 、Gateway 都深度嵌入到阿里云体系内。这样既保证了用户可以无厂商锁定风险地以 Knative API 使用云资源，还能享受到阿里云基础设施的已有优势。
首先是 Gateway 和云的融合，直接使用阿里云 SLB 作为 Gateway，使用云产品 SLB 的好处有：
· 云产品级别的支撑，提供 SLA 保障；
· 按需付费，不需要出 IaaS 资源；
· 用户无需承担运维成本，不用考虑高可用问题，云产品自带高可用能力。
总结出来以下两点：
降成本:减少了十几个组件，大大降低运维成本和laas成本。
更稳定: SLB云产品服务更稳定、可靠性更高，易用性也更好。
2、管控组件下沉
除了 Gateway 组件以外，Knative Serving Controller 也需要一定的成本，所以我们把 Knative Serving Controller 和阿里云容器服务也进行了融合。用户只需要拥有一个 Serverless Kubernetes 集群并开通 Knative 功能就可以基于 Knative API 使用云的能力，并且用户无需为 Knative Controller 付出任何成本。
即以下三点：
●开箱即用:用户直接使用Serverless Framework,不需要自己安装。
●免运维、低成本: Knative组件和K8s集群进行融合，用户没有运维负担，也无需承担额外的资源成本。
●高管控:所有组件都在管控端部署，升级和迭代更容易。
3、优雅的保留实例
免冷启动:通过保留规格消除了从0到1的30秒冷启动时间
成本可控:突发性能实例成本比标准规格实例降低40%的成本,如果和Spot实例结合还能再进一步降低成本
四、动手实践
1.部署 coffee 服务
spec:
containers:
image: registry . cn-hangzhou . aliyuncs . com knative sample/he lloworld-go: 16e4dc8env :
name: TARGET
value: "coffee"
[root@i Zbp1djyqnxhjfv9h9s0edZ serverless]# kubectl apply - f ksvc-coffee. Yaml
执行 kubectl apply -f coffee.yaml 部署 coffee 服务，稍等一会儿应该可以看到 coffee 服务已经部署好了。
# kubectl get ksvc
coffee http://coffee.default.example.com coffee-fh85b coffee-fh85b True
2.访问 coffee 服务
# curl -H "Host: coffee.default.example.com" http://47.102.220.35
Hello coffee!
3.保留实例
保留实例启动后，正常实例就下线掉。
保留实例：
coffee-6zbbd-deployment-58c7c4f546-92c58 2/2 Running 2m51s
coffee-6zbbd-deployment-reserve-75f88bf97c-r6j5g 0/2 Pending 17s
正常实例：
coffee-6zbbd-deployment-reserve-75f88bf97c-r6i5q 2/2 Running 0 33s
五、总结
1.为什么需要 Knative
通过原生的 Kubernetes 创建Serverless ，遇到了一些问题，这时Knative提供了 Serverless 编排框架。
2.Knative Serving
包括Service这些信息。
3.Knative与云的结合
把相关的组件像常驻的 Controller 和常驻的网关和阿里云进行深度融合，做到了极致的 Serverless 体验。
