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