做者 | 李鹏（元毅） 来源 | Serverless 公众号安全
1、为何须要 Knative
K8s 目前已成为云原生市场上的主流操做系统，K8s 对上经过数据抽象暴露基础设施能力，好比 Service、Ingress、Pod、Deployment 等，这些都是经过 K8s 原生 API 给用户暴露出来的能力；而对下 K8s 提供了基础设施接入的一些标准接口，好比 CNI、CRI、CRD，让云资源以一个标准化的方式进入到 K8s 的体系中。服务器
K8s 处在一个承上启下的位置，云原生用户使用 K8s 的目的是为了交付和管理应用，也包括灰度发布、扩容缩容等。可是对用户来讲，实现这些能力，经过直接操做 K8s API 不免有些复杂。另外节省资源成本和弹性对于用户来讲也愈来愈重要。架构
那么，如何才能简单地使用 K8s 的技术，而且实现按需使用，最终实现降本增效的目的呢？答案就是 Knative。框架
2、Knative简介
1. Knative 是什么
- 定义
Knative 是一款基于 Kubernetes 的 Serverless 编排引擎，Knative 一个很重要的目标是制定云原生跨平台的编排标准，它经过整合容器构建、工做负载以及事件驱动来实现这一目的。less
Knative 社区当前贡献者主要有 Google、Pivotal、IBM、Red Hat，可见其阵容强大，另外还有 CloudFoundry、OpenShift 这些 PAAS 提供商也都在积极地参与 Knative 的建设。运维
- 核心模块
Knative 核心模块主要包括两部分：事件驱动框架 Eventing 和提供工做负载的 Serving，接下来本文主要介绍 Serving 相关的一些内容。性能
2. 流量灰度发布
以一个简单的场景为例：阿里云
- 在 K8s 中实现基于流量的灰度发布
若是要在 K8s 中实现基于流量的灰度发布，须要建立对应的 Service 与 Deployment，弹性相关的须要 HPA 来作，而后在流量灰度发布时，要建立新的版本。url
以上图为例，创始版本是 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 的自动扩缩容策略；
- 事件网关（基于流量请求的精准弹性）。
3、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 实例结合还能再进一步下降成本。
4、实操演示
最后进行动手实践演示，以一家咖啡店（cafe）为例，演示内容主要有：
- 在 ASK 集群中安装 Knative；
- 部署 coffee 服务；
- 访问 coffee 服务；
- 保留实例。
演示过程观看连接：https://developer.aliyun.com/live/246126
做者简介： 李鹏，花名：元毅，阿里云容器平台高级开发工程师，2016 年加入阿里， 深度参与了阿里巴巴全面容器化、连续多年支持双十一容器化链路。专一于容器、Kubernetes、Service Mesh 和 Serverless 等云原生领域，致力于构建新一代 Serverless 平台。当前负责阿里云容器服务 Knative 相关工做。