春色满园关不住,带你体验阿里云 Knative

简介:Knative 是基于 Kubernetes 的开源 Serverless 应用编排框架。阿里云 Knative 在社区Knative基础之上,与阿里云产品进行了深度的融合,给你带来最纯粹的容器化 Serverless 体验。

Knative 是基于 Kubernetes 的开源 Serverless 应用编排框架。阿里云 Knative 在社区Knative基础之上,与阿里云产品进行了深度的融合,给你带来最纯粹的容器化 Serverless 体验。

章程

  • 关于 Knative
    • Serverless 服务引擎 - Serving
    • Serverless 事件驱动 - Eventing
  • 阿里云 Knative
    • 阿里云产品融合
    • 阿里云 K8s 生态集成
  • 一个例子

关于Knative

Knative 是基于 Kubernetes 的开源 Serverless 应用编排框架。实际上 Knative 包含的不单单是 Workload,它还有 Kubernetes 原生的流程编排引擎和完备的事件系统。 Knative 目标是基于 Kubernetes 提供应用 Serverless 工作负载编排的标准化。Knative 核心模块主要包括事件驱动框架 Eventing 和部署工作负载的 Serving。

Serverless服务引擎 - Serving

Knative Serving 核心能力就是其简洁、高效的应用托管服务,这也是其支撑Serverless 能力的基础。当然作为SeverlesssFramework 就离不开按需分配资源的能力,Knative 可以根据您应用的请求量在高峰时期自动扩容实例数,当请求量减少以后自动缩容实例数,可以非常自动化的帮助您节省成本。Serving 还提供了的流量管理能力和灵活的灰度发布能力。流量管理能力可以根据百分比切分流量,灰度发布能力可以根据流量百分比进行灰度

简单的应用模型

提供了极简的应用模型 - Knative Service,同时满足服务部署、服务访问以及灰度发布的能力。可以用下面的公式表述:Knative Service = 工作负载(Deployment)+服务访问(service)+灰度流量(Ingress)。应用模型如图:


Service: 对 Serverless 应用模型的抽象,通过Service 管理应用的生命周期

  • configuration: 用于配置应用期望的信息。每次更新Service 就会更新Configuration
  • revision: configuration的每次更新都会创建一个快照,用来做版本管理
  • route: 将请求路由到Revision,并可以向不同的Revision 转发不同比例的流量


  • 应用托管
    • Kubernetes 是面向 IaaS 管理的抽象,通过 Kubernetes 直接部署应用需要维护的资源比较多
    • 通过 Knative Service 一个资源就能定义应用的托管
  • 流量管理
    • Knative 通过 Gateway 结果应用流量,然后可以对流量按百分比进行分割,这为弹性、灰度等基础能力做好了基础
  • 灰度发布
    • 支持多版本管理,应用同时有多个版本在线提供服务很容易实现
    • 不同版本可以设置不同的流量百分比,对灰度发布等功能实现起来很容易
  • 弹性
    • Knative 帮助应用节省成本的核心能力是弹性,在流量增加的时候自动扩容,流量下降的时候自动缩容
    • 每一个灰度的版本都有自己的弹性策略,并且弹性策略和分配到当前版本的流量是相关联的。Knative 会根据分配过来的流量多少进行扩容或者缩容的决策

丰富的弹性策略

作为 Serverless 框架,其核心能力就是自动弹性,Knative中提供了丰富的弹性策略:

  • 基于流量请求的自动扩缩容-KPA
  • 基于CPU、Memory的自动扩缩容-HPA
  • 支持定时 + HPA的自动扩缩容策略
  • 事件网关,提供请求与Pod 1对1处理能力

Serverless 事件驱动框架 - Eventing

事件驱动是Serverless的标配,在Knative 同样提供了事件驱动框架-Eventing。

Knative 的 Eventing 提供了完整的事件模型,可以很容易地接入各个外部系统的事件。事件接入以后通过 CloudEvent 标准在内部流转。

在Knative Eventing提供两种事件转发方式:

  • 事件源直接转发到服务
  • 事件源转发到Broker/Trigger,然后通过过滤转发到服务

对于在使用过程中究竟应该使用哪种方式进行转发呢?其实很简单,broker/trigger模型是基于底层消息系统实现的,对于像github、gitlab、k8s apiserver这样的事件源来说,需要对消息事件进行缓冲处理、保证消息传输可靠性,那么我们建议通过事件源转发到Broker/Trigger进行事件流转。

对于事件源本身就是消息系统来说,像mns、kafka、rocketmq来说,使用事件源直接转发到服务更为高效。

讲到这里,就不得不提Knative的事件源。我把它比喻成事件驱动引擎,Knative Eventing正是通过这些事件源驱动事件流转。

Knative社区提供了丰富的事件源,如Kafka、GitHub等。此外还接入消息云产品事件源,如MNS、RocketMQ等。

阿里云Knative

阿里云 Knative 在社区原生的 Knative 之上,与阿里云资源体系进行了全方位的整合,提供了更为丰富的能力以及云产品级别的支持。

与阿里云产品融合

  • 丰富的消息云产品事件源:Kafka、MNS、RocketMQ
  • 服务访问:SLB
  • 存储:NAS、云盘等
  • 可观测性:日志服务、ARMS
  • IaaS资源:ECS、ECI

天然集成阿里云k8s生态

  • 支持阿里云标准版 Kubernentes,专有版Kubernentes
  • 支持阿里云Serverless Kubernetes(ASK), 并且在ASK中将 Knative 管控组件全托管, 为用户节省了资源以及运维成本。

一个例子

接下来以一个发送弹幕的示例来介绍一下如何玩转阿里云Knative。先看一下效果:

架构示意图

流程说明:

  • 用户通过弹幕web服务发送弹幕到阿里云kafka
  • Kafka Source事件源监听到弹幕消息,然后发送到弹幕消息处理服务
  • 弹幕消息处理服务接收到消息,然后自动弹性扩容实例进行消息处理,并将处理完成的消息发送给弹幕服务
  • 最后弹幕通过web服务界面展示给用户


具体实践活动(密透:完成有机会拿Cherry机械键盘):https://developer.aliyun.com/adc/series/ask?accounttraceid=82456b2a764b48bfa05663576c3025e8xihe

总结

最后我们总结一下阿里云 Knative 能给我们带来哪些能力:

  • 服务部署低门槛、易上手
  • Serverless 按需使用资源
  • 事件驱动与消息云产品无缝对接
  • 天然集成阿里云 K8s 生态
  • 与阿里云产品打通

希望这些能力能给你带来真正的按需使用,降低运维、资源使用成本的诉求,这也是 serverless 思想理念所追求的目标。


原文链接:https://developer.aliyun.com/article/783581?

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

你可能感兴趣的:(消息中间件,运维,Kubernetes,监控,Serverless,测试技术,Kafka,文件存储,RocketMQ,容器)