K8s 原生 Serverless 实践：ASK 与 Knative

比眉伴天荒 2022-11-15 01:25 171阅读 0赞

![头图.jpg][.jpg]

作者 | 李鹏（元毅）  
来源 | [Serverless 公众号][Serverless]

# 一、为什么需要 Knative #

![1.jpg][]

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

K8s 处在一个承上启下的位置，云原生用户使用 K8s 的目的是为了交付和管理应用，也包括灰度发布、扩容缩容等。但是对用户来说，实现这些能力，通过直接操作 K8s API 难免有些复杂。另外节省资源成本和弹性对于用户来说也越来越重要。

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

# 二、Knative简介 #

## 1. Knative 是什么 ##

*  **定义**

![2.jpg][]

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

Knative 社区当前贡献者主要有 Google、Pivotal、IBM、Red Hat，可见其阵容强大，另外还有 CloudFoundry、OpenShift 这些 PAAS 提供商也都在积极地参与 Knative 的建设。

*  **核心模块**

![3.jpg][]

Knative 核心模块主要包括两部分：事件驱动框架 Eventing 和提供工作负载的 Serving，接下来本文主要介绍 Serving 相关的一些内容。

## 2. 流量灰度发布 ##

以一个简单的场景为例：

*  **在 K8s 中实现基于流量的灰度发布**

![4.jpg][]

如果要在 K8s 中实现基于流量的灰度发布，需要创建对应的 Service 与 Deployment，弹性相关的需要 HPA 来做，然后在流量灰度发布时，要创建新的版本。

以上图为例，创始版本是 v1，要想实现流量灰度发布，我们需要创建一个新的版本 v2。创建 v2 时，要创建对应的 Service、Deployment、HPA。创建完之后通过 Ingress 设置对应的流量比例，最终实现流量灰度发布的功能。

*  **在 Knative 中实现基于流量的灰度发布**

![5.jpg][]

如上图所示，在 Knative 中想要实现基于流量的灰度发布，只需要创建一个 Knative Service，然后基于不同的版本进行灰度流量，可以用 Revision1 和 Revision2 来表示。在不同的版本里面，已经包含了自动弹性。  
   
从上面简单的两个图例，我们可以看到在 Knative 中实现流量灰度发布时，需要直接操作的资源明显较少。

## 3. Knative Serving 架构 ##

![6.jpg][]

*  \*\*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 ##

![7.jpg][]

如果要准备 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 管控组件和冷启动问题。

![8.jpg][]

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

![9.jpg][]

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

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

## 3. Gateway 和 SLB 融合 ##

![10.jpg][]

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

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

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

## 4. 管控组件下沉 ##

![11.jpg][]

对于 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][https_developer.aliyun.com_live_246126]

**作者简介：**  
李鹏，花名：元毅，阿里云容器平台高级开发工程师，2016 年加入阿里， 深度参与了阿里巴巴全面容器化、连续多年支持双十一容器化链路。专注于容器、Kubernetes、Service Mesh 和 Serverless 等云原生领域，致力于构建新一代 Serverless 平台。当前负责阿里云容器服务 Knative 相关工作。

[.jpg]: /images/20221022/3725164d905649c6bd5454522fbc45fb.png
[Serverless]: https://mp.weixin.qq.com/s/v-5MpEqKiwVpA0Xlt15qnA
[1.jpg]: https://img-blog.csdnimg.cn/img_convert/658140b9976cf60e6756775b25e28096.jpg
[2.jpg]: https://img-blog.csdnimg.cn/img_convert/56e917d4613ab0c664bb9865762a00d2.jpg
[3.jpg]: https://img-blog.csdnimg.cn/img_convert/7fab3c0411c99c3ad866ab789320e582.jpg
[4.jpg]: https://img-blog.csdnimg.cn/img_convert/ff3012a9d26bfba032512dc236230221.jpg
[5.jpg]: https://img-blog.csdnimg.cn/img_convert/d20eb20ae99f59491a9e7d6303f37c06.jpg
[6.jpg]: https://img-blog.csdnimg.cn/img_convert/fa475a46025a921995cbf991bf4ae6b0.jpg
[7.jpg]: https://img-blog.csdnimg.cn/img_convert/3d1b30fa6343d5366ef0e371aec63d6b.jpg
[8.jpg]: https://img-blog.csdnimg.cn/img_convert/c07613b1865f90ba35614bf37352b975.jpg
[9.jpg]: https://img-blog.csdnimg.cn/img_convert/38aeecf9617c3dd4343f6ac301d9002c.jpg
[10.jpg]: https://img-blog.csdnimg.cn/img_convert/f06d5d52f74de4b01dec666f11d44c7b.jpg
[11.jpg]: https://img-blog.csdnimg.cn/img_convert/d11d2329441f5b2d3e86d73cc7ea3874.jpg
[https_developer.aliyun.com_live_246126]: https://developer.aliyun.com/live/246126