Knative是一个基于Kubernetes平台的开源项目，用于构建、部署和管理在云中、内部或第三方数据中心运行的无服务器工作负载。由谷歌和50多家公司的贡献开始。

Knative允许你构建基于容器和面向源代码的现代应用程序。

Knative核心项目

Knative由两部分组成：Serving和Eventing。在尝试开发Knative应用程序之前，了解它们是如何交互的是很有帮助的。

Knative Serving

Knative Serving负责围绕部署和扩展你计划部署的应用程序的功能。这还包括提供对给定主机名下的应用程序的访问的网络拓扑。

Knative Serving专注于：

——快速部署无服务器容器。

——自动缩放包括将pod缩放到零。

——支持多个网络层，如Ambassador、Contour、Kourier、Gloo和Istio，以便集成到现有环境中。

——提供已部署代码和配置的时间点快照。

Knative Eventing

Knative Eventing涵盖了无服务器应用程序的事件驱动特性。事件驱动架构基于创建事件的事件生产者和接收事件的事件使用者（或接收器）之间的解耦关系的概念。

Knative Eventing使用标准HTTP POST请求在事件生成器和接收器之间发送和接收事件。

在本文中，笔者将重点介绍Serving项目，因为它是Knative最核心的项目，有助于部署应用程序。

Serving项目

Knative Serving将一组对象定义为Kubernetes Custom Resource Definitions（CRD）。这些对象用于定义和控制无服务器工作负载在集群上的行为：

Service：Knative Service描述了路由和配置的组合，如上图所示。它是一个更高级别的实体，不提供任何附加功能。它应该使快速部署应用程序并使其可用变得更容易。你可以将服务定义为始终将流量路由到最新版本或固定版本。

Route：Route描述了如何调用特定的应用程序，以及如何在不同版本之间分配流量。根据这些场景中的用例，在任何给定的时间，系统中都很有可能有多个修订处于活动状态。路由的责任是分割流量并分配给修订。

Configuration：Configuration描述了应用程序的相应部署应该是什么样子。它在代码和配置之间提供了一个清晰的分离，并遵循 Twelve-Factor App 方法。修改配置将创建一个新版本。

Revision：Revision表示特定时间点的配置状态。因此，将从配置中创建修订。Revision是不可变的对象，你可以将其保留多久就保留多久。每个配置的多个修订可能在任何给定时间处于活动状态，并且你可以根据传入流量自动放大和缩小。

使用Knative Service部署应用程序

要编写示例Knative Service，必须运行Kubernetes集群。如果没有集群，可以使用Minikube运行本地单节点集群。集群必须至少有两个CPU和4GB RAM可用。

你还必须安装Knative Serving及其所需的依赖关系，包括带有已配置DNS的网络层。

下面是一个简单的YAML文件（称之为article.YAML），它部署了一个Knative Service：

	

		
		

			apiVersion: serving.knative.dev/v1
kind: Service
metadata:
 name: knservice
 namespace: default
spec:
 template:
   spec:
     containers:
       - image: docker.io/##DOCKERHUB_NAME##/demo
		

		

			


		

	

其中###DOCKERHUB_NAME##是dockerhub的用户名。

例如，docker.io/savita/demo。

这是一个用于创建Knative应用程序的最简YAML定义。

用户和开发人员可以根据自己的需求添加更多属性来调整YAML文件。

$ kubectl apply -f article.yaml
service.serving.knative.dev/knservice created

现在，你可以像对待任何其他Kubernetes流程一样，使用kubectl来观察不同的可用资源。

看看这项service：

$ kubectl get ksvc

NAME              URL                                                      LATESTCREATED                 LATESTREADY       READY   REASON
knservice         http://knservice.default.example.com                     knservice-00001               knservice-00001   True

你可以查看配置：

$ kubectl get configurations

NAME         LATESTCREATED     LATESTREADY       READY   REASON
knservice    knservice-00001   knservice-00001   True

还可以看到以下routes：

$ kubectl get routes

NAME          URL                                    READY   REASON
knservice     http://knservice.default.example.com   True

可以查看revision：

$ kubectl get revision

NAME                       CONFIG NAME   K8S SERVICE NAME   GENERATION   READY   REASON   ACTUAL REPLICAS   DESIRED REPLICAS

knservice-00001            knservice                        1            True             1                 1

可以看到创建的pod：

$ kubectl get pods

NAME                                          READY    STATUS     RESTARTS   AGE
knservice-00001-deployment-57f695cdc6-pbtvj   2/2      Running    0          2m1s

缩小到零

Knative的一个特性是，如果没有向应用程序发出请求，则将pod缩小到零——如果应用程序在五分钟内没有收到更多请求，就会发生这种情况。

$ kubectl get pods

No resources found in default namespace.

应用程序将缩小到零实例，不再需要任何资源。这是无服务器的核心原则之一：如果不需要资源，那么就不会消耗任何资源。

从零开始放大

一旦应用程序再次被使用（意味着请求到达应用程序），它就会立即扩展到适当数量的pod。你可以通过使用curl命令看到：

$ curl http://knservice.default.example.com
Hello Knative!

由于需要首先进行扩展，并且必须至少创建一个pod，因此在大多数情况下，请求通常会持续更长的时间。一旦成功完成，pod列表看起来就像以前一样：

$ kubectl get pods
NAME                                          READY    STATUS     RESTARTS   AGE
knservice-00001-deployment-57f695cdc6-5s55q   2/2      Running    0          3s

结论

Knative拥有无服务器框架所需的所有最佳实践。对于已经使用Kubernetes的开发人员来说，Knative是一个易于访问和理解的扩展解决方案。

本文详细展示了Knative服务是如何工作的，它如何实现所需的快速扩展，以及如何实现无服务器的功能。

原文链接：

https://opensource.com/article/21/11/knative-serving-serverless