乐趣区

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

jiezi

作者 | 元毅

导读：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 思维理念所谋求的指标。

退出移动版