云计算

https://murphy.blog.csdn.net/article/details/127846026

Serverless

Knative

Knative 是谷歌牵头发起的 Serverless 项目。
其目标是基于 Kubernetes 的 Serverless 解决方案，旨在标准化 Serverless，简化其学习成本。

Knative 是以 Kubernetes 的一组自定义资源类型（CRD）的方式来安装的，因此只需使用几个 YAML 文件就可以轻松地开始使用 Knative 了。
这也意味着，在本地或者托管云服务上，任何可以运行 Kubernetes 的地方都可以运行 Knative 和代码。

Knative的定位

Knative构建在Kubernetes、Istio、Container的基础上，以K8S的CRD形式存在。

  • 基础设施：Kubernetes作为基础设施进行容器编排，解决应用编排和运行环境
  • 通信设施：Isito作为通信基础设施层，保证服务的运行可检测、可配置、可追踪
  • 模板+环境：Knative使用应用模板和统一的运行环境来标准化服务的构建、部署和管理

Knative 解决了现在Serverless 的诸多问题。
如果kubernetes是容器编排的事实上的标准，那么Knative也许就是未来serverless的事实上的标准。

Knative的优势：

  • 便利性：Knative 以 Kubernetes 作为其底层框架，因此无论是线上还是线下，任何 Kubernetes 集群，无论是云上 Kubernetes 服务还是自建 Kubernetes 集群，都可通过安装 knative 插件快速的搭建 serverless 平台。
  • 标准化：Knative 联合 CNCF，把所有事件标准化，统一为 CloudEvent，提供事件的跨平台，同时让函数和具体的调用方能够解耦。
  • 服务间解耦：使用 Knative 使得应用不在与底层依赖服务强绑定，可以跨云实现业务互通。
  • 成熟的生态：Knative 基于 Kubernetes 体系构建，与 kubernetes 生态结合更紧密。
  • 自动伸缩：监控应用的请求，并自动扩缩容, 借助于istio(ambassador,gloo等)天生支持蓝绿发布、回滚功能，方便应用发布流程。
  • 应用监控：支持日志的收集、查找和分析，并支持 VAmetrics 数据展示、调用关系 tracing。

Knative的组成

为了实现 serverless 应用的管理，knative 把整个系统分成了三个部分：

  • Build：构建模块，把用户定义的函数和应用 build 成容器镜像，提供云原生“从源代码到容器”的镜像构建能力。
  • Serving：服务模块，用来配置应用的路由、升级策略、自动扩缩容等功能，通过 Serving 部署容器并提供通用的服务模型。
  • Eventing：事件模块，用来自动完成事件的绑定和触发，提供事件全局订阅、传递和管理能力，实现事件驱动。

Build 构建模块

Serving 服务模块

基于负载自动伸缩，包括在没有负载时缩减到零。
允许为多个修订版本（revision）应用创建流量策略，从而能够通过 URL 轻松路由到目标应用程序。

knative serving 功能是基于 kubernetes 和 istio 开发的。可以认为 knative 提供了更高的抽象，自动封装掉了 kubernetes 和 istio 的实现细节。

  • kubernetes 来管理容器（deployment、pod）
  • istio 来管理网络路由（VirtualService、DestinationRule）

serving 的核心功能是让应用运行起来提供服务。
虽然听起来很简单，但包括了很多的事情：

  • 自动化启动和销毁容器
  • 根据名字生成网络访问相关的 service、ingress 等对象
  • 监控应用的请求，并自动扩缩容
  • 支持蓝绿发布、回滚功能，方便应用方法流程

Eventing 事件模块

使得生产和消费事件变得容易。
抽象出事件源，并允许操作人员使用自己选择的消息传递层。

serverless 最重要的是基于事件的触发机制，也就是说当某件事发生时，就触发某个特定的函数。

事件概念的出现，让函数和具体的调用方能够解耦。
函数部署出来不用关心谁会调用它，而事件源触发也不用关心谁会处理它。

为了让整个事件系统更有扩展性和通用性，knative 定义了很多事件相关的概念。简单介绍一下：

  • EventSource：事件源，能够产生事件的外部系统。
  • Feed：把某种类型的 EventType 和 EventSource 和对应的 Channel 绑定到一起。
  • Channel：对消息实现的一层抽象，后端可以使用 kafka、RabbitMQ、Google PubSub 作为具体的实现。
  • Subscription：把 channel 和后端的函数绑定到一起，一个 channel 可以绑定到多个knative service。

https://skyao.io/learning-knative/introduction/motivation.html
https://www.bookstack.cn/read/getting-started-with-knative/eventing.md

Knative - Eventing

Kubernetes 用户在实现开发和部署阶段服务之间松耦合的同时，服务间常要通过不同的事件机制来进行事件传递，为了解决大部分的云原生消息通信需求，Knative 提供了 Eventing 组件。

Eventing 主要由事件源（Event Source）、事件处理（Flow）、事件消费者（Event Consumer）三部分构成。

  • 事件源 Event Source
  • 事件处理 Flow
    • Source to Service，直接事件接收
      通过事件源直接转发到单一事件消费者。支持直接调用 Knative Service 或者 Kubernetes Service 进行消费处理。这样的场景下，如果调用的服务不可用，事件源负责重试机制处理。
    • Channels & Subscriptions，通过事件通道(Channel)以及事件订阅(Subscriptions)转发事件处理
      这样的情况下，可以通过 Channel 保证事件不丢失并进行缓冲处理，通过 Subscriptions 订阅事件以满足多个消费端处理。
    • Brokers & Triggers，通过 brokers 和 triggers 支持事件消费及过滤机制
      从 v0.5 开始，Knative Eventing 定义 Broker 和 Trigger 对象，实现了对事件进行过滤（亦如通过 ingress 和 ingress controller 对网络流量的过滤一样）。
      通过定义 Broker 创建 Channel，通过 Trigger 创建 Channel 的订阅（subscription），并产生事件过滤规则。
  • 事件消费者 Event Consumer

Event Source

事件源是 Kubernetes 自定义资源，它提供了一种机制用于注册特定软件系统对某一类事件的兴趣。

Event Registry

Event Registry 维护着一个事件类型目录，这些事件可以从不同Broker中消费。
Event Registry 引入了一个新的 EventType CRD，以便将事件类型的信息持久化在集群的数据存储中。

利用Registry发现事件：使用Registry，可以发现能够从Broker的事件网格中消费的不同类型的事件。该Registry是为与Broker/Trigger模型一起使用而设计的，旨在帮助创建Triggers。

Broker & Trigger

  • Broker

    Broker代表了 “Event Mesh”。事件被发送到Broker的入口（Ingress），然后被发送到对该事件感兴趣的任何订阅者。一旦进入Broker，除CloudEvent之外的所有元数据都会被剥离（例如，除非设置为CloudEvent属性，否则没有该事件如何进入Broker的概念）。
  • Trigger
    Trigger 代表了从特定的Broker订阅事件的愿望。

Channel

Channels是Kubernetes Custom Resources(k8s自定义资源)，它定义了一个单一的事件转发和持久层。
消息实现可以通过Kubernetes Custom Resource提供Channel的实现，支持不同的技术，如Apache Kafka或NATS Streaming。