我们探索直接且与工具无关的方式使Kubernetes无服务器

本文是关于什么的

· 您刻苦学习的Kubernetes知识是否会因无服务器而变得过时，并且浪费了3年的生命？

· 如何在不使云提供商陷入困境的情况下使用无服务器？

· 这不是特定工具的比较，而是一般性想法

TL; DR

Kubernetes上的无服务器技术以一种独立于云提供商的方式减少了重复配置。 这只是不断地使手动工作自动化的结果。

在谈论Kubernetes上的无服务器时，我们需要考虑两个不同的领域：

· 在集群中无服务器地部署应用程序（减少每个应用程序+自动构建容器所需的YAML文件数）

· 在没有服务器的情况下运行Pod的容器而无需服务器

无服务器

简而言之：您无需与运行应用程序所需的服务器和基础架构进行交互或进行较少的交互。 今天，当使用"无服务器"一词时，它可以指向两种不同的事物：CaaS和FaaS。

CaaS —容器即服务

您创建（Docker）容器，将其扔到CaaS上，然后它会自动运行，服务和缩放。

托管示例包括Azure容器实例，Google Cloud Run或AWS Fargate。

FaaS —服务即功能

您编写代码，将其扔到FaaS上，它将自动运行，服务和缩放。

托管示例包括Azure Functions，Google Functions或AWS Lambda。

FaaS实施

FaaS如何运行代码的方式可能不同。 一种方式是FaaS实际上为每次代码更改构建一个容器，然后使用如下CaaS：

> FaaS building a container and sending it to CaaS

另一种方式可能是FaaS在引导过程中将功能的源代码动态地拉入预定义的环境（容器）中。 环境将适用于不同的语言。 当使用必须像Go一样编译的语言时，那么在引导过程中也必须完成编译。

活动/扩展

FaaS通常在与事件系统结合使用时触发事件的功能实例化。 事件可以源自API网关，Github，Kafka，RabbitMQ，CronJobs等。

> the FaaS encapsulates communication with event sources

对于每个事件，将创建一个新函数来处理它。 如果同时发生多个事件，则将创建多个实例来处理这些事件。 这样我们就可以自动缩放。

FaaS与各种事件源进行通信，因此功能本身不必如此。 它们只需要使用FaaS使用的一种事件格式，例如CloudEvents或通过HTTP传输。

>

有一个CloudEvents项目，它以"标准"形式描述了事件的结构和元数据。 它还包括数据和描述该数据的模式。 云事件是包裹事件数据的信封。 如果被许多供应商采用以实现互操作性，这可能会很棒。

Kubernetes应用

让我们看一下开发在Kubernetes上运行的传统非无服务器应用程序所需的步骤：

> quite a bit of manual "server" interactions necessary

我们需要构建一个容器，创建各种Kubernetes资源（YAML文件），然后确定运行我们的应用程序需要多少个工作节点。

通过配置群集/节点自动缩放器，可以更动态地处理我们需要多少个工作节点的决定。 尽管即使那样，我们仍然必须对其进行配置，并且需要设置最小+最大数量的节点。

我们使用这种传统方法与"服务器"进行了很多交互。 首先创建/构建容器，然后编写YAML文件，然后定义节点的数量和资源。

Kubernetes无服务器应用程序

现在，让我们探索为Kubernetes开发应用程序时的无服务器方法。

CaaS —容器即服务

> we reduced the creation of a lot of YAML files

在这里，我们减少了要创建的Kubernetes资源（YAML文件）的数量。 CaaS将为我们创建所有必要的子资源，例如自动缩放器，Ingress或Istio路由。

我们要做的就是提供一个（Docker）容器并创建一个单一的k8s资源，即通过CRD引入的CaaS容器资源。 CaaS可以根据事件或我们的定义来决定何时启动我们的应用程序实例以及多少实例。

我们必须确保我们构建的容器可以接收和处理来自CaaS的事件，例如可以通过HTTP或CloudEvents。 这可能需要容器内的某些库。

CaaS示例：Knative（Knative提供了其他解决方案可以使用和依赖的灵活构建基块）。

FaaS —服务即功能

> we now also automate the build process and maybe have a nice FaaS webinterface

FaaS function.yml将包含通过CRD引入的FaaS系统中的一个K8s资源。 在该资源中，我们设置了诸如函数名称，源代码位置，语言运行时和触发事件之类的内容。

如果我们通过网络界面上传代码，则无需创建FaaS函数。yaml。 但是将函数保留为代码应该是一种好习惯。 Web界面非常适合原型设计或测试修改。

借助FaaS，我们还可以获得CaaS解决方案所提供的一切。 但是现在，我们进一步减少了工作量，因为我们在Kubernetes集群中运行了可以直接执行/构建应用程序源代码的工具。

为我们构建的容器已经包含必要的库，例如HTTP或CloudEvents，以从FaaS接收事件。 我们不必为此担心。

源可能存储在Git存储库中，可以通过Web界面上传，也可以在其他地方使用。 FaaS将访问代码，侦听更改，构建容器，然后将其传递给CaaS以服务最终事件。

> example webinterface of TriggerMesh to upload code and deploy as a function

FaaS示例：

· TriggerMesh（使用Knative作为CaaS）

· OpenFaaS

· 无核

· 裂变（与环境而不是不变的功能容器一起使用，更进一步）

· OpenWhisk

· 各种K8 FaaS的概述和比较

冷暖启动

冷启动意味着没有任何Pod正在运行来处理事件，因此创建它会花费一些时间。 通常，这些吊舱在最后使用后会存活一段时间，并且可以重复使用。 在"已经运行"期间的调用将被称为热启动。 暖启动更快，但也浪费资源。

基于裂变/环境的FaaS

> Fission architecture (source)

K8s FaaS的一个例子Fission实际上并没有为每个函数的代码更改构建不可变的容器，而是使用了可变环境容器（"通用容器"）的思想，该容器动态地拉入代码，然后将其转换为"特定功能容器"。 我认为这也是AWS Lambda运作的方式。

可观察性

从容器化微服务转移到功能可能导致必须管理比以前更多和更少的服务。 这是由于易于创建仅侦听和处理单个事件的小功能而引起的。 当我与第1部分中的Container Microservices和第2部分中的AWS Serverless创建相同的演示应用程序时，我自己注意到了这一点。

要管理大量的服务或功能，必须保持可观察性（度量，日志记录，跟踪）。 这就是为什么大多数Kubernetes FaaS和CaaS已经与Prometheus，Jaeger和Istio或Linkerd之类的服务网格进行集成的原因。

Kubernetes无服务器节点

在上一节中，我们讨论了K8的无服务器应用程序，并且看到了使用CaaS或FaaS时的工作流程。 这些简化了流程并大大减少了重复工作。

但是开发人员或操作员仍在与服务器交互：用作群集中工作节点的VM。 他们仍然需要指定要拥有多少个节点及其资源（CPU /内存）。

现在，我们进一步迈出了一步，使用虚拟Kubelet使实际的基础Kubernetes底层节点无服务器。

> FaaS on top of Kubernetes with Virtual Kubelet as nodes. The ultimate setup?

虚拟Kubelet模拟了Kubernetes的工作节点，然后可以像其他任何普通节点一样使用该节点调度Pod。 尽管Pod的容器未在VM上运行，但是在无服务器容器的云提供商中提供，例如AWS Fargate，Google Cloud Run或Azure容器实例。

在我有关虚拟Kubelet的详细文章中阅读更多内容。

K8的无服务器应用程序和Kubernetes的K8的无服务器节点的结合可能是一个强大的工具。 但是，如果我们无所事事，为什么还要使用K8呢？

为什么仍然使用Kubernetes？

> sorry, I was in the mood for a goofy image O:)

Kubernetes提供了强大而灵活的构建块，而不是为了方便交互和最终用户而构建的。 这使得K8变得复杂，并且在直接使用时需要大量重复工作。

Kubernetes成为独立于云提供商的标准。 在无服务器时使用无服务器框架是最重要的，以保持这种独立性。 如有必要，我们总是可以更详细地定义我们的应用程序，因为它仍在后台运行K8。

通过在K8上使用无服务器，我们可以大大减少重复工作，从而使我们可以花更多的时间来构建实际的应用程序。

概括

> traditional

> serverless

结论

我认为现代的无服务器事件驱动架构已经证明了自己，并将在未来几年中越来越流行。 让我们继续在诸如K8之类的开放标准之上使用它，以确保更好的互操作性。

Kubernetes上的无服务器只是不断地使手动工作自动化的结果。

资料来源

· 互联网。

· Kubernetes无服务器框架的快速比较

· Gitlab使用Knative和Triggermesh提供无服务器应用程序

· Google Cloud Run在后台使用Knative

· Kubeless和TriggerMesh创作者的精彩视频

6.关于Kubernetes，Serverless和OpenWhisk的另一个精彩视频

(本文翻译自Kim Wuestkamp的文章《Kubernetes Serverless simply visually explained》，参考：)