关于云原生-cloud-native:从零入门-Serverless-Knative-带来的极致-Serverless-体验

0次阅读

共计 5644 个字符，预计需要花费 15 分钟才能阅读完成。

作者 | 冬岛阿里巴巴高级技术专家

Serverless 公众号后盾回复“knative”，即可收费下载《Knative 云原生利用开发指南》电子书！

导读：Serverless 如今已是万众期待将来可期的状态，但一个零碎到底具备怎么的能力能力更好地撑持 Serverless 利用？随着 Kubernetes 和云原生概念的崛起，Serverless 在 Kubernetes 之上应该怎么玩？本文就从 Serverless 利用的外围特质登程，探讨作为 Serverless 利用治理平台应该具备哪些特质。通过本文让您对 Knative 的 Serverless 利用治理形式有一个粗浅的理解。

Serverless 曾经是万众期待，将来可期的状态。各种调查报告显示企业及开发者曾经在应用 Serverless 构建线上服务，而且这个比例还在一直减少。

在这个大趋势下，咱们再来看 IaaS 架构的演进方向。最后企业上云都是基于 VM 的形式在应用云资源，企业线上服务都是通过 Ansible、Saltstack、Puppet 或者 Chef 等工具裸部在 VM 中的。间接在 VM 中启动利用，导致线上服务对 VM 的环境配置有很强的依赖，而后随同着容器技术的崛起，大家开始通过容器的形式在 VM 中部署利用。

但如果有十几个甚至几十个利用须要部署，就须要在成千盈百的 VM 疾速部署、降级利用，这是一件十分令人头疼的事件。而 Kubernetes 很好地解决了这些问题，所以当初大家开始通过 Kubernetes 形式应用云资源。随着 Kubernetes 的风行，各大云厂商都开始提供 Serverless Kubernetes 服务，用户无需保护 Kubernetes 集群，即可间接通过 Kubernetes 语义应用云的能力。

既然 Kubernetes 曾经十分好了，为什么还须要 Knative 呢？要答复这个问题，咱们先梳理一下 Serverless 利用都有哪些独特特质：

按需应用，主动弹性

按需应用云资源，业务量上涨的时候主动扩容，业务量降落的时候主动缩容，所以须要主动弹性能力。

灰度公布

要能反对多版本治理，利用降级的时候能够应用各种灰度公布策略上线新的版本。

流量治理

可能治理南北流量，能够依照流量百分比对不同版本进行灰度。

负载平衡、服务发现

利用弹性过程中主动减少或者缩小实例数量，流量治理须要具备负载平衡和服务发现的性能。

Gateway

多个利用部署在同一个集群中，须要一个接入层网关对多个利用以及同一个利用的不同版本进行流量的治理。

随着 Kubernetes 和云原生概念的崛起，第一直觉可能是间接在 Kubernetes 之上部署 Serverless 利用。那么，如果要在原生的 Kubernetes 上部署 Serverless 利用咱们可能会怎么做？

首先须要一个 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 的能力。

引入 Istio 作为 Gateway 组件，Istio 除了治理同一个利用的流量灰度，还能对不同的利用进行流量治理。看起来很好，然而咱们再仔细分析一下存在什么问题。先梳理一下在原生 K8s 之上手动治理 Serverless 利用都须要做什么：

Deployment
Service
HPA
Ingress
Istio
- VirtualService
- Gateway

这些资源是每一个利用保护一份，如果是多个利用就要保护多份。这些资源散落在 K8s 内，基本看不出来利用的概念，另外治理起来也十分繁琐。

Serverless 利用须要的是面向利用的治理动作，比方利用托管、降级、回滚、灰度公布、流量治理以及弹性等性能。而 Kubernetes 提供的是 IaaS 的应用形象。所以 Kubernetes 和 Serverless 利用之间少了一层利用编排的形象。

而 Knative 就是建设在 Kubernetes 之上的 Serverless 利用编排框架。除了 Knative 以外，社区也有好几款 FaaS 类的编排框架，但这些框架编排进去的利用没有对立的规范，每一个框架都有一套本人的标准，而且和 Kubernetes API 齐全不兼容。不兼容的 API 就导致应用难度高、可复制性不强。云原生的一个外围规范就是 Kubernetes 的 API 规范，Knative 治理的 Serverless 利用放弃 Kubernetes API 语义不变。和 Kubernetes API 具备良好的兼容性，就是 Knative 的云原生个性所在。

Knative 次要解决的问题就是在 Kubernetes 之上提供通用的 Serverless 编排、调度服务，给下层的 Serverless 利用提供面向应用层的原子操作。并且通过 Kubernetes 原生 API 裸露服务 API，放弃和 Kubernetes 生态工具链的完满交融。Knative 有 Eventing 和 Serving 两个外围模块，本文次要介绍 Serving 的外围架构。

Serving 外围是 Knative Service，Knative Controller 通过 Service 的配置主动操作 Kubernetes Service 和 Deployment，从而实现简化利用治理的指标。

Knative Service 对应一个叫做 Configuration 的资源，每次 Service 变动如果须要创立新的 Workload 就更新 Configuration，而后每次 Configuration 更新都会创立一个惟一的 Revision。Revision 能够认为是 Configuration 的版本管理机制。实践上 Revision 创立完当前是不会批改的。

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 API 细节。

上图展现了 Knative Autoscaler 的工作机制，Route 负责接入流量，Autoscaler 负责做弹性伸缩。当没有业务申请时会缩容到零，缩容到零后 Route 进来的申请会转到 Activator 上。当第一个申请进来之后 Activator 会放弃住 http 链接，而后告诉 Autoscaler 去做扩容。Autoscaler 把第一个 pod 扩容实现当前 Activator 就把流量转发到 Pod，从而做到了缩容到零也不会损失流量的目标。

到此 Knative Serving 的外围模块和基本原理曾经介绍结束，你应该对 Knative 曾经有了初步理解。在介绍原理的过程中你可能也感触到了，要想把 Knative 用起来其实还是须要保护很多 Controller 组件、Gateway 组件（比方 Istio)）的，并且要继续地投入 IaaS 老本和运维老本。

Gateway 组件假如应用 istio 实现的话，Istio 自身就须要十几个 Controller，如果要做高可用可能就须要二十几个 Controller。Knative Serving Controller 全都高可用部署也须要十几个。这些 Controller 的 IaaS 老本和运维老本都比拟多。另外冷启动问题也很显著，尽管缩容到零能够升高业务波谷的老本，然而第一批流量也可能会超时。

为了解决上述问题，咱们把 Knative 和阿里云做了深度的交融。用户还是依照 Knative 的原生语义应用，但底层的 Controller、Gateway 都深度嵌入到阿里云体系内。这样既保证了用户能够无厂商锁定危险地以 Knative API 应用云资源，还能享受到阿里云基础设施的已有劣势。

首先是 Gateway 和云的交融，间接应用阿里云 SLB 作为 Gateway，应用云产品 SLB 的益处有：

云产品级别的撑持，提供 SLA 保障；
按需付费，不须要出 IaaS 资源；
用户无需承当运维老本，不必思考高可用问题，云产品自带高可用能力。

除了 Gateway 组件以外，Knative Serving Controller 也须要肯定的老本，所以咱们把 Knative Serving Controller 和阿里云容器服务也进行了交融。用户只须要领有一个 Serverless Kubernetes 集群并开明 Knative 性能就能够基于 Knative API 应用云的能力，并且用户无需为 Knative Controller 付出任何老本。

接下来再剖析一下冷启动问题。

传统利用在没开启弹性配置的时候实例数是固定的，Knative 治理的 Serverless 利用默认就有弹性策略，在没有流量的时候会缩容到零。传统利用在流量低谷时即使没有业务申请解决，实例数还是放弃不变，这其实是浪费资源的。但益处就是申请不会超时，什么时候过去的申请都能够会很好地解决。而如果缩容到零，第一个申请达到当前才会触发扩容的过程。

Knative 的模型中从 0 到 1 扩容须要 5 个步骤串行进行，这 5 个步骤都实现当前能力开始解决第一个申请，而此时往往都会超时。所以 Knative 缩容到零尽管升高了常驻资源的老本，但第一批申请的冷启动问题也非常明显。可见弹性其实就是在寻找老本和效率的一个平衡点。

为了解决第一个实例的冷启动问题，咱们推出了保留实例性能。保留实例是阿里云容器服务 Knative 独有的性能。社区的 Knative 默认在没有流量时缩容到零，然而缩容到零之后从 0 到 1 的冷启动问题很难解决。冷启动除了要解决 IaaS 资源的调配、Kubernetes 的调度、拉镜像等问题以外，还波及到利用的启动时长。利用启动时长从毫秒到分钟级别都有。利用启动工夫齐全是业务行为，在底层平台层面简直无法控制。

ASK Knative 对这个问题的解法是通过低价格的保留实例，来均衡老本和冷启动问题。阿里云 ECI 有很多规格，不同规格的计算能力不一样，价格也不一样。如下所示是对 2c4G 配置的计算型实例和突发性能型实例的价格比照。

通过上图可知突发性能实例比计算型便宜 46%，可见如果在没有流量时，应用突发性能实例提供服务不单单解决了冷启动的问题，还能节俭很多老本。

突发性能实例除了价格优势以外，还有一个十分亮眼的性能就是 CPU 积分。突发性能实例能够利用 CPU 积分应答突发性能需求。突发性能实例能够继续取得 CPU 积分，在性能无奈满足负载要求时，能够通过耗费积攒的 CPU 积分无缝进步计算性能，不会影响部署在实例上的环境和利用。通过 CPU 积分，您能够从整体业务角度调配计算资源，将业务平峰期残余的计算能力无缝转移到高峰期应用（简略的了解就是油电混动）。突发性能实例的更多细节参见这里。

所以 ASK Knative 的策略是在业务波谷时应用突发性能实例替换规范的计算型实例，当第一个申请来长期再无缝切换到规范的计算型实例。这样能够升高流量低谷的老本，并且在低谷时取得的 CPU 积分，还能在业务顶峰到来时生产掉，用户领取的每一分钱都不会节约。

应用突发性能实例作为保留实例只是默认策略，用户能够指定本人冀望的其余类型实例作为保留实例的规格。当然用户也能够指定最小保留一个规范实例，从而敞开保留实例的性能。

Knative 是 Kubernetes 生态最风行的 Serverless 编排框架。社区原生的 Knative 须要常驻的 Controller 和常驻的网关能力提供服务。这些常驻实例除了须要领取 IaaS 老本以外还带来了很多运维累赘，给利用的 Serverless 化带来了肯定的难度，因而咱们在 ASK 中齐全托管了 Knative Serving，开箱即用极致的 Serverless 体验。

为了更多开发者可能享受到 Serverless 带来的红利，这一次，咱们集结了 10+ 位阿里巴巴 Serverless 畛域技术专家，打造出最适宜开发者入门的 Serverless 公开课，让你即学即用，轻松拥抱云计算的新范式——Serverless。

点击即可收费观看课程：https://developer.aliyun.com/learning/roadmap/serverless