尽管Knative自2018年以来一直由社区维护，但最近一直有关于该项目的传言，因为谷歌最近将Knative提交给了云原生计算基金会(CNCF)，作为一个孵化项目考虑。

太酷了!但Knative到底是什么呢?

简单地说，Knative是一种简化和增强应用在Kubernetes上运行方式的技术。Knative本身运行在Kubernetes上，有两个主要组件:Knative serving和Knative eventing。这篇文章是关于Knative serving。

Kubernetes 很复杂

Knative 如何简化在 Kubernetes 上运行应用程序的过程？要理解这一点，您必须首先了解这一点：在 Kubernetes 上部署应用程序很复杂。您首先进行部署，最终管理许多 ReplicaSet（每个版本的应用程序一个），每个 ReplicaSet 运行一个或多个 pod，这是您的应用程序容器运行的地方，通常每个 pod 一个容器。

但是，您还需要创建一个服务，在集群内部公开您的应用程序(以便应用程序的其他部分可以访问它)，并创建一个入口，使您的应用程序在集群之外可用(以便最终用户可以访问它)。如果你想要自动伸缩，你需要制作一个HorizontalPodAutoscaler (HPA)。您还需要将配置和机密信息与应用程序分开管理。

这需要考虑很多。对于开发人员来说，这可能是一个很高的学习门槛——他们本来应该花时间专著应用程序代码。

进入Knative介绍

使用 Knative，您只需要创建一个资源——Knative 服务——然后 Knative 会为您协调一组资源，以完成我们在上面的 Kubernetes 示例中介绍的所有内容！ 此外，默认设置的方式是您可以运行您的应用程序并使用一个开箱即用的命令（或一个应用的 YAML）从外部访问它。

Knative 简化应用部署

它是如何工作的？

kn service create sunshine --image=rainbows

运行 kn service create 命令，提供您的应用程序名称、应用程序映像和任何配置（环境变量、首选端口等），Knative 将为您创建一个 Knative 服务。

Knative Service 会自动为您的 Service 创建配置和路由。 配置管理修订流，每个修订都与 Kubernetes 部署和 Knative Pod Autoscaler (KPA) 相关联。

我将暂时解释这些组件中的每一个。 但现在我想让你知道两件事：

1. 当您运行 kn service create 命令时，会为您创建所有这些对象，并且该命令会向您返回一个 URL，您可以在其中访问正在运行的应用程序。 就这么容易。
2. 除了支持 Knative 资源的 Kubernetes 资源外，您还可以查看、访问和操作 Kubernetes 集群中的所有这些 Knative 资源。 Knative 构建在 Kubernetes 之上，但它并没有掩盖它。

Knative 缩放为零

流量如何通过这些 Knative 抽象到达 Kubernetes 部署中正在运行的应用程序？

在这一点上，我们的系统只有一个修订版，所以它像这样移动：

流量通过 Knative Route 进入集群。 默认情况下，路由将 100% 的流量发送到最新版本，但这是可配置的，我们将在本文后面讨论。

Knative Pod Autoscaler (KPA) 正在监视 Revision 收到的请求数量，并将根据需要自动扩展 Kubernetes 部署中的 pod 数量。 （再次，我将深入研究一下这里有哪些修订）。

然后检查一下：当没有流量流向您的应用程序时，Knative 会将 pod 的数量缩放为零。 这是正确的！ 与 Kubernetes 不同，您需要始终运行至少一个 pod 实例才能为应用程序提供服务，而 Knative 可以扩展到零。 然后，当客户端请求访问您的应用程序时， Knative 才开始实际运行应用程序 的Pod。 这可以节省大量用于保持整年运行应用程序的费用。

带有 Knative 修订的更整洁的发布管理

正如我之前提到的，Knative Configuration 对象管理着一个修订流。 什么是 Knative 修订版？ 修订是您当前代码和配置的时间快照，包含运行该特定版本的应用程序所需的所有信息。 这与 Kubernetes 管理配置的方式不同（在我看来，更优越），与源代码分开。

您想升级您的应用程序以使用最新的容器映像吗？ 砰！ Knative 进行了新的修订。 现在您想更新应用程序的配置吗？ 砰！ 新修订。 这些修订是有序的、不可变的，并且可以无限期地持续存在。

流量拆分

使用修订管理您的版本有两个主要好处。 首先，您可以轻松地在修订之间拆分流量。 这在推出新版本时特别有用。 假设您目前有 100% 的流量流向修订版 2，并且您准备升级到更新版本，修订版 3。首先，您可以将少量流量发送到修订版 3，例如 10%。 然后您运行一些用户测试，感觉更有信心，现在将 20% 的流量发送到新应用程序。 您可以以这种方式继续，直到 100% 的流量流向修订版 3，而 0% 的流量流向修订版 2。

回滚

修订的第二个主要好处是回滚。 由于 Knative 版本代表时间快照，因此您可以跳回您喜欢的任何版本的应用程序。 如果您发现您的某个应用程序依赖项存在漏洞，您可以将流量引导回不使用该依赖项的最新版本——即使该漏洞是去年引入的并且自那时以来已经发布了 20 个版本 . 当然，使用 Kubernetes，您也可以回滚，但使用 Kubernetes，回滚可能会很复杂。 跟踪与每个版本相关的配置是一个难题，回滚超过一两个周期可能特别困难。

Knative 提供对路由和访问的细粒度控制

更重要的是，使用 Knative 的 Route 抽象，您可以设置路由以提供对完全实验性且不打算向公众公开的修订的内部访问。 你可以设置一个站点和一个内部路径来对不同的 UI 模式进行测试，或者评估一个激进的新想法的可行性。 Knative Route 组件使您可以对路由和访问进行细粒度控制。

总之，以下是 Knative Serving 的诸多好处：

• 易于部署
• 缩放为零
• 流量拆分
• 回滚
• 路线和访问