Knative概述

概述

  1. Knative是一款基于Kubernetes的Serverless框架，支持基于请求的自动弹性、在没有流量时将实例数量自动缩容至零、版本管理与灰度发布等能力
  2. 在完全兼容社区Knative和Kubernetes API的基础上，ACS Knative进行了多维度的能力增强，例如通过保留实例降低冷启动时间、基于AHPA实现弹性预测等

为什么要在Kubernetes集群中使用Knative

Knative介绍

Knative是一款基于Kubernetes集群的Serverless框架，提供了云原生、跨平台的Serverless编排标准。Knative通过整合容器构建、工作负载管理以及事件模型来实现这一Serverless标准，优势如下。

  1. 更聚焦于业务逻辑：Knative通过简单的应用配置、自动扩缩容等手段让开发者聚焦于业务逻辑，降低运维负担、减少对底层资源的关注。
  2. 标准化：将业务代码部署到Serverless平台时，需要考虑源码的编译、部署和事件的管理。
    • 目前社区和云厂商提供的Serverless解决方案和FaaS方案标准不一。
    • Knative提供了一个标准、通用的Serverless框架。例如，如需在Knative中实现事件驱动，您可以编写对应的YAML文件（CR）并在集群中部署，无需与云产品做深度绑定，便于跨平台迁移。
  3. 使用门槛低：Knative支持将代码自动打包为容器镜像并发布为服务，也支持将函数快捷地部署到Kubernetes集群中，以容器的方式运行。
  4. 应用管理自动化：Knative支持在没有流量时自动将实例数量缩容至零，从而节省资源，还提供版本管理、灰度发布等功能。
  5. 事件驱动：Knative提供了完整的事件模型，便于接入外部系统的事件，并将事件路由到适当的服务或函数进行处理。

核心组件

Knative包括以下核心组件，分别执行不同的功能

  • Knative Serving：管理Serverless工作负载，提供了应用部署、多版本管理、基于请求的自动弹性、灰度发布等能力，而且在没有业务流量时可以将应用实例缩容至零。
  • Knative Eventing：提供了事件源的接入、事件注册和订阅、以及事件过滤等一整套事件管理的能力。事件模型可以有效地解耦生产者和消费者的依赖关系。
  • Knative Functions: 提供了一个简单的方式来创建、构建和部署Knative服务。您无需深入了解底层技术栈（例如Kubernetes、容器、Knative），通过使用Knative Functions，即可将无状态、事件驱动的函数作为Knative服务部署到Kubernetes集群中。

功能特性

相较于在Kubernetes集群不使用Knative，使用Knative能帮您以更简便的方式实现如下功能特性。

基于请求的自动弹性

  1. 基于CPU或者Memory的弹性有时并不能完全反映业务的真实使用情况
    • 对于Web服务来说，基于并发数（QPS）或者每秒处理请求数（RPS）进行弹性伸缩更能直接反映服务性能
    • Knative Serving会为每个Pod注入queue-proxy容器，收集容器并发数（Concurrency）或请求数（RPS）指标
    • Autoscaler定时获取指标后，会根据相应的算法自动调整Deployment的Pod数量，从而实现基于请求的自动扩缩容
  2. 如果在ACS集群中实现相应的操作，您需要分别创建Deployment、Service，配置Ingress网关，然后配置HPA参数。
    • 而使用Knative服务时，您只需要部署Knative并配置Knative服务的YAML文件。

在没有流量时将实例数量自动缩容至零

  1. Knative支持在应用无流量请求时将Pod数量自动缩容至0，并在有请求时自动扩容Pod
  2. Knative中定义了两种请求访问模式：Proxy（代理模式）和Serve（请求直达模式）
  3. 模式的切换由Autoscaler组件负责
  4. 当请求为0时，Autoscaler会将请求模式切换为Proxy模式
  5. 当有请求访问时，Autoscaler会收到通知进行扩容，扩容的Pod状态变为Ready后对请求进行转发，此时Autoscaler会将访问模式切换为Serve模式

两种请求访问模式的路径与切换时机如下（承载访问模式的底层CRD为ServerlessService，简称SKS，Autoscaler根据实例数与Ready状态切换其模式）：

  • Proxy 模式：0实例或实例未Ready时，请求经Activator代理，Activator缓冲请求并触发扩容，待Pod Ready后完成转发
  • Serve 模式：实例Ready后，Ingress网关绕过Activator，请求直达Pod内的queue-proxy，避免常驻代理层的额外开销

版本管理与灰度发布

创建Knative服务时底层会自动创建一个Configuration资源和一个Route资源。

  1. Configuration
    • 当前期望状态的配置
    • 每次更新Service就会更新Configuration，Configuration的更新会创建一个唯一的Revision
    • Revision相当于Configuration的版本管理机制
  2. Route
    • 负责将请求路由到Revision，并可以向不同的Revision转发不同比例的流量

基于以上特性，您可以使用Revision进行版本的管理，例如版本的回退。您还可以进行流量的灰度发布，例如创建了V1版本的Revision后，当版本需要变更时可以更新服务的Configuration，创建V2版本的Revision，通过Route对V1、V2设置不同的流量比例（例如V1为70%，V2是30%），那么流量会按照预设的比例进行分发。

route

事件驱动

Knative通过Eventing提供了完整的事件模型，便于接入外部系统（例如GitHub、消息队列等）的事件，并将事件路由到适当的Knative服务或函数进行处理。

为什么要使用ACS Knative

在完全兼容社区Knative并提供标准Kubernetes API接口的基础上，ACS Knative进一步增强产品化能力并提供了更丰富的产品方案。

acs-knative

  1. 产品化的能力：提供了产品化一键部署能力，您无需购买资源搭建系统。同时提供产品控制台，支持白屏化操作，降低Kubernetes集群和Knative的使用门槛
  2. 简化运维：
    • 核心组件托管：在ACS集群中，Knative的核心组件Knative Serving和Knative Eventing均由ACS创建和托管，无需您承担资源费用，且提供高可用保障
    • 网关托管：ACS Knative提供ALB、ASM和Kourier 3种网关。除社区兼容的Kourier外，其余两种云产品网关的Controller均由ACS创建，提供全托管、免运维的网关服务
  3. 生态集成
    • 无缝集成了阿里云的计算、可观测（日志服务SLS、Prometheus）、CI/CD（云效）、应用集成（EventBridge）等产品
    • 您无需自行采购服务器，也无需自建服务，便能在Knative服务中实现日志与监控告警、持续交付、事件驱动等能力
  4. 更丰富的功能特性：在社区Knative的基础上，ACS Knative结合实际业务场景提供了开箱即用的、更为丰富的产品方案。例如以下方案。
    • 保留实例
      • 在应用没有流量时，社区Knative默认将应用实例数缩容至零以降低成本，从而导致应用重新启动时会经历较长的冷启动时间
      • 如果您的应用对冷启动延时较为敏感，推荐使用此功能，保留一个低规格的突发性能实例，平衡好使用成本和启动时长
    • Knative自动伸缩
      • 除提供开箱即用的HPA、KPA（Knative Pod Autoscaler）外，您还可以为Knative服务配置AHPA（Advanced Horizontal Pod Autoscaler）弹性能力
      • 如果您的应用所需资源具备周期性变化，推荐您使用AHPA进行弹性预测，提前预热所需的资源，缓解使用Knative时遇到的冷启动问题

使用场景

ACS Knative的典型使用场景如下

Web服务的托管

  • 简化部署：ACS Knative封装了许多Kubernetes的底层细节，通过Knative服务大大简化了工作负载的部署和管理
  • 简化多版本管理：Revision机制能够确保每个修订版本都有唯一标识，便于管理不同的版本，例如版本的回滚
  • 简化流量灰度发布：ACS Knative提供流量管理功能。通过为不同Revision版本的服务分配不同的流量比例，可以快速实现灰度发布、A/B测试等

Serverless应用

  • 聚焦业务逻辑：开发者无需关心IaaS资源，只需关注业务逻辑的开发，应用配置也大大简化，降低底层基础设施的运维成本。
  • 资源按需使用、自动弹性：ACS Knative可以根据流量请求和并发情况自动扩缩资源，当没有业务流量时还可以将实例数量缩减至零，节省资源和成本。

AI场景

  • 聚焦业务逻辑：GPU等异构计算场景下，开发者无需关心底层基础设施的维护，只需关注AI任务的构建和部署。
  • 资源按需使用、自动弹性：ACS Knative可以根据实际负载情况自动扩缩资源，针对负载具有波动性的推理服务能够有效降低资源使用成本。
  • 可移植性：ACS Knative可以运行在任何兼容Kubernetes的环境中，Knative服务可以在云上、本地数据中心甚至是边缘设备上移植部署。

事件驱动场景

  • Knative Eventing提供了完整的事件模型，简化了接入外部系统的事件的流程。
  • 例如，IoT设备可以将传感器数据发送到Knative服务中，ACS Knative可以配置对应的事件源用于接收数据，并触发相应的处理逻辑，例如数据存储、实时分析、监控告警等。

ACS Knative的使用流程

前提条件

  1. 已在ACS集群中部署Knative
  2. 在控制台一键部署ACS Knative，安装Knative Serving组件
  3. 完成网关选型并部署网关。ACS Knative支持ALB、ASM、Kourier三种网关
    • ALB：基于阿里云ALB提供了更为强大的Ingress流量管理方式，全托管免运维，且支持自动弹性能力
    • ASM：统一管理微服务应用流量、兼容Istio的托管式平台
      • 通过流量控制、网格观测以及服务间通信安全等功能，简化您的服务治理，并为运行在异构计算基础设施上的服务提供统一的管理能力
    • Kourier：基于Envoy架构实现的一款Knative社区开源的轻量级网关

服务部署与管理

自动伸缩

  1. 基于流量请求数（QPS）实现服务的自动扩缩容KPA（Knative Pod Autoscaler）
  2. 配置AHPA（Advanced Horizontal Pod Autoscaler），既可以根据历史指标弹性预测未来负载的情况并提前准备扩缩容，又能够结合Cron表达式实现定时扩缩
  3. 配置基于CPU指标阈值的HPA

版本管理与灰度发布

  1. 基于Revision修订版本实现版本的管理，例如版本的回滚
  2. 基于Revision版本，根据流量百分比灰度发布服务

Knative服务的访问

  1. Knative服务的默认域名格式为{route}.{namespace}.{default-example.com}，其中{default-example.com}是默认的域名后缀，您可以自定义域名后缀
  2. 使用自定义域名时，推荐为自定义域名配置一个HTTPS证书，提高数据传输的安全性
  3. 配置探针（存活探针（Liveness Probe）和就绪探针（Readiness Probe）），监测和管理服务的健康状况和可用性

进阶功能

事件驱动

  1. 在满足云原生开发的常见需求的基础上，Knative Eventing提供了完整、系统的Serverless事件驱动模式，
    • 包括外部事件源的接入、事件流转和订阅、以及对事件的过滤等功能
  2. ACS Knative直接丰富的事件源，包括GitHub、EventBridge等

Knative Functions

简化在Kubernetes集群中创建、部署和调用函数的流程

AI推理服务

  1. KServe提供了一个基于Kubernetes集群的机器学习模型服务框架，提供简单的Kubernetes CRD
  2. 可将单个或多个经过训练的模型（例如TFServing、TorchServe、Triton等推理服务器）部署到模型服务运行时

服务网格

如果您需要在Knative服务中集成服务网格，以实现复杂的流量管理并增强服务安全性，推荐您使用服务网格ASM

可观测性与成本管理

监控大盘

您可以把Knative接入阿里云Prometheus监控，便于查看Knative的响应延迟、请求并发数等数据

相关计费

在ACS集群中使用ACS Knative时，ACS Knative本身不收取管理费用，但在使用过程中产生的负载均衡实例、NAT网关等，按照相应资源的价格计费