翻译自 Is Cluster API Really the Future of Kubernetes Deployment? 。
每个人都喜欢 Cluster API。但有些情况下它并不是最好的解决方案。来看看 Omni,Sidero Labs 新的基于裸金属和边缘部署的 Kubernetes SaaS 。
在 Sidero Labs ,我们非常喜欢 Cluster API(CAPI)。我们已经围绕它构建了许多东西,包括多个 CAPI Provider ,不用提还有每天多次使用 CAPI测试 Talos Linux 。我们是 CAPI 的粉丝。但在这篇文章中,我们将讨论我们认为存在问题的地方,以及为什么我们选择不在我们的新 SaaS 产品 Omni 中使用 CAPI 来在裸机和边缘上部署 Kubernetes 。
首先,什么是 Cluster API ?根据文档,“ Cluster API 是 Kubernetes 的一个子项目,旨在提供声明性 API 和工具,以简化多个 Kubernetes 集群的配置、升级和运维。”这基本上意味着 Cluster API 为人们提供了一种创建和管理 Kubernetes 集群的方式,类似于他们在 Kubernetes 中管理应用工作负载的方式。这为那些已经成为Kubernetes专家的人提供了一个非常好的体验,以便他们可以用自己喜欢的方式管理事物。
有所有云提供商的 Cluster API Provider 、VMware 的 Cluster API Provider ,以及针对裸机的 Cluster API Provider —— Sidero Metal 是我们自己的针对裸机的 CAPI 提供商,可以对服务器进行全面管理(在需要时开关机,将它们添加到集群中,删除和擦除机器等)。根据 CAPI 文档,“可以在各种基础设施环境中实现一致和可重复的集群部署。”
听起来不错,那么问题在哪里呢?
我们很幸运在 Sidero Labs 拥有一群热情的用户。我们有大量企业大规模运行 Talos Linux,其集群中有数十万个核。我们也有很多中小型企业运行着几个只有几个节点的小型集群,还有许多用户在运行家庭实验室。这些不同的用例导致人们对像 CAPI 这样的东西的胃口呈双峰分布。那些将数百个裸机集群作为内部服务运行的团队喜欢 CAPI 提供的功能。小团队则没有那么热衷。以下是一些原因。
所有这些都导致我们建议普通用户不要使用 CAPI,尽管我们开发了一个 CAPI 提供者,除非他们要部署具有数百台服务器的许多集群。
我们大约九个月前开始构建 Omni。 Omni 的目标是提供绝对顺畅的体验,用于创建 Kubernetes 集群并随时间管理它们。这包括一整套惊人的功能,例如轻松加入节点、处理升级、与企业身份验证提供程序集成的集群用户管理等。正如人们可能怀疑的那样,我们进行了许多关于如何架构该系统以及是否要基于 Cluster API 的讨论。最终决定是,不,我们不会使用 CAPI。上述问题是其中一些原因,加上 Omni 的一些其他目标,CAPI无法满足这些目标:
因此,所有这些都是为了说明,在考虑我们的设计目标时,Cluster API 并不适合 Omni 。
有人可能会问:“这对 Sidero Metal 有什么影响?”回答是:完全没有影响! Sidero 实验室仍然是 CAPI 社区的一部分,我们所有的提供者都将继续得到维护和改进。虽然我们认为 CAPI 存在一些限制,正如您可以从上面的观点中看到的那样,但对于特定的用例,如大规模提供许多集群而无需混合集群, CAPI 仍然是一个不错的选择。对于这些用户,我们将继续建议他们使用和享受 CAPI 。
但是对于 Omni,我们将继续在没有 CAPI 的情况下构建它,因为这会为更多用户带来更好的体验。实际上,我们预计 Omni 很快将成为一个更好的体验,即使对于运行数百个集群和服务器的用户也是如此。 Omni 可以轻松混合来自任何平台的工作程序(不像 CAPI);它是(像 CAPI 一样)基于声明性的驱动;它带来了 SaaS 的简单性,并且很快将支持 IPMI 以用于裸金属,所有这些都包含在一个优雅的 UI(和API) 中。这是一个绝对棒的平台,将简化几乎所有用户的生活。同时鼓励他们不要过于担心操作集群,只需运行他们的工作负载即可!
如果您想了解更多有关 Omni 或 CAPI 的信息,欢迎参加我们 3 月 21 日的免费虚拟用户会议 TalosCon 。诺基亚将讨论如何使用 CAPI、 Talos Linux 和 Sidero Metal “将私有云托管的 Kubernetes 服务扩展到10万+核心”。我们还将举行几场有关 Omni 和边缘 Kubernetes 的演讲。
希望在那里见到您!