| owner | reviewer | description | publishDate | updateDate | |||||
|---|---|---|---|---|---|---|---|---|---|
|
|
本章是全书的第一章，主要用来介绍 Knative。 |
2019-03-05 |
2019-03-10 |
我们有一个信念：以平台的方式提供软件是一个最佳选择。事实证明，标准化的开发和部署流程能让开发人员更专注于新功能的研发，从而减少时间和金钱上的消耗。不仅如此，确保应用程序之间的一致性也意味着其更容易打补丁、更新和监控，从而让运维工作也更加高效。Knative 的目标就是成为这样的现代化平台。
我们先来看看 Knative 的目标。Knative 的目标是在基于 Kubernetes 之上为整个开发生命周期提供帮助。它的具体实现方式是：首先使你作为开发人员能够以你想要的语言和以你想要的方式来编写代码，其次帮助你构建和打包应用程序，最后帮助你运行和伸缩应用程序。
为此，Knative 将重点放在三个关键组件上：*build（构建）*你的应用程序，为其提供流量 serving（服务），以及确保应用程序能够轻松地生产和消费 event（事件）。
Build（构建）
通过灵活的插件化的构建系统将用户源代码构建成容器。目前已经支持多个构建系统，比如 Google 的 Kaniko，它无需运行 Docker daemon 就可以在 Kubernetes 集群上构建容器镜像。
Serving（服务）
基于负载自动伸缩，包括在没有负载时缩减到零。允许你为多个修订版本（revision）应用创建流量策略，从而能够通过 URL 轻松路由到目标应用程序。
Event（事件）
使得生产和消费事件变得容易。抽象出事件源，并允许操作人员使用自己选择的消息传递层。
Knative 是以 Kubernetes 的一组自定义资源类型（CRD）的方式来安装的，因此只需使用几个 YAML 文件就可以轻松地开始使用 Knative 了。这也意味着，在本地或者托管云服务上，任何可以运行 Kubernetes 的地方都可以运行 Knative 和你的代码。
| Kubernetes 知识 |
|---|
| 由于 Knative 是基于 Kubernetes 的一系列扩展，因此建议你先了解下 Kubernetes 和 Docker 的架构和术语。今后我们会提及以下术语，比如 namespace、Deployment、ReplicaSet 和 Pod。熟悉这些 Kubernetes 术语将帮助你在阅读时更好地理解 Knative 的基本工作。如果你对这些都不熟悉，那么这两个链接：Kubernetes 和 Docker 上都有很棒的培训材料，可以直接在浏览器上阅读。 |
到目前为止，我们已经讨论了应用程序的容器化。但都 2019 年了，我们读了半章却还没有提到“无服务器架构（serverless）”这个词。也许作为当今技术中被提到最多的一个词，无服务器架构（serverless）仍然在寻找一个整个行业都能认同的定义。许多人都同意这个理念的影响最大的是代码量，比如以前需要编写大型、单一的应用程序，现在你只需编写通过事件来调用的小型、单一用途的函数即可。这些事件可以简单到是一个 HTTP 请求或一个来自消息通道（如 Apache Kafka）的消息。同时事件也可能是间接的，比如这些操作：将图片上传到 Google Cloud Storage 或更新了 Amazon 的 DynamoDB 中的一张表。
许多人也都同意这表示着你的代码只有在处理请求时才用到计算资源。对于很多托管服务来说，如 Amazon 的 Lambda 或 Google Cloud Functions，这意味着你只需要为活跃期间的计算服务付费，而不是一台 7x24 小时运行并可能在大部分时间内无所事事的虚拟机。在本地或非托管的无服务器架构（serverless）平台上，则表示代码可以只在需要时运行，在不需要时就停止，从而让你的基础设施能在其他方面自由使用计算资源。
在这些基础原理之上的是一场圣战。有些人坚持无服务器架构（serverless）只适合在托管的云环境中运行，在本地运行这样的平台完全是不对的。其他人则认为它更像是一种哲学理论上的设计。也许这些定义最后会合并，也许不会。就目前来说，随着无服务器架构（serverless）普及率的持续增长，Knative 最有可能成为其标准。
除了关于无服务器架构（serverless）定义的争论之外，下一个逻辑问题是“为什么创造的是 Knative ？”随着基于容器的架构的流行和 Kubernetes 的普及，我们又开始见到一些相同的问题，这些问题之前也出现在平台即服务（PaaS）方案上并推动了其发展。如在构建容器时，我们该如何保证其一致性？谁负责给所有东西打补丁？如何根据需求来伸缩？如何实现零停机部署？
虽然 Kubernetes 确实已经演进并开始解决其中一些问题，但是之前提到的关于不断发展的无服务器架构（serverless）的概念方面产生了更多的问题。如何管理多个事件类型的一致性？如何定义事件源和目标？
许多无服务器架构（serverless）或函数即服务（FaaS）框架都尝试回答这些问题，但它们都在用不同的方式来解决问题，且不是所有的解决方案都用到了 Kubernetes。而 Knative 构建在 Kubernetes 的基础上，并为构建和部署无服务器架构（serverless）和基于事件驱动的应用程序提供了一致的标准模式。Knative 减少了这种新的软件开发方法所产生的开销，同时还把路由（routing）和事件（eventing）的复杂性抽象出来。
现在我们已经很好地理解了 Knative 是什么以及它被创造出来的原因，接下来我们将进一步深入了解它。接下来的章节将介绍 Knative 的三个关键组件。我们将详细研究它们，并解释它们是如何协同工作的，以及如何充分发挥它们的潜力。之后，我们将了解如何在 Kubernetes 集群上安装 Knative 和一些更高级的用例。最后，我们将通过一个 demo 来展示在这个报告中你能学习到的大部分内容。