导读

随着云计算技术的发展，云资源交付变的越来越简单，按需使用已经成为可能。在按需使用资源的模式下，用户更多的聚焦于业务自身，而减少了对基础设施的关注，Serverless 理念也因此应运而生。我们知道 Kubernetes 已成为当今云原生业界标准，具备良好的生态以及跨云厂商能力。Kubernetes 很好的抽象了 IaaS 资源交付的标准， 但如果想要在 Kubernetes 之上以 Severless 的方式管理应用还是要做很多事情的。Knative 在 K8s 之上又做了进一步的简化，大大降低了应用生命周期管控复杂度，同时提供了自动弹性和灰度发布等能力，同时基于阿里云 Severless Kubernetes （ASK）提供的极致容器化 Serverless，给您带来云原生 Serverless 应用完全体。本文会从如下 4 部分内容展开介绍：

• 为什么需要 Knative
• Knative 简介
• Knative 和 ASK 融合
• 演示示例

为什么需要Knative

我们知道当前K8s 已经成为了云原生事实上的操作系统，Kubernetes 对上通过数据抽象暴露基础设施能力，比如 Service、Ingress、Pod、Deployment，这些都是通过 Kubernetes 原生 API 给用户暴露出来的能力。而对下，Kubernetes 提供了基础设施能力接入的标准接口，比如说 CNI、CRD，让云资源以一个标准化的方式接入到 Kubernetes 的体系中。今天我们来看 Kubernetes 所处的位置，实际上是承上启下。云原生的用户使用 Kubernetes 的目的，都是为了交付和管理应用，当然也包括灰度发布、扩容缩容等，并且兼顾资源成本。

但我们实际在使用Kubernetes过程中, 逐渐会发现如下问题：

• 通过 k8s API 实现服务全生命周期管理比较复杂
• 云 IaaS 资源规格繁杂，每一种规格适用场景都所有不同，用户很难自己组合所有规格
• 节省资源使用成本，弹性越来越重要

那么如何才能简单的使用容器（K8s）技术？如何随心所欲的实现按需使用，降低成本？答案就是：Knative

Knative 简介

Knative 是在 2018 的 Google Cloud Next 大会上发布的一款基于Kubernetes 的 Serverless编排引擎。Knative 一个很重要的目标就是制定云原生、跨平台的Serverless 编排标准。Knative 是通过整合容器构建(或者函数)、工作负载管理(弹性)以及事件模型这三者来实现的这一Serverless 标准。Knative 社区的当前主要贡献者有Google、Pivotal、IBM、Red Hat。另外像 CloudFoundry、OpenShift 这些 PAAS 提供商都在积极的参与Knative 的建设。

Knative 核心模块

Knative 核心模块主要包括事件驱动框架 Eventing 和部署工作负载的Serving。

Serverless 服务引擎 - Serving

Knative Serving 核心能力就是其简洁、高效的应用托管服务，这也是其支撑Serverless 能力的基础。当然作为SeverlesssFramework 就离不开按需分配资源的能力，Knative 可以根据您应用的请求量在高峰时期自动扩容实例数，当请求量减少以后自动缩容实例数，可以非常自动化的帮助您节省成本。Serving 还提供了的流量管理能力和灵活的灰度发布能力。流量管理能力可以根据百分比切分流量，灰度发布能力可以根据流量百分比进行灰度。

一个简单的场景：基于流量灰度发布

我们以一个简单的流量灰度发布为例，先看一下在k8s中如何实现。

我们创建一个提供外部访问的服务，在 K8s 中需要创建如下资源：

• Deployment: 部署应用的工作负载
• Service: 提供服务访问以及负载均衡的能力
• Ingress： 对外提供域名访问的功能
• HPA：我们实现按照负载（cpu、memory）自动弹性，需要创建HPA。

初始的时候，通过V1提供服务，这时候如果要灰度新的版本，那么需要创建对应资源的V2版本，然后通过Ingress实现V1和V2版本直接的流量灰度。如图：

我们可以看到在k8s中基于流量对灰度过程，我们需要对这些资源进行细粒度的控制，包括新版本对应资源的创建以及灰度完成之后旧版本资源的清理，对于用户来说还是比较复杂的。那么在 Knative 中，如何进行灰度发布的呢？

• 创建 Knative 服务
• 更新 Knative 服务
• 调整版本流量比例

这里我们只需要操作Knative Service服务资源，对于新变更只需要更新一下Knative Service信息（如镜像），就会自动创建一个新版本，灰度的规程只需要在Knative Service中调整对应版本的流量比例即可。如下图：

看了上面的灰度发布，我们接下来对 Knative 应用模型做进一步介绍。

应用模型

Knative 提供了极简的应用模型 - Knative Service，同时满足服务部署、服务访问以及灰度发布的能力。可以用下面的公式理解：Knative Service = 工作负载（Deployment）+服务访问(service)+灰度流量(Ingress) + 自动弹性。应用模型如图：

• Service: 对 Serverless 应用模型的抽象，通过Service 管理应用的生命周期
• configuration: 用于配置应用期望的信息。每次更新Service 就会更新Configuration
• revision: configuration的每次更新都会创建一个快照，用来做版本管理
• route: 将请求路由到Revision，并可以向不同的Revision 转发不同比例的流量

丰富的弹性策略

作为 Serverless 框架，其核心能力就是自动弹性，Knative中提供了丰富的弹性策略：

• 基于流量请求的自动扩缩容-KPA
• 基于CPU、Memory的自动扩缩容-HPA
• 支持定时 + HPA的自动扩缩容策略
• 提供事件网关满足事件精准分发策略

Knative 和 ASK 融合

这里我们先来了解一下ASK。通常的我们使用K8s，需要提前准备 IaaS 资源才能部署应用，这无疑违背了serverless的 初衷。那么我们能否摆脱IaaS的束缚， 不必提前进行IaaS资源规划呢？答案就是：ASK

ASK是阿里云推出的无服务器Kubernetes。用户无需购买节点即可直接部署容器应用，无需对集群进行节点维护和容量规划。ASK集群提供完善的Kubernetes兼容能力，同时极大降低了Kubernetes使用门槛，让用户更专注于应用程序，而不是管理底层基础设施。

• 免运维：开箱即用，无需节点管理、运维及安全维护。
• 极致弹性扩容：无需容量规划，秒级扩容，30s 扩容 500 POD实例。
• 低成本：按需创建POD，支持 spot(抢占式实例)、预留实例券
• 兼容k8s：支持deployment/statefulset/job/service/ingress/crd等
• Knative: 基于流量的应用自动弹性、缩容到保留实例
• 存储挂载：支持云盘、NAS、OSS存储卷
• Elastic Workload: 支持 eci 按量和 spot 混合调度
• 集成ARMS/SLS等云产品

Knative 运维复杂度

了解了ASK，我们接下来看一下当前Knative 自身面临的一些问题：

• Gateway 网关。Knative 社区提供Istio网关能力，但Istio组件较多，用户在管控这些组件时需要付出资源及运维成本。（虽然当前社区已经解耦了Istio， 用户可以自行选择更多轻量级的网关，但是资源及运维成本依然需要投入）
• Knative 管控组件。当前需要运维 7 个管控组件，需要用户额外投入资源及运维成本
• 冷启动问题。Serverless 绕不开应用冷启动的问题，0到1的时候需要考虑如何保证服务的快速响应。

对于上述问题，我们在ASK Knative 中提供了如下的能力。

Gateway 和 SLB 融合

通过阿里云 SLB 提供网关能力：

• 降成本：减少了十几个组件，大大降低运维成本和 IaaS 成本
• 保稳定：SLB 云产品服务更稳定、可靠性更高，易用性也更好

管控组件下沉

将 Knative 管控组件进行托管：

• 开箱即用：用户直接使用 Serverless Framework，不需要自己安装
• 免运维、低成本：Knative 组件和 K8s 集群进行融合，用户没有运维负担，也无需承担额外的资源成本
• 高管控：所有组件都在管控端部署，升级和迭代更容易

保留实例

解决从 0 到 1冷启动的问题：

• 免冷启动：通过保留实例消除了从 0  到 1 的 30 秒冷启动时间
• 成本可控：突发性能实例成本比标准规格实例降低 40% 的成本，如果和 Spot 实例结合还能再进一步降低成本

演示示例

• 在 ASK 集群中安装 Knative
• 部署 helloworld 应用并访问
• 保留实例

在 ASK 集群中安装 Knative

当前支持在创建 ASK 集群时选择安装 Knative, 也可以在ASK集群部署完成之后在应用 > Knative 中通过组件管理页签单击一键部署Knative。在已有的ASK集群部署 Knative 操作如下:

1. 登录容器服务管理控制台。
2. 在控制台左侧导航栏中，单击集群。
3. 在集群列表页面中，单击目标集群名称或者目标集群右侧操作列下的详情。
4. 在集群管理页左侧导航栏中，选择应用 > Knative。
5. 在Knative的组件管理页签单击一键部署Knative。
6. 选择需要安装的Knative组件后，单击部署。

Knative 部署完成之后，结果如图：

部署 helloworld 应用并访问

1. 登录容器服务管理控制台。
2. 在集群列表页面中，单击目标集群名称或者目标集群右侧操作列下的详情。
3. 在集群管理页左侧导航栏中，选择应用 > Knative。
4. 在服务管理页签右上角，单击创建服务。
5. 设置集群、命名空间、服务名称，选择所要使用的镜像和镜像版本等配置信息。这里我们使用 helloworld 示例镜像。

1. 单击创建。创建完成后，您可以在服务管理页签的列表中，看到新创建的服务。点击服务名称，进入服务详情页，内容如下：

1. 服务访问。

我们将域名绑定Host访问，也可以直接通过curl命令访问如下：

$ curl -H "host: helloworld-go.default.example.com" http://39.106.199.35
Hello World!

保留实例

在没有请求访问等时候（持续时间90s没有访问），会默认缩容到保留实例：

$ kubectl get po |grep hello
helloworld-go-v6z2l-deployment-754dc6c64d-89jlj                   2/2     Terminating   0          6m28s
helloworld-go-v6z2l-deployment-reserve-6bf95f6746-mq2wq           2/2     Running       0          116s

待保留实例 Ready 之后，会将正常实例下线掉。

总结

本文介绍了为什么需要Knative, Knative 核心模块 Serving , 同时通过在ASK的融合，降低Knative 运维及资源成本，最后我们通过一个示例演示了在 ASK 部署并访问 Knative 服务、缩容到保留实例。欢迎有兴趣同学关注 Knative 钉钉交流群。