现在，Kubernetes 已基本上成为容器编排的代名词，所有竞争者要么被吸收（或者被重写为基于 Kubernetes，参见 Openshift），要么基本上消失在空虚之中（抱歉，Nomad）。这是否意味着发展现在将放缓？还是它仅仅是某些更大事件的开端？或许 Kubernetes 正处于成为通用名称的风口浪尖，就像 Kleenex 一样，或者像“使用谷歌搜索”这样的动词一样。
译自Kubernetes: Future or Fad?，作者 Chris Engelbert。
多年前，有人在一次采访中问我如何看待 Docker，以及我是否看好容器化的未来。当时我很快给出了一个便捷的答案。首先，容器化并不是一个新概念。BSD、Solaris 以及其他系统多年前就已经使用这种方式。但当时，对于 Linux 来说它们还是一种新兴事物（至少在广泛普及方面），因此将会长期存在。这是虚拟化的下一个合乎逻辑的演化步骤。但至少在我的脑海中，Docker 是不同的。对于 Docker，我的简单回答是“它是我们目前拥有的最佳工具，但我希望它不是最终的解决方案。”Docker 现在正在全面普及，我们今天使用的工具一致基于开放容器计划 (OCI) 定义的规范及其 OCI 镜像格式。
那么，Kubernetes 的未来将如何发展？它会继续存在还是会走向灭亡，继而“成为被其他东西取代的另一个平台”，正如Michael Levan在《Kubernetes 的未来》中所写的那样。
开玩笑地说，在字典中查找容器编排时，你可能会找到同义词 Kubernetes，但 Kubernetes 花了大约十年的时间才走到今天。
Kubernetes 最初由 Google 基于 Borg（Google 的内部容器编排平台）的关键经验教训构建，于 2014 年 9 月发布。在 Kubernetes 发布时，Borg 本身已经超过十年了。到 2013 年，Borg 的许多原始团队成员开始研究下一步。Project 7 诞生了。
在发布时，Kubernetes 仍在底层使用 Docker。这种组合很可能有助于提升 Kubernetes 的普及度。Docker 当时非常流行，但人们在尝试组织和运行大量容器时开始发现不足。Kubernetes 即将解决这个问题。凭借其构建块的概念、独立部署和参与者（或代理），它易于扩展但仍然易于理解。此外，资源本质上是声明式的（以 JSON 或 YAML 文件编写），这使得这些定义能够进行版本控制。
自发布以来，Kubernetes 启用了越来越多的用例，因此越来越多的公司开始使用它。我认为采用的一大步是 2016 年 Helm 的发布，它简化了更复杂应用程序的部署过程，并实现了“开箱即用”的体验。现在 Kubernetes很“容易”（不要引用我说的容易！）。
如今，每个云提供商及其母公司都提供托管的 Kubernetes 环境。由于一组标准接口，这些服务大多可以互换。Kubernetes 的一大好处。无论如何，它只是大部分。小的不一致和实现或性能差异可能会让你度过一生，这可能还不够好。但我们称之为“随处运行”，因为几乎确实是这样。
Ferenc Hámori在Kubernetes 的历史中提供了 Kubernetes 完整历史的精彩概述，其中包括所有主要里程碑。
Kubernetes，爱或恨
当我们深入了解社区时，人们对 Kubernetes 的看法分歧很大。许多人指出了 Kubernetes 的内部（但隐藏的）复杂性。随着新功能和附加功能（包括第三方）的添加，这种复杂性只会增加。这种复杂性是真实的，这就是像Kelsey Hightower或Abdelfettah Sghiouar这样的人称 Kubernetes 为构建平台的平台（收听我们的 Cloud Commute播客剧集与 Abdelfettah）的原因，这意味着它应该由云提供商（或公司内部私有云团队）用于构建容器部署平台，但它不应该由开发人员或每个人使用。然而，Kelsey 也声称 Kubernetes 是一个好的起点，而不是终点。
而在光谱另一端，有人称 Kubernetes 为云领域的“操作系统”。鉴于其可扩展性和丰富特性，他们的说法可能并非过于牵强。现代操作系统的工作主要有一项：抽象底层硬件及其特性。话虽如此，Kubernetes 抽象掉了云基础设施的许多方面，以及运行容器所需的各种运维流程。从这个意义上说，Kubernetes 可能是一个云操作系统，尤其是因为我们已经开始看到在运行其他操作系统的 Kubernetes 实现，比如 Microsoft 的实现。
如果您有兴趣进一步了解 Kubernetes 作为云操作系统的理念， 来自 Robusta Dev 的Natan Yellin撰写了一篇非常有见地的文章，名为Kubernetes 将如何持续存在 50 年。
下一步是什么？
对于 Kubernetes 而言，最紧迫的问题是，下一步是什么？它将如何演变？我们是否接近终点？
回顾 Borg，十年后，Google 决定是时候重申编排并根据所吸取的教训进行构建了。Kubernetes 即将迎来其 10 周年纪念日。那么，这意味着是时候进行另一次迭代了吗？
Kubernetes 中的许多功能（例如机密）在 10 年前很好。今天我们知道，编码的“机密”肯定不够。临时用户帐户、OIDC 和类似技术可以并且已经集成到 Kubernetes 中，从而增加了其复杂性。
展望 Kubernetes，技术总是经历三个阶段：开始或采用阶段、每个人“必须”使用它的中间阶段以及公司开始逐步淘汰它的结束阶段。我个人认为，Kubernetes 目前正处于鼎盛时期，处于中间位置。
但这并不能让我们预测达到终点的时间表。目前看来，Kubernetes 将继续发展和壮大一段时间。它没有显示出任何放缓的迹象。
其他技术，如微型虚拟机，使用kata 容器或Firecracker，正变得越来越流行，提供更高的隔离性（因此更安全），但效率不高。然而，它们提供了一个重要的元素，即 CRI 兼容接口。这意味着它们可以用作 Kubernetes 下面的备用运行时。
在不久的将来，我看到 Kubernetes 提供多种运行时环境，就像它今天提供多种存储解决方案一样。启用在普通容器中运行简单服务，但将具有更高隔离需求的服务移动到微型虚拟机。
还有其他基于 Kubernetes 的有趣发展。Edgeless Systems 实施了一种机密计算解决方案，作为名为 Constellation 的 Kubernetes 发行版提供。机密计算利用 CPU 和 GPU 功能，帮助硬件加密内存，不仅适用于整个系统内存空间，还适用于每个虚拟机，甚至每个容器。这开启了一整套新的用例，为高度机密计算和数据处理提供端到端加密。虽然可以在 Kubernetes 之外使用它，但将这些计算运行在容器中的编排和操作优势使其易于部署和更新。如果您想了解更多有关 Constellation 的信息，我们不久前在我们的播客中邀请了来自 Edgeless Systems 的Moritz Eckert。
未来还是昙花一现？
那么，Kubernetes 是否拥有光明的前途，并将持续存在 50 年，还是我们很快就会意识到它不是我们正在寻找的东西？
如果今天有人问我如何看待 Kubernetes，我想我会回答得与我的 Docker 答案类似。它肯定是我们今天拥有的最好的工具，使其成为当今的容器编排工具。然而，它不断增加的复杂性使得很难在未来看到同样的情况。我认为有很多新的经验教训。现在可能是进行新迭代的时候了。不是今天，不是明天，而是在未来几年中的某个时候。
也许这个新迭代不是一个全新的工具，而是 Kubernetes 2.0，谁知道呢——但有些东西必须改变。技术不会停滞不前，（容器）世界与 10 年前不同。
如果你在容器化初期问某人，那都是关于容器必须是无状态的，而我们今天做什么？我们将数据库部署到 Kubernetes 中，我们喜欢它。云原生不再只是无状态的，但我认为今天三分之一的容器工作负载可能是状态化的（具有临时或持久状态），并且它将继续增加。编排、自动资源管理、自修复基础设施以及介于两者之间的所有内容的美妙之处在于，它太不可思议了，无法将其用于“所有内容”。
无论如何，无论 Kubernetes 本身发生什么（也许它将成为 OCI 的编排扩展？！），我认为它将从用户的眼中消失。它（或其继任者）将成为构建容器运行时平台的平台。但要实现这一目标，需要提供调试功能。目前，您必须深入了解 Kubernetes 或代理日志才能找出并修复问题。现在可以举手的人，他从未发现过为什么 Let's Encrypt 证书没有更新。
总之，Kubernetes 肯定不是一种昙花一现，但我强烈希望它也不是我们的未来。至少不是以其当前的形式。
本文在云云众生（yylives.cc/）首发，欢迎大家访问。
