作者 | 李鹏（元毅）
起源 | Serverless 公众号

一、为什么须要 Knative

K8s 目前已成为云原生市场上的支流操作系统，K8s 对上 通过数据抽象裸露基础设施能力，比方 Service、Ingress、Pod、Deployment 等，这些都是通过 K8s 原生 API 给用户裸露进去的能力；而 对下 K8s 提供了基础设施接入的一些标准接口，比方 CNI、CRI、CRD，让云资源以一个标准化的形式进入到 K8s 的体系中。

K8s 处在一个承前启后的地位，云原生用户应用 K8s 的目标是为了交付和治理利用，也包含灰度公布、扩容缩容等。然而对用户来说，实现这些能力，通过间接操作 K8s API 不免有些简单。另外节俭资源老本和弹性对于用户来说也越来越重要。

那么，如何能力简略地应用 K8s 的技术，并且实现按需应用，最终实现降本增效的目标呢？答案就是 Knative。

二、Knative 简介

1. Knative 是什么

• 定义

Knative 是一款基于 Kubernetes 的 Serverless 编排引擎，Knative 一个很重要的指标是制订云原生跨平台的编排规范，它通过整合容器构建、工作负载以及事件驱动来实现这一目标。

Knative 社区以后贡献者次要有 Google、Pivotal、IBM、Red Hat，可见其阵容强大，另外还有 CloudFoundry、OpenShift 这些 PAAS 提供商也都在踊跃地参加 Knative 的建设。

• 外围模块

Knative 外围模块次要包含两局部：事件驱动框架 Eventing 和提供工作负载的 Serving，接下来本文次要介绍 Serving 相干的一些内容。

2. 流量灰度公布

以一个简略的场景为例：

• 在 K8s 中实现基于流量的灰度公布

如果要在 K8s 中实现基于流量的灰度公布，须要创立对应的 Service 与 Deployment，弹性相干的须要 HPA 来做，而后在流量灰度公布时，要创立新的版本。

以上图为例，开创版本是 v1，要想实现流量灰度公布，咱们须要创立一个新的版本 v2。创立 v2 时，要创立对应的 Service、Deployment、HPA。创立完之后通过 Ingress 设置对应的流量比例，最终实现流量灰度公布的性能。
 

• 在 Knative 中实现基于流量的灰度公布

如上图所示，在 Knative 中想要实现基于流量的灰度公布，只须要创立一个 Knative Service，而后基于不同的版本进行灰度流量，能够用 Revision1 和 Revision2 来示意。在不同的版本外面，曾经蕴含了主动弹性。
 
从下面简略的两个图例，咱们能够看到在 Knative 中实现流量灰度公布时，须要间接操作的资源显著较少。

3. Knative Serving 架构

• Service

Service 对应 Serverless 编排的形象，通过 Service 治理利用的生命周期。Service 下又蕴含两大部分：Route 和 Configuration。

• Route

Route 对应路由策略。将申请路由到 Revision，并能够向不同的 Revision 转发不同比例的流量。

• Configuration

Configuration 配置的是相应的资源信息。以后冀望状态的配置。每次更新 Service 就会更新 Configuration。

• Revision

每次更新 Configuration 都会相应失去一个快照，这个快照就是 Revision，通过 Revision 实现多版本治理以及灰度公布。

咱们能够这样了解：Knative Service ≈ Ingress + Service + Deployment + 弹性（HPA）。

4. 丰盛的弹性策略

当然，Serverless 框架离不开弹性，Knative 中提供了以下丰盛的弹性策略：

• 基于流量申请的主动扩缩容：KPA；
• 基于 CPU、Memory 的主动扩缩容：HPA；
• 反对定时 + HPA 的主动扩缩容策略；
• 事件网关（基于流量申请的精准弹性）。

三、Knative 和 ASK 交融

1. ASK：Serverless Kubernetes

如果要筹备 ECI 资源的话，须要提前进行容量布局，这无疑违反了 Serverless 的初衷。为解脱 ECI 资源的解放，不用提前进行 ECI 资源布局，阿里云提出了无服务器 Serverless——ASK。用户无需购买节点，即可间接部署容器利用，无需对节点进行保护和容量布局。ASK 提供了 K8s 兼容的能力，同时极大地升高了 K8s 的应用门槛，让用户专一于应用程序，而不是底层基础设施。

ASK 提供了以下能力：

• 免运维

开箱即用，无节点治理和运维，无节点平安保护，无节点 NotReady，简化 K8s 集群治理。

• 极致的弹性扩容

无容量布局，秒级扩容，30s 500pod。

• 低成本

按需创立 Pod，反对 Spot，预留实例券。

• 兼容 K8s

反对 Deployment/statfulset/job/service/ingress/crd 等。

• 存储挂载

反对挂载云盘、NAS、OSS 存储券。

• Knative on ASK

基于利用流量的主动弹性，开箱即用，缩容到最小规格。

• Elastic Workload

反对 ECI 按量和 Spot 混合调度。

• 集成 ARMS/SLS 等云产品

2. Knative 运维复杂度

Knative 运维次要存在三个方面的问题：Gateway、Knative 管控组件和冷启动问题。

如上图所示，在 Knative 中管控组件会波及到相应的 Activator，它是从 0 到 1 的一个组件；Autoscaler 是扩缩容相干的组件；Controller 是本身的管控组件以及网关。对于这些组件的运维，如果放在用户层面做，无疑会加重负担，同时这些组件还会占用老本。

除此之外，从 0 到 1 的冷启动问题也须要思考。当利用申请过去时，第一个资源从开始到启动实现须要一段时间，这段时间内的申请如果响应不及时的话，会造成申请超时，进而带来冷启动问题。

对于下面说到的这些问题，咱们能够通过 ASK 来解决。上面看下 ASK 是如何做的？

3. Gateway 和 SLB 交融

相比于之前 Istio 提供的能力，咱们须要经营管控 Istio 相干的组件，这无疑加大了管控老本。实际上对于大部分场景来说，咱们更关怀网关的能力，Istio 自身的一些服务（比方服务网格）咱们其实并不需要。

在 ASK 中，咱们将网关这一层通过 SLB 进行了替换：
 

• 降老本：缩小了十几个组件，大大降低运维老本和 IaaS 老本；
• 更稳固：SLB 云产品服务更稳固，可靠性更高，易用性也更好。

4. 管控组件下沉

对于 Knative 管控组件，ASK 做了一些托管：

• 开箱即用：用户间接应用 Serverless Framework，不须要本人装置；
• 免运维、低成本：Knative 组件和 K8s 集群进行交融，用户没有运维累赘，也无需承当额定的资源老本；
• 高管控：所有组件都在管控端部署，降级和迭代更容易。

5. 优雅的保留实例

在 ASK 平台中，咱们提供了优雅保留实例的能力，其作用是 免冷启动。通过保留实例，打消了从 0 到 1 的冷启动工夫。当咱们缩容到 0 的时候，并没有把实例真正缩容到 0，而是缩容到一个低规格的保留实例上，目标是降低成本。

• 免冷启动：通过保留规格打消了从 0 到 1 的 30 秒冷启动工夫；
• 老本可控：突发性能实例老本比规范规格实例升高 40% 的老本，如果和 Spot 实例联合还能再进一步降低成本。

四、实操演示

最初进行入手实际演示，以一家咖啡店（cafe）为例，演示内容次要有：

• 在 ASK 集群中装置 Knative；
• 部署 coffee 服务；
• 拜访 coffee 服务；
• 保留实例。

演示过程观看链接：https://developer.aliyun.com/live/246126

作者简介：
李鹏，花名：元毅，阿里云容器平台高级开发工程师，2016 年退出阿里，深度参加了阿里巴巴全面容器化、间断多年反对双十一容器化链路。专一于容器、Kubernetes、Service Mesh 和 Serverless 等云原生畛域，致力于构建新一代 Serverless 平台。以后负责阿里云容器服务 Knative 相干工作。