Cluster API真的是Kubernetes部署的未来吗？

很多人喜欢Cluster API。但在某些情况下，它并不是最好的解决方案。看看Omni——来自Sidero Labs的面向在裸金属和边缘上部署Kubernetes的新SaaS。

在Sidero Labs，我们热爱Cluster API（CAPI）。我们已经围绕它建立了一大堆东西，更不用说每天用CAPI测试Talos Linux好几次了。但在这篇文章中，我们将讨论一些问题存在的地方，以及为什么我们选择不将CAPI用于Omni——这是我们面向在裸金属和边缘上部署Kubernetes的新SaaS。

首先，什么是Cluster API？根据文档，“Cluster API是一个Kubernetes子项目，专注于提供声明性API和工具，以简化多个Kubernet集群的配置、升级和运维。”这本质上意味着Cluster API为人们提供了一种创建和管理Kubernete集群的方式，与在Kubernets中管理应用程序工作负载时使用的方式类似。这给那些已经是Kubernetes专业人士的人提供了一种非常好的体验，他们可以用自己喜欢的方式管理。

所有云供应商、VMware和裸金属都有集群API provider——Sidero metal是我们的裸金属CAPI provider，可以对服务器进行全面管理（在需要时打开/关闭服务器电源，将其添加到集群，移除和擦除机器等）。根据CAPI文档，这“实现了在各种基础设施环境中一致且可重复的集群部署。”

听起来很不错，那么问题出在哪里呢？

CAPI的问题

Sidero Labs拥有一群热情的用户。我们有相当多的企业用户在大规模运行Talos Linux，他们的集群中有数十万个内核。我们还有很多中小型企业用户在运行由几个节点组成的数个小集群，还有许多用户在运行家庭实验室。这些不同的用例导致人们对CAPI之类的需求呈双峰分布。团队正在运行数百个裸金属集群作为内部服务，就像CAPI提供的电源一样。规模较小的团队没有得到关注。原因如下。

——CAPI需要一个专门的“管理平面”。这意味着你需要一个Kubernetes集群来管理Kubernete集群。对于硬件有限、只想运行一两个集群的人来说，将另一个集群和节点用于此目的是浪费和昂贵的。

——这很难。在很多方面，人们必须深入理解Cluster API和特定provider提供的原语。这些原语根据所选择的provider而不同，并且在试图理解其管理平面和供应系统时，可能会导致普通用户感到困惑。对于刚接触Kubernetes的团队来说，这是双重困惑——试图理解pod、部署等已经足够困难了。

——CAPI做出了一些假设，但这些假设不适用于裸金属或边缘部署。在CAPI世界中，升级过程是“使用较新的配置启动一个新节点，然后拆除旧节点”。这对具有单节点集群的边缘用例根本不起作用，也不适用于具有大量数据的集群节点，如果节点被拆除，这些数据需要复制（比如在本地连接的磁盘中具有大量Ceph存储的裸金属节点）。如果你没有一台备用服务器来进入集群进行滚动升级，那么它也不起作用——让每类昂贵的服务器以及管理平面服务器闲置，成本高企（如果你在云提供商中运行集群，这不是问题）。

——故障排除很难。由于Cluster API的模块化，很难弄清楚事情的症结所在。集群创建的许多编排都归结为各种资源的状态，以及这些资源是否已完成配置，以便下一个提供者有足够的信息来提供其资源。你必须深入了解CAPI本身与基础设施/引导/控制平面provider之间的集成，甚至知道在哪里查找故障日志。

所有这些都导致我们建议普通用户不要使用CAPI，除非部署了数百台服务器的许多集群。

看看Omni

我们大约九个月前开始构建Omni。Omni的目标是为创建Kubernetes集群并随着时间的推移对其管理提供绝对流畅的体验。这包括一系列功能，如轻松连接节点、处理升级、与企业身份provider集成的集群用户管理等。我们就如何构建这个系统以及是否将其建立在集群API的基础上进行了大量讨论。最终的决定是不，我们不会。上述问题是为什么不这样做的一些原因，以下是CAPI无法实现而Omni可以的其他一些目标：

——专用的“管理平面”对一些用户来说是不可行的。我们有一些内部部署用户想要一种完全无间隙且简单的方式来部署、管理和升级集群，我们希望通过Omni提供这种方式。笔者说的是“把一个支架运到沙漠里，希望它能工作”级别的空气间隙。对于这些用户来说，需要额外的硬件来运行HA管理平面集群是对资源的巨大浪费，或者在某些情况下是不可能的，因为他们已经有了一个服务器机架。

——操作这些设备的人甚至不知道Kubernetes是什么。我们需要尽可能简单的架构来启动Omni，以及它将管理的集群。需要一个带有CAPI的Kubernetes集群、一堆provider、Omni本身，然后尝试在现场启用引导和故障排除，这几乎是不可能的。从需求中删除集群API使我们能够将Omni作为单个Go二进制文件进行发布，这使得管理变得简单。（是的，Omni是一种SaaS，你可以轻松地自己运行它。）

——Omni通过Kubespan支持真正的混合Kubernetes集群。我们在内部使用它。通过在Azure中廉价托管控制平面节点，我们每月节省约1500美元，而我们的工作节点是Equinix metal中强大的裸金属节点。此功能非常强大，允许你从任何位置（任何云、VMware、裸金属）向集群添加节点（注意如何标记这些节点并根据它们进行计划）。然而，在ClusterAPI中，没有一个提供程序是以这样的方式编写的，即提供程序可以在单个集群中混合使用。

——Omni的目标之一是让边缘的Kubernetes变得简单，使用Omni的大部分人正是利用它来做到这一点的。使用Cluster API进行边缘部署并不是一个好方法。没有真正的方法允许在边缘启动预启动执行环境（PXE）：这些节点需要遵循“签入”流程。它在Omni中的工作方式是从公司Omni账户下载的镜像中启动节点。此镜像经过预配置，可形成点对点Wireguard连接，返回Omni账户。因此，一旦机器启动，它就会在Omni中显示为一台未分配的机器，并允许用户将机器连接到现有的集群或用它创建一个新的集群。这与集群API的供应流程并不匹配，我们觉得提出的与集群API协同使用的任何东西都有点过时，无法提供简单性。

——最后，Talos Linux的一些功能将受到Cluster API的限制。Kubernetes和Talos Linux本身的升级就是一个很好的例子。我们为这两者提供了非常好的API，允许进行适当的升级，并在升级过程中对准备情况进行良好的检查。在CAPI之外构建使我们能够利用已有的这些升级API，并避免CAPI强加的滚动更新限制。

所有这些都意味着，考虑到我们的设计目标，Cluster API并不适合Omni。

未来

“这对Sidero Metal意味着什么？”有人可能会问。答案是一个响亮的“什么都没有”！Sidero Labs仍然是CAPI社区的一部分，我们所有的provider都将继续得到维护和改进。虽然我们认为CAPI存在局限性，但正如你从上面几点可以看到的那样，CAPI仍然是特定用例的不错选择——大规模供应许多集群，而不需要混合集群。对于这些用户，我们将继续建议他们使用并享受它。

但对于Omni来说，我们将在没有CAPI的情况下继续构建它，因为它可以为更多用户提供更好的体验。事实上，我们预计Omni很快就会成为比CAPI更好的体验，即使对于那些运行数百个集群和服务器的用户来说也是如此。Omni使混合来自任何平台的工作节点变得简单（与CAPI不同），是声明驱动的（像CAPI一样），带来了SaaS的简单性，并将很快支持用于裸金属的IPMI，所有都封装在一个优雅的UI（和API）中。这是一个非常棒的平台，它将简化几乎所有用户的生活。他们不要再为运维集群而担心太多，只运行他们的工作负载就可以了。