关于云原生-cloud-native:春色满园关不住带你体验阿里云-Knative

34次阅读

共计 2550 个字符,预计需要花费 7 分钟才能阅读完成。

作者 | 元毅

导读:Knative 是基于 Kubernetes 的开源 Serverless 利用编排框架。阿里云 Knative 在社区 Knative 根底之上,与阿里云产品进行了深度的交融,给你带来最纯正的容器化 Serverless 体验。

对于 Knative

Knative 是基于 Kubernetes 的开源 Serverless 利用编排框架。实际上 Knative 蕴含的不单单是 Workload,它还有 Kubernetes 原生的流程编排引擎和齐备的事件零碎。Knative 指标是基于 Kubernetes 提供利用 Serverless 工作负载编排的标准化。Knative 外围模块次要包含事件驱动框架 Eventing 和部署工作负载的 Serving。

1. Serverless 服务引擎 – Serving

Knative Serving 外围能力就是其简洁、高效的利用托管服务,这也是其撑持 Serverless 能力的根底。当然作为 Serverless Framework 就离不开按需分配资源的能力,Knative 能够依据利用的申请量在顶峰期间主动扩容实例数,当申请量减少当前主动缩容实例数,能够十分自动化地帮忙您节省成本。

Serving 还提供了流量治理能力和灵便的灰度公布能力。流量治理能力能够依据百分比切分流量,灰度公布能力能够依据流量百分比进行灰度。

1)简略的利用模型

提供了极简的利用模型 – 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 会依据调配过去的流量多少进行扩容或者缩容的决策。

2)丰盛的弹性策略


作为 Serverless 框架,其外围能力就是主动弹性,Knative 中提供了丰盛的弹性策略:

  • 基于流量申请的主动扩缩容 – KPA
  • 基于 CPU、Memory 的主动扩缩容 – HPA
  • 反对定时 + HPA 的主动扩缩容策略
  • 事件网关,提供申请与 Pod 1 对 1 解决能力

2. 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 之上,与阿里云资源体系进行了全方位的整合,提供了更为丰盛的能力以及云产品级别的反对。

1. 与阿里云产品交融

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

2. 人造集成阿里云 K8s 生态

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

一个例子


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

架构示意图:

流程阐明:

  • 用户通过弹幕 Web 服务发送弹幕到阿里云 Kafka;
  • Kafka Source 事件源监听到弹幕音讯,而后发送到弹幕音讯解决服务;
  • 弹幕音讯解决服务接管到音讯,而后主动弹性扩容实例进行音讯解决,并将解决实现的音讯发送给弹幕服务;
  • 最初弹幕通过 Web 服务界面展现给用户;

总结


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

  • 服务部署低门槛、易上手
  • Serverless 按需应用资源
  • 事件驱动与音讯云产品无缝对接
  • 人造集成阿里云 K8s 生态
  • 与阿里云产品买通

心愿这些能力能给你带来真正的按需应用,升高运维、资源应用老本的诉求,这也是 Serverless 思维理念所谋求的指标。

正文完
 0