V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
Serverlessor
V2EX  ›  Serverless

K8s 原生 Serverless 实践: ASK 与 Knative

  •  1
     
  •   Serverlessor · 212 天前 · 471 次点击
    这是一个创建于 212 天前的主题,其中的信息可能已经有所发展或是发生改变。

    头图.jpg

    作者 | 李鹏(元毅) 来源 | 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

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

    目前尚无回复
    关于   ·   帮助文档   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   2173 人在线   最高记录 5497   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 58ms · UTC 12:35 · PVG 20:35 · LAX 05:35 · JFK 08:35
    ♥ Do have faith in what you're doing.