【翻译】Kubernetes Cluster API达到1.0版本的生产准备状态

发布日期：2021年10月6日

今天，我们宣布Cluster API v1.0已经具备生产条件，并正式进入v1beta1APIs。为了从阿尔法项目的成熟度水平转移，Cluster API已经证明了不断增长的采用率、功能成熟度以及对社区和包容性创新的坚定承诺。

Cluster API是一个Kubernetes项目，实现了Kubernetes的声明式管理，使用API来轻松创建、配置和更新集群。它是一种端到端的方法，可以简化Kubernetes生命周期中的重复性任务，同时在统一的基础设施中保持一致性和可重复性。

从一开始，Cluster API就看到了来自众多公司的贡献，包括VMware、微软、Weaveworks、谷歌、Mattermost、IBM、RedHat、D2iQ、Equinix、苹果、Talos Systems、Spectro Cloud、戴姆勒TSS、爱立信、Giant Swarm、AppsCode、英特尔、Twilio、New Relic、亚马逊等等。

Cluster API的主要目标是使集群生命周期管理变得枯燥。我们的API和可扩展性模型有一个成熟的生产记录；随着时间的推移，我们的目标是进一步巩固我们的基础，并建立抽象，以简化终端用户的体验。

Twilio - Cluster API on-premise bare metal

在Twilio，我们正在利用Cluster API为我们的SendGrid电子邮件基础设施进行生产。我们在分布于不同地域数据中心的裸机服务器上运行了100多个生产型Kubernetes集群。

我们发现Cluster API的整体拓扑结构很有价值，特别是拥有一个管理集群的范式。我们利用管理集群作为我们的专用基础设施，团队可以在其上构建、管理和保护管理我们公司不断增长的Kubernetes集群的应用程序套件。

我们对Cluster API的v1.0版本感到兴奋，因为它标志着我们对项目的下一阶段承诺的开始，以及未来更多的贡献。

Twilio - Kris Nóva - 高级首席工程师

Twilio - J. Brandt Buckley - 首席工程师

Giant Swarm - 云端和企业内部的集群API

在Giant Swarm，我们决定全身心地投入Cluster API，用上游的等价物取代我们的自定义控制器和API。我们正在将其与我们的分布式管理集群方法相结合，以管理数百个工作负载集群，并在此过程中向上游贡献我们的经验。

Cluster API的模块化架构和声明性质与我们管理基础设施的原则和愿景完全一致，进一步推动了Kubernetes作为平台的平台的想法。加入社区的这一努力，共同为每个人创造更好的集群管理的未来，是一个非常有动力和回报的经验。

我们对Cluster API的v1.0版本感到非常兴奋，因为我们正在使基于Cluster API的产品迭代做好准备，以便在明年初为我们不同供应商的客户实现平稳过渡。

Giant Swarm - Puja Abbassi - 产品副总裁

幽灵云

Cluster API是我们平台的基础性开源组件之一，它使我们的客户能够在任何地方大规模地管理任何类型的集群。随着对企业级生产环境要求的改变，全面管理Kubernetes基础设施的需求正在成为一种必要。Cluster API可能是社区最重要的项目之一，它不仅是Kubernetes的关键，也是整个开源生态系统更容易访问和管理的关键。

我们对即将发布的Cluster-API v1.0感到非常兴奋，并期待着更多的客户和供应商采用它。

Spectro Cloud - Jun Zhou - 首席架构师

塔洛斯系统公司

在Talos，我们从第一天起就是Cluster API的粉丝。我们有几个客户（包括我们自己！）使用CAPI在各种裸机和云环境中配置和维护Talos集群。

CAPI项目的模块化和总体预想使我们能够建立我们自己的Talos操作系统的提供者，帮助将Kubernetes声明式范式扩展到集群配置和操作系统。 这样一来，我们对CAPI的使用使我们有能力在这个坚实的基础上建立其他项目。有了这样一个处理Talos集群的框架，大大提高了我们产品的可用性。

我们非常高兴地看到v1.0版本的发布，因为我们将继续在这个伟大的项目之上开展工作!

Talos Systems - Spencer Smith - 高级首席软件工程师

戴姆勒TSS - Cluster API on-premise OpenStack

作为戴姆勒TSS的平台团队，我们在世界各地的内部数据中心运行和操作大约700个Kubernetes集群和3500个机器。 通过迁移到Cluster API，我们取代了传统的配置，包括Terraform、定制的自写工具和Kubernetes运营商。

我们的目标是提供大量的完全管理的Kubernetes集群和良好的客户体验。

Cluster API通过实现对外部云供应商的管理，增强了我们的产品组合。同时，它简化了我们现有基础设施的配置和升级。用Kubernetes的方式来管理集群，感觉是最自然的方式，而且完美地融入了现有的工作流程。

在我们的内部集群迁移到Cluster API之后，我们期待着采取下一步行动：向其他供应商提供集群，并与Kubernetes社区进行更多的接触。

戴姆勒TSS - Christian Schlotter - 软件工程师

戴姆勒TSS - Tobias Giese - 软件工程师

戴姆勒TSS - Sean Schneeweiss - 软件工程师

New Relic - 管理New Relic One观测平台的基础设施

Cluster API是New Relic公司Kubernetes集群车队管理系统中令人激动的一环。这个系统帮助我们的工程师更好地管理部署在公有云中的许多Kubernetes集群的生命周期。Cluster API为创建、配置和升级Kubernetes集群及其节点池提供了一致、简单和声明式的API，使我们能够简化集群舰队的自动化。除此之外，Cluster API使我们更容易为我们的工程师提供一个一致的自助服务界面来管理他们的基础设施。因为有了Cluster API，我们的工程师很少需要查看底层云供应商的控制台和API。相反，他们可以直接在Kubernetes中以Cluster API资源的形式管理基础设施。我们为能为Cluster API项目做出贡献而感到自豪，我们对1.0版本及以后的版本感到兴奋。

New Relic - Dane Thorsen - 首席软件工程师

红帽公司

在红帽，我们从最早的时候就参与了集群API项目，并将机器API组件纳入了红帽OpenShift 4集群自动缩放、节点自动恢复和短暂/热点实例能力。在这个共同的上游祖先上构建我们OpenShift基础设施管理的核心组件是一个成功的经验，我们期待在未来通过HyperShift等项目增加Cluster API的更多功能，使我们的用户能够将控制平面和管理问题与生产工作负载分开。我们很高兴看到Cluster API达到1.0，并祝贺所有的贡献者达到这个里程碑!

Red Hat - Michael McCune - 首席软件工程师

德国电信技术公司

在德国电信技术公司，我们的任务是为电信工作负载提供Kubernetes集群，如4G/5G核心、IMS、FTTH、RAN、Edge等等，还有一些相关的管理应用（OSS）。这些工作负载不仅需要在大型数据中心部署，还需要在德国各地的数百个小型内部地点部署。从2019年一开始，我们就完全相信CAPI是我们的发展方向，在2020年初，我们用v1alpha2投入生产，但很快就切换到v1alpha3，这在可用性和可管理性方面带来了重大突破。我们主要在vSphere（CAPV）和裸机（Metal3）上使用集中式管理集群运行我们的集群。

ClusterAPI为我们提供了很大的帮助，使我们可以通过一个小规模但专门的SRE团队来管理大量数据中心中的各种基础设施，并且可以管理。尤其是与GitOps搭配的声明式方法，在这方面对我们帮助很大。

随着我们把越来越多的关键电信服务放在CAPI管理的车队上，我们非常高兴看到ClusterAPI走向稳定。然而，从我们到目前为止的经验来看，我们可以随意地说，在软件稳定性方面的经验是非常好的。 非常感谢所有参与的人!

德国电信 - Maximilian Rink - 高级SRE

德国电信 - Vuk Gojnic - Kubernetes引擎小组组长

美国陆军

陆军首席信息官下属的企业云管理机构和陆军软件工厂正在利用集群API在生产中实现我们的上游集群自动化。我们在众多影响级别和环境中运行Kubernetes集群。我们需要一种方法来声明这些集群，以满足合规和安全的默认值，同时也提供一个区域控制平面，可以强制执行这些默认值。

我们发现Cluster API在管理集群方面的价值，它作为这个区域控制平面，帮助建立额外的集群，使不同的服务和组件可以快速安装在上面。由于这个原因，集群API成为国防部企业DevSecOps参考设计多集群CNCF Kubernetes的部分基础。

ECMA和陆军软件工厂期待着集群API的V1.0版本的发布，这将使我们能够扩展和自动化我们的流程，使陆军客户的企业达到。

美国陆军 - Paul Puckett - 企业云管理机构主任

美国陆军 - LTC Vito Errico - 陆军软件工厂主任

微软--Azure

微软对Cluster API的参与始于大约2年前，目的是为包括Azure在内的各地自我管理的Kubernetes集群的用户提供一个更好的开源故事。在Azure上的Kubernetes的起步阶段，AKS引擎是用来配置Kubernetes集群的工具。它的源代码在Azure的GitHub组织中，而不是在CNCF中。通过AKS引擎，用户能够在Azure上创建自我管理的集群，但在Azure上的体验与其他基础设施供应商之间几乎没有一致之处。这一切都因集群API而改变。现在，有了一个共享的界面，可以跨供应商建立基础设施。

在过去的一年里，Azure容器上游团队已经将其上游的Kubernetes测试迁移到Cluster API生态系统中，这样Azure Kubernetes场景的验证就只使用开源的CNCF工具。这对社区和微软来说都是一个巨大的胜利。我们能够用社区拥有和合作维护的工具在Azure上验证Kubernetes。在不久的将来，Azure的所有Kubernetes验证测试都将使用Cluster API运行。

微软 - David Justice - 首席工程负责人

AWS--Amazon EKS Anywhere的Cluster API

Amazon EKS Anywhere的目标之一是使客户能够使用Amazon EKS Distro在他们选择的基础设施提供商上配置Kubernetes集群。另一个目标是提供一个管理这些集群的声明性方式。Cluster API的宗旨是与基础设施无关，提供了一个可插入的模型，可以根据需要添加新的供应商，其管理Kubernetes集群和节点的声明式方法与我们的目标非常一致，因此我们决定在Amazon EKS Anywhere中使用它进行集群配置和生命周期管理操作，包括扩展、升级和删除。

对于Amazon EKS Anywhere，我们能够进一步利用Cluster API的声明式风格，为GitOps驱动的集群生命周期和配置管理提供Flux集成。在实现这些目标的过程中，与Cluster API社区的互动是非常有价值的。

我们对V1.0版本的发布感到兴奋，并期待着与社区进行更多的合作，为项目做出贡献。

AWS - Chandler Hoisington - EKS Anywhere总经理

AWS - Jackson West - 软件开发经理

AWS - Rajashree Mandaogane - 二级软件开发工程师

D2iQ

D2iQ认识到集群生命周期管理是一个复杂的问题，需要一个灵活但可靠的解决方案，而且它认识到朝着这两个目标努力最好在一个社区内完成。我们的软件帮助我们的客户在不同的基础设施上管理大量的集群。我们使用多个Cluster API基础设施供应商，并对社区维护的基础设施供应商做出贡献。Cluster API的架构使我们能够与社区合作解决共同的问题，并在我们需要时插入专门的组件。

对我们来说，V1.0版本的发布证实了我们自己在Cluster API方面的经验：它的设计随着时间的推移不断发展和成熟，它的实施已经可以投入生产，而项目社区拥有丰富的专业知识和不同的观点。我们期待着这个版本，以及未来更多的版本。

D2iQ - Daniel Lipovetsky - 工作人员软件工程师

D2iQ - Deepak Goel - 首席技术官

三星SDS

三星SDS从早期就对Cluster API项目感兴趣，目前正在使用Cluster API作为SDS云中管理Kubernetes服务的核心技术。我们实施了自己的供应商，以更适合SDS云的方式使用Cluster API。Cluster API使Kubernetes集群配置在各种IaaS中具有一致性和可扩展性。我们正试图利用这些优势来扩展我们的服务，在多混合云环境中提供Kubernetes服务。

我们相信Cluster API将成为遵循Kubernetes路线的云原生生态系统中管理集群生命周期的基础。v1.0版本的发布让我们对自己的方向充满信心，我们真诚地感谢每一位贡献者。我们期待着通过社区的各种活动做出更多的贡献。祝贺你!

三星SDS - Hansol Park - 高级工程师

三星SDS - Kangsub Song - 高级工程师

三星SDS - Moonhyuk Choi - 高级工程师

SK电信

在SK电讯，我们正在提供Kubernetes服务，作为我们为金融、媒体、广播领域的大型企业公司提供的多种混合云的一部分。从2019年初开始，我们就相信Cluster API是抽象化集群生命周期管理的复杂性质的正确方式。我们通过Kustomize、Helm和Argo工具链充分利用了Cluster API的Kubernetes原生和声明性质。现在，我们正在通过Argo CD在公有云上以GitOps风格配置企业就绪的Kubernetes集群和附加服务。我们正计划将其扩展到企业内部环境。

我们对V1.0版本的发布感到非常兴奋。 我们从社区中的每个人身上学到了很多东西，当然也会尽可能地回馈给社区。我们期待着与这个优秀的社区一起做些什么!

SK电信 - Jaesuk Ahn - 云原生开发负责人
SK Telecom - Seungkyu Ahn - 高级SW工程师和韩国Kubernetes社区负责人

VMware公司

Cluster API项目是VMware将云计算原生工具带给更多用户的努力的核心。VMware在其企业客户的转型过程中为他们提供支持，而Cluster API则在多云世界中为基础设施供应商提供一致的体验。通过与社区中的其他许多人合作，我们可以作为该社区的一员，以一致的方式在各种基础设施（从vSphere到公有云到裸机）上轻松部署和管理Kubernetes集群。新发布的ClusterClass功能进一步简化了事情，为定义和共享集群模式提供了一个更简单的界面。通过为平台团队创建一个更好的工具集，他们反过来可以为应用团队提供更加自动、快速和简单的内部产品。 最终的结果是应用团队更快、更安全地发货。

VMware - Joe Beda - 首席工程师 - Tanzu

在VMware，我们相信，竞争使我们个人变得更好，但合作使世界变得更好。我们很自豪地与Kubernetes社区一起走过了从CAPI的诞生到目前的生产准备阶段的旅程。作为一个系统，它从根本上重新定义了部署和维护Kubernetes集群的模式，将Kubernetes控制模式的力量带到了大规模的基础设施管理领域。衷心祝贺社区发布的V1.0版本。我们期待着这个项目的未来，它不仅是我们Tanzu产品线的基本组成部分，而且是充满活力的Kubernetes生态系统中越来越重要的组成部分。

VMware - Craig McLuckie - 副总裁 - 现代应用和管理

常见问题 (FAQ)

为什么要从 alpha迁移 到 1.0？

迁移到v1.0/v1beta1是对Cluster API已经被许多公司用于生产的认可，反映了项目团队已经在生产层面上运作，无论之前应用于我们代码库的语义版本或我们API前面的标签。

是什么让这一生产准备就绪？

去年，集群API社区在稳定代码、API、文档和广泛的测试信号方面投入了大量的精力，为Kubernetes的发布提供信息。

此外，我们还提供了API版本之间的自动转换，通过clusterctl工具进行自动升级，而且我们最近的所有API版本都支持了一年以上。

但真正重要的是，标志着这个项目已经为生产做好准备的主要信号，是来自我们用户的反馈。

这是否会影响开发的速度？

作为生产准备不会影响Cluster API的开发速度，因为项目团队已经有了工作结构，同时提供生产水平的保证。

在实践中，项目已经有了一系列孵化新功能的机制，例如功能标志或实验文件夹，所有的新功能，如机器池和ClusterClass，都已经在按照这个方法开发。

相反，在毕业于v1.0/v1beta1之后，我们希望我们的用户群能够增长，从而涌入新的用例和功能请求来推动我们的路线图。

有很多伟大的想法和机会摆在面前。

我在哪里可以找到更多关于这个项目的信息？

在KubernetesSlack上与我们交谈。#cluster-api

加入SIG集群生命周期谷歌群组，接收日历邀请并获得文件访问权。

在Zoom上加入我们的社区会议，每周三在太平洋时间上午10点。

这个项目的下一步是什么？

Cluster API社区目前正在努力提供ClusterClass和管理的拓扑结构，这一功能将大大简化你如何以声明的方式配置、升级和操作多个Kubernetes集群。

但路线图上还有更多内容：与集群自动调节器项目更好地整合，新的可扩展性点允许可插拔的负载平衡器解决方案，可管理的外部etcd集群，可插拔的运行时扩展，以及更多即将到来的内容

请继续关注!

集群API的维护者。