2018年7月,Google 在Google Cloud Next 2018上发布Knative,将其定位为基于Kubernetes的Serverless解决方案,旨在标准化Serverless,简化其学习成本。自开源以来,Knative项目备受关注,在Github上已经获得1000+的start, Pivotal、IBM、Red Hat 等公司也纷纷成为其重要的合作伙伴。本系列文章将从0到1讲解这个跨平台的Serverless编排框架的核心原理和重要实践。
在 Google Cloud Next 2018 上,谷歌发布了 Knative,将其称为“基于“Kubernetes 的平台,用来构建、部署和管理现代 serverless 工作负载”。该框架试图将构建、服务请求以及事件相关的最佳实践集合起来。Knative 是由谷歌与 Pivotal、IBM、Red Hat 和 SAP 紧密协作开发的。
Knative 提供了一组中间件组件,它们对于“构建现代、源码中心化以及基于容器的应用至关重要”。Knative 一个很重要的目标就是制定云原生、跨平台的 Serverless 编排标准。
本篇文章不做深入的技术讨论,仅从 Knative 的基本概念及诞生背景入手,让读者对 Knative 的产生初步了解。
本文把 Build 组件拆开揉碎,全面分享给读者。如果手头刚好有 K8s 集群,可以跟着文档尝试操作,整个过程甚至不需要占用一杯咖啡的时间。
前一篇 [文章](https://www.infoq.cn/article/D489mKhQ96dGwfj*w05E) 已经介绍了 Build 的使用方式和原理,本文将紧接上文介绍 Serving。
本节对 Knative 的第三大组件 Eventing 进行介绍,其解决了大部分云原生消息通信需求。
本篇文章就通过一个 Hello World 和 Knative 来一个“约会”,让你一睹 Knative 这位白富美的真容。
本文通过 Kubernetes Event Source 示例介绍 Knative Eventing 中如何获取事件,并将事件传递给 Serving 进行消费。
Build 模块提供了一套 Pipeline 机制,每一步都可执行一个动作。
Knative 社区很早就在讨论用 Tekton 替换 Build 模块,Knative Build 官方正式说明不建议使用 Knative Build 。