很多人喜欢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)中。这是一个非常棒的平台,它将简化几乎所有用户的生活。他们不要再为运维集群而担心太多,只运行他们的工作负载就可以了。