简介： K8s 处在一个承上启下的位置，云原生用户使用 K8s 的目的是为了交付和管理应用，也包括灰度发布、扩容缩容等。但是对用户来说，实现这些能力，通过直接操作 K8s API 难免有些复杂。另外节省资源成本和弹性对于用户来说也越来越重要。那么，如何才能简单地使用 K8s 的技术，并且实现按需使用，最终实现降本增效的目的呢？答案就是 Knative。
作者 | *（元毅）
来源 | 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 相关工作。