Kubernetes与Serverless将在何处殊途同归

【编者的话】Kubernetes提供了Serverless所没有的优势，反之亦然，但都未能完全做到让开发人员自由的编码。我们期望它们能够在某个地点相遇，当那一天到来的时候，我们将会处在一个交叉点上，那时我们可以自由地处理代码，而不是做其他的事情。

让软件开发人员的生活变得更轻松是一个价值数十亿美元的行业，其中Kubernetes处于领先地位，AWS等公司的Serverless紧随其后。总的来说，用不相同的方法可以实现共同的目标，这个目标就是确保开发人员能够专注于他们的代码，而不必关心基础设施。

Kubernetes为了实现这一点，通过将所有内容打包到自给自足的且可在任何地方运行的容器中，这样开发人员不必担心不同环境之间的兼容性。但是，在基础设施的设置和配置方面，它涉及大量繁重的工作，因此在开始之前，你需要了解容器、Kubernetes和 Docker 以及它们是如何工作的。

Kubernetes为控制而生

根据CNCF可知，存储、安全和网络问题仍然是那些通过Kubernetes部署其架构的人们最关注的问题。这是因为采用完全基于容器的架构存在重大障碍，即使是由Kubernetes编排的架构也是如此。一个例子是，扩展不是即时的，你必须等待容器上线，在启动和运行之前，还需要处理一些重要的“管理”问题。

因此，尽管Kubernetes是一种提供“无服务器体验”的容器运行技术，但在底层，Kubernetes体系结构是具有深度基础设施意识的。这是因为在Kubernetes基础设施的基础上，假设Kubernetes中的容器位于对Kubernetes可见的机器上，至少可以说，抽象所有基础设施仍然是一个白日梦。

Serverless为简化而生

另一方面，Serverless实际上抽象了基础设施，不需要任何繁重的工作，并且实例可以按需自动运行。扩展是即时的，你根本不需要配置或提供任何东西，只需关注你的应用程序，也可随意部署。不要期望Kubernetes提供对资源的细粒度控制，这并不会很快发生。

但是Serverless也有它的局限性，它与Kubernetes提供的功能和控制相去甚远，因为所有这些都是由云供应商控制的。它还对运行时和文件大小有限制，因此对于大型数据集（如在线游戏和应用程序）来说非常不切实际，而且延迟也是一个问题。因此，虽然这两个平台都旨在从软件供应链中抽象出基础设施层，但它们将会在何处相遇呢？

Kubernetes vs Serverless

目前，将Serverless与Kubernetes进行比较仅仅是因为它们允许在不增加复杂性的情况下进行扩展。然而，这就是唯一的相似点了，容器和无服务器完全是两种不同的游戏。就目前的情况来看，在Kubernetes和Serverless之间进行选择实际上没有意义，原因有很多。

尽管两者可能有相同的最终目标，但目前都处于“生命周期”的不同阶段，而且在生产准备方面仍处于开发阶段。Kubernetes提供了Serverless替代方案所没有的优势，反之亦然。现在成功部署的关键是如何在Kubernetes和Serverless之间进行选择，并根据你的实际情况搞清楚哪个更有价值。

关于成功部署软件，两者之间的选择很大程度上取决于你需要完成什么。例如，为了快速总结每种方法的优点，如果你正在运行一个全新的应用程序，并且是从小型应用程序开始的，那么Serverless将是一个很好的选择。因为你只需要为服务器执行操作的时间付费，这样可以节省很多成本。

如前所述，Serverless会根据需求自动弹性伸缩，因此在使用率激增的情况下，无需始终将服务器作为备份运行。此外，由于所有硬件和管道都基本上是隐藏的，因此你无需具备任何基础设施经验即可编写和部署软件，从而可以更轻松地雇用人员为你工作。

除了提供明显的“可移植性”之外，容器还有自己的优点。它们还有助于避免供应商锁定，这是一个主要的独特销售主张。此外，容器为你提供了所需的对环境和基础设施的所有控制，这样你就可以随心所欲地分配资源。

Serverless容器

有一些平台希望抽象出管理容器所带来的复杂性， AWS Fargate 希望通过提供他们所谓的“serverless”容器来做到这一点。

Fargate提供了基于资源的定价和每秒计费功能，以及大量其他功能，如容器注册支持、负载平衡等等。使用Fargate，你不需要在集群中配置或扩展虚拟机来运行容器。Fargate现在可以与Amazon ECS一起使用，很快将为Kubernetes提供Amazon Elastic Container服务。

然而，它并不是真正的无服务器，尽管Docker承载了自动伸缩功能，但你仍然需要考虑如何扩展负载均衡器中的容器。你还需要在多个可用性区域中设置子网，启动多个容器，并配置Fargate来使用这些子网。它也比现在在AWS上使用ECS要贵得多。

此外，使用AWS Fargate，无论是否触发操作，容器仍然在运行。这是因为即使容器不处理数据，它们也是活动的，所以如果你启动一个容器并运行一个监听请求的节点进程，实际上那就是服务器。毫无疑问，更少的基础设施总是一件好事，但是现在就调用Fargate无服务器还为时过早，尤其与AWS Lambda相比。

Fn是另一个开源的“serverless”功能平台，它试图为容器带来无服务器架构的价值和便利。Fn项目是一个容器原生的基于Apache 2.0开原协议的无服务器平台，你可以在任何地方、任何云中或内部运行它。再次强调，这并不是真的像Lambda那样没有服务器，在Lambda中，函数在被触发之前服务器是不存在的，它还依赖于Docker。

相遇之时

我们期望Kubernetes与Serverless能够在某个地方相遇，可能就在不远的将来，在那里，Kubernetes将实现所有配置、复杂性和集群管理的抽象，或者AWS Fargate将实现对环境的“kubernets”级别的控制。自动化是伟大的，我们总是在寻找“强大的”工具，使得我们控制我们的环境。因此，我们正在寻找的是，在抽象基础设施和只给我们足够的控制权以便我们能够调整重要内容之间取得良好的平衡。

因此，在容器和无服务器方面将这两个世界的优点结合在一起在理论上听起来像是一个美梦，但这一旅程才刚刚开始。将来肯定会有一天，AWS Fargate完全负责业务流程，也会有一天Kubernetes像AWS Lambda一样运行。当那一天到来的时候，我们将会处在一个交叉点上，那时我们都可以自由地处理我们的代码，而不是做其他的事情。在那一天到来之前，Serverless和Kubernetes是两种完全不同的物种，因此要明智地选择。

原文链接： KUBERNETES AND SERVERLESS: THE POINT WHERE THEY INTERSECT

译者：Mr.lzc，软件工程师、DevOpsDays深圳核心组织者，目前供职于华为，从事云存储工作，以Cloud Native方式构建云文件系统服务，专注于K8s、微服务领域。