Kubernetes不仅关于容器，更关于API

“Kubernetes是一个可移植、可扩展的开源平台，用于管理容器化工作负载和服务，方便了声明式配置和自动化。”

这句话在开始时可能是一个很好的描述。现在，情况大不相同（尽管不一定明显）——Kubernetes不仅仅用于管理容器化工作负载和服务。

我们可以通过KubeVirt这样的项目用Kubernetes来管理虚拟机，可以使用ORKA来管理macOS机器和应用程序。Kubernetes通过Services创建和管理外部负载均衡器已经有一段时间了。Kubernetes管理的资源类型列表正在增加，因此我们不能再说它是一个用于管理容器化工作负载和服务的平台。

实际上，Kubernetes完全是关于API及其接收事件和让控制器监听这些事件的能力。

API本身被设计成可扩展的，并且它正在变得通用。这就是为什么像KubeVirt和ORKA这样的项目选择Kubernetes来管理非容器的东西。它们之所以这么做，主要是因为Kubernetes API的功能，以及用户对能够管理（几乎）一切的公共API的普遍需求。

如果Kubernetes API正在成为事实上的标准，那么思考一下这对今天或不久的将来意味着什么是有趣的。一般来说，我们需要管理运行在其上的基础设施和应用程序。这是Kubernetes API可以涵盖的两个主要领域。

就应用程序而言，有两件事正变得显而易见。我们正在采用（或已经采用）不变性，这意味着打包应用程序的普遍方式是J镜像。我们需要将这些镜像转换为容器、虚拟机或可能使用的任何其他运行时格式的进程，然后确定运行它们的最佳位置，并确保（几乎）始终保持所需状态。目前，这一切进展顺利。尽管我们将继续看到这一领域的重大改进，但这很可能是基于可用性而不是主要目标。

目前，更令人兴奋的方面是基础设施。

如果Kubernetes API正在成为一种通用的、事实上的标准，那么我们就有理由不仅要在应用程序中使用它，还要在基础设施中使用它。笔者相信，这是下一个前沿。将基础设施管理引入Kubernetes API将使其成为真正通用的事实标准。

有人可能会说，“使用Kubernetes API来管理我们的基础设施并不是一个放弃我们最喜欢的工具的充分理由。”然而，这是短视的，因为同一个API是有史以来创建的最大生态系统的主要方面。今天，很大一部分创新都是围绕Kubernetes展开的。大多数项目都转换为在Kubernetes内部工作。在过去的几年中，大多数项目都设计为利用我们在Kubernetes内部运行和利用其API所获得的优势。因此，设计用于利用Kubernetes API管理基础设施的项目将允许我们对所有事情使用相同的API，也能更好地利用Kubernetes周围的生态系统。

最接近这一目标的候选工具是Crossplane，它可以作为基础设施即代码（IaC）利用Kubernetes API背后的强大功能。我们可以通过最喜欢的工具来管理它，比如Helm或Kustomize。如果我们想按照GitOps原则使用它，我们可以将它与Argo CD或类似的工具结合使用。如果我们想在更改存储在Git中的定义时触发管道构建，我们可以使用Kubernetes原生解决方案，比如Codefresh。或者，如果我们想监控它的行为，我们可以从Prometheus那里获取指标。

我们能用那些不是为利用Kubernetes API而设计的基础设施即代码（IaC）工具来完成这些吗？当然可以。但是，我们没有得到Kubernetes提供的所有好处。Crossplane是否会成为管理基础设施的下一个主要解决方案，还有待观察。但可以肯定的是，一旦Kubernetes API被广泛用于管理应用程序和基础设施，它将成为（几乎）所有东西的通用API。这一天的到来是因为我们都在采用Kubernetes——不是因为它运行容器，而是因为它的API。