使用Knative基于构建、部署、管理serverless应用

Kubernetes的主要价值在于它极大地减少了许多基础架构管理的痛苦,几乎所有主要云服务提供商(CSP)对它的广泛支持也意味着我们的应用是可移植的,但是,对于在Kubernetes之上构建解决方案的开发人员来说还是复杂的,对于初学者来说,在Kubernetes上开发,部署和管理服务的行为仍然过于复杂。尽管有许多用于记录、监控、集成的开源项目,但即使你把它们恰到好处地放在一起,在Kubernetes上进行开发还仍然很脆弱,而且过于劳动密集。

作为代码开发的原子单元的函数的日益普及进一步增加了整体复杂性,通常在两个分离的区域创建不同的开发模式:一个用于函数(FaaS),一个用于应用程序(PaaS)。

因此,今天的开发人员不得不担心与基础架构相关的问题:例如,映像构建、注册表发布、部署服务、负载平衡、日志记录、监视和扩展。但是,他们真正想要做的还是编写代码。

介绍Knative

Knative凝聚了Google的许多经验,这个开源项目也有来自Pivotal、IBM、Red Hat和SAP等公司的贡献,包括OpenWhisk、riff和Kyma这样开源的函数即服务的框架社区的合作,他们要么重新转换为Knative,要么消使用来自Knative项目的组件。

它提供了一组构建块,可在Kubernetes上实现现代的、以源码为中心的和基于容器的开发工作负载:

1. 构建  - 源码到容器的构建编排
2. 事件  - 管理和交付事件
3. 服务  - 请求驱动的计算,可以缩减到零


Knative总览
Knative基于明确分离关注点的前提,它允许开发人员和操作人员通过以自定义资源(CRD)的形式定义原始对象来负责应用的开发、部署和管理。下面是它的原始对象:

1. 配置  - 是你的服务所需的状态,包括代码和配置
2. 修订版  - 表示代码和配置的不可变时间点快照
3. 路由  - 将流量分配给服务的修订版或修订版
4. 服务  - 是所有上述对象的组合lite版本,以实现简单的用例


除了这些对象之外,Knative还定义了用于事件的主要对象......你知道,因为无服务器,Knative负责解耦事件生成者和使用者,并实现CNCF CloudEvents(v0.1)以简化事件处理。

Knative 事件结构:
1. 事件源  - 代表事件的生产者(例如GitHub)
2. 事件类型  - 描述不同事件源支持的事件类型(例如,上面提到的GitHub源的Webhook)
3. 事件消费者  - 代表你Action目标(即Knative定义的任何路线)
4. 事件feed  - 是将事件类型连接到操作的绑定或配置


Knative对象模型的这些功能实现说明Knative既易于入门,又能够解决更高级的用例,特别是当你的解决方案的复杂性增加时。

Build, deploy, manage modern serverless workloads