Knative 概述
我们先来看看 Knative 的目标。Knative 的目标是在基于 Kubernetes 之上为整个开发生命周期提供帮助。它的具体实现方式是:首先使你作为开发人员能够以你想要的语言和以你想要的方式来编写代码,其次帮助你构建和打包应用程序,最后帮助你运行和伸缩应用程序。
为此,Knative 将重点放在三个关键组件上:build(构建)你的应用程序,为其提供流量 serving(服务),以及确保应用程序能够轻松地生产和消费 event(事件)。
Build(构建)
Event(事件)
Knative 是以 Kubernetes 的一组自定义资源类型(CRD)的方式来安装的,因此只需使用几个 YAML 文件就可以轻松地开始使用 Knative 了。这也意味着,在本地或者托管云服务上,任何可以运行 Kubernetes 的地方都可以运行 Knative 和你的代码。
许多人也都同意这表示着你的代码只有在处理请求时才用到计算资源。对于很多托管服务来说,如 Amazon 的 Lambda 或 Google Cloud Functions,这意味着你只需要为活跃期间的计算服务付费,而不是一台 7x24 小时运行并可能在大部分时间内无所事事的虚拟机。在本地或非托管的无服务器架构(serverless)平台上,则表示代码可以只在需要时运行,在不需要时就停止,从而让你的基础设施能在其他方面自由使用计算资源。
在这些基础原理之上的是一场圣战。有些人坚持无服务器架构(serverless)只适合在托管的云环境中运行,在本地运行这样的平台完全是不对的。其他人则认为它更像是一种哲学理论上的设计。也许这些定义最后会合并,也许不会。就目前来说,随着无服务器架构(serverless)普及率的持续增长,Knative 最有可能成为其标准。
除了关于无服务器架构(serverless)定义的争论之外,下一个逻辑问题是“为什么创造的是 Knative ?”随着基于容器的架构的流行和 Kubernetes 的普及,我们又开始见到一些相同的问题,这些问题之前也出现在平台即服务(PaaS)方案上并推动了其发展。如在构建容器时,我们该如何保证其一致性?谁负责给所有东西打补丁?如何根据需求来伸缩?如何实现零停机部署?
虽然 Kubernetes 确实已经演进并开始解决其中一些问题,但是之前提到的关于不断发展的无服务器架构(serverless)的概念方面产生了更多的问题。如何管理多个事件类型的一致性?如何定义事件源和目标?
现在我们已经很好地理解了 Knative 是什么以及它被创造出来的原因,接下来我们将进一步深入了解它。接下来的章节将介绍 Knative 的三个关键组件。我们将详细研究它们,并解释它们是如何协同工作的,以及如何充分发挥它们的潜力。之后,我们将了解如何在 Kubernetes 集群上安装 Knative 和一些更高级的用例。最后,我们将通过一个 demo 来展示在这个报告中你能学习到的大部分内容。