本文已超过一年。较旧的文章可能包含过时的内容。请检查页面中的信息自发布以来是否已变得不正确。

Cluster API v1alpha3 提供新功能和改进的用户体验

作者：Daniel Lipovetsky (D2IQ) | 2020 年 4 月 21 日，星期二

Cluster API 是一个 Kubernetes 项目，旨在为集群的创建、配置和管理引入声明式、Kubernetes 风格的 API。它在核心 Kubernetes 之上提供可选的、附加的功能，以管理 Kubernetes 集群的生命周期。

在 2019 年 10 月发布 v1alpha2 版本后，Cluster API 社区的许多成员在加利福尼亚州旧金山会面，计划下一个版本。该项目刚刚经历了一次重大转型，交付了一个新的架构，有望让用户更容易采用该项目，并让社区更快地构建。在那两天里，我们找到了共同的目标：实施管理生产集群的关键功能，使其用户体验更加直观，并使其开发过程更加愉快。

Cluster API 的 v1alpha3 版本为任何在生产环境中大规模运行 Kubernetes 的人带来了重要功能。其中亮点包括：

声明式控制平面管理
支持跨故障域分布控制平面节点以降低风险
自动替换不健康的节点
支持基础设施管理的节点组

对于任何想要了解 API 或重视简单但功能强大的命令行界面的人来说，新版本带来了：

重新设计的 clusterctl，一个用于安装和管理 Cluster API 生命周期的命令行工具（和 go 库）
《Cluster API Book》中的大量最新文档

最后，对于任何为其自定义基础设施或软件需求扩展 Cluster API 的人：

新的端到端 (e2e) 测试框架
将 Cluster API 集成到您的集群生命周期堆栈中的文档

所有这一切都归功于许多贡献者的辛勤工作。

声明式控制平面管理

特别感谢 Jason DeTiberus、Naadir Jeewa 和 Chuck Ha

基于 Kubeadm 的控制平面 (KCP) 提供了一个声明式 API，用于部署和扩展 Kubernetes 控制平面，包括 etcd。这是许多 Cluster API 用户一直期待的功能！到目前为止，要部署和扩展控制平面，用户必须创建专门设计的 Machine 资源。要缩小控制平面，他们必须手动从 etcd 集群中删除成员。KCP 自动化了部署、扩展和升级。

什么是 Kubernetes 控制平面？ Kubernetes 控制平面的核心是 kube-apiserver 和 etcd。如果其中任何一个不可用，则无法处理任何 API 请求。这不仅影响核心 Kubernetes API，还会影响使用 CRD 实现的 API。其他组件，如 kube-scheduler 和 kube-controller-manager，也很重要，但对可用性的影响不如它们。
控制平面在开始时很重要，因为它调度工作负载。但是，某些工作负载可以在控制平面中断期间继续运行。如今，工作负载依赖于操作符、服务网格和 API 网关，它们都将控制平面用作平台。因此，控制平面的可用性比以往任何时候都更加重要。
管理控制平面是集群操作中最复杂的部分之一。由于典型的控制平面包括 etcd，它是有状态的，并且操作必须按正确的顺序执行。控制平面副本可能并且确实会发生故障，并且维护控制平面的可用性意味着能够替换发生故障的节点。
控制平面可能会遭受完全中断（例如，etcd 中仲裁的永久丢失），而恢复（以及定期备份）有时是唯一可行的选择。
有关更多详细信息，请阅读 Kubernetes 文档中的Kubernetes 组件。

这是一个用于 Cluster API Docker 基础设施的 3 副本控制平面的示例，该项目维护该基础设施以进行测试和开发。为简洁起见，其他必需的资源（如 Cluster 和 Infrastructure Template，通过其名称和命名空间引用）未显示。

apiVersion: controlplane.cluster.x-k8s.io/v1alpha3
kind: KubeadmControlPlane
metadata:
  name: example
spec:
  infrastructureTemplate:
    apiVersion: infrastructure.cluster.x-k8s.io/v1alpha3
    kind: DockerMachineTemplate
    name: example
    namespace: default
  kubeadmConfigSpec:
    clusterConfiguration:
  replicas: 3
  version: 1.16.3

使用 kubectl 部署此控制平面

kubectl apply -f example-docker-control-plane.yaml

以与其他 Kubernetes 资源相同的方式扩展控制平面

kubectl scale kubeadmcontrolplane example  --replicas=5

kubeadmcontrolplane.controlplane.cluster.x-k8s.io/example scaled

将控制平面升级到 Kubernetes 发布的较新补丁

kubectl patch kubeadmcontrolplane example --type=json -p '[{"op": "replace", "path": "/spec/version", "value": "1.16.4"}]'

控制平面副本数量默认情况下，KCP 配置为管理 etcd，并且需要奇数个副本。如果 KCP 配置为不管理 etcd，则建议使用奇数，但不是必需的。奇数个副本可确保最佳的 etcd 配置。要了解为什么您的 etcd 集群应具有奇数个成员，请参阅 etcd FAQ。

由于它是核心 Cluster API 组件，KCP 可以与任何提供固定控制平面端点（即负载均衡器或虚拟 IP）的 v1alpha3 兼容基础设施提供程序一起使用。此端点使请求可以到达多个控制平面副本。

什么是基础设施提供程序？计算资源（例如机器、网络等）的来源。社区维护了适用于 AWS、Azure、Google Cloud 和 VMWare 的提供程序。有关详细信息，请参阅 Cluster API Book 中的提供程序列表。

分布控制平面节点以降低风险

特别感谢 Vince Prignano 和 Chuck Ha

Cluster API 用户现在可以在不同的故障域中部署节点，从而降低因域中断而导致集群发生故障的风险。这对于控制平面尤其重要：如果一个域中的节点发生故障，只要控制平面可用于其他域中的节点，集群就可以继续运行。

什么是故障域？故障域是一种对因某些故障而变得不可用的资源进行分组的方法。例如，在许多公共云中，“可用区”是默认的故障域。一个区域对应一个数据中心。因此，如果某个数据中心因断电或自然灾害而关闭，则该区域中的所有资源都将变得不可用。如果您在自己的硬件上运行 Kubernetes，则您的故障域可能是机架、网络交换机或配电单元。

基于 Kubeadm 的 ControlPlane 会将节点分布到不同的故障域中。为了最大限度地减少在域发生故障时丢失多个节点的可能性，它会尝试均匀分布它们：它会在现有节点最少的故障域中部署一个新节点，并删除现有节点最多的故障域中的现有节点。

MachineDeployments 和 MachineSets 不会在故障域之间分布节点。要在多个故障域中部署工作节点，请为每个故障域创建一个 MachineDeployment 或 MachineSet。

故障域 API 适用于任何基础设施。这是因为每个基础设施提供商都以自己的方式映射故障域。该 API 是可选的，因此如果您的基础设施不够复杂，不需要故障域，则无需支持它。此示例适用于 Cluster API Docker 基础设施提供商。请注意，其中两个域被标记为适合控制平面节点，而第三个域则不适合。基于 Kubeadm 的 ControlPlane 将仅将节点部署到标记为适合的域。

apiVersion: infrastructure.cluster.x-k8s.io/v1alpha3
kind: DockerCluster
metadata:
  name: example
spec:
  controlPlaneEndpoint:
    host: 172.17.0.4
    port: 6443
  failureDomains:
    domain-one:
      controlPlane: true
    domain-two:
      controlPlane: true
    domain-three:
      controlPlane: false

由 Cluster API 项目维护的 AWS 基础设施提供商 (CAPA) 将故障域映射到 AWS 可用区。使用 CAPA，您可以跨多个可用区部署集群。首先，为多个可用区定义子网。CAPA 控制器将为每个可用区定义一个故障域。使用 KubeadmControlPlane 部署控制平面：它会将副本分布在不同的故障域中。最后，为每个故障域创建一个单独的 MachineDeployment。

自动替换不健康的节点

特别感谢 Alberto García Lamela 和 Joel Speed

节点可能不健康的原因有很多。kubelet 进程可能会停止。容器运行时可能存在错误。内核可能存在内存泄漏。磁盘空间可能耗尽。CPU、磁盘或内存硬件可能发生故障。可能会发生停电。这些故障在较大的集群中尤其常见。

Kubernetes 的设计旨在容忍这些故障，并帮助您的应用程序也容忍它们。尽管如此，只有有限数量的节点可能不健康，然后集群才会耗尽资源，并且 Pod 会被驱逐或根本无法调度。应尽早修复或更换不健康的节点。

Cluster API 现在包含一个 MachineHealthCheck 资源和一个监视节点运行状况的控制器。当它检测到不健康的节点时，会将其删除。（另一个 Cluster API 控制器会检测到该节点已被删除并将其替换。）您可以根据需要配置控制器。您可以配置在删除节点之前等待多长时间。您还可以为不健康节点的数量设置阈值。达到阈值后，将不再删除任何节点。等待可用于容忍短暂的停机，阈值可防止同时替换太多节点。

控制器将仅删除由 Cluster API MachineSet 管理的节点。控制器不会删除控制平面节点，无论是通过基于 Kubeadm 的 Control Plane 管理的，还是由用户管理的，如 v1alpha2 中所示。有关更多信息，请参阅 MachineHealthCheck 的限制和注意事项。

这是一个 MachineHealthCheck 的示例。有关更多详细信息，请参阅 Cluster API 书中的配置 MachineHealthCheck。

apiVersion: cluster.x-k8s.io/v1alpha3
kind: MachineHealthCheck
metadata:
  name: example-node-unhealthy-5m
spec:
  clusterName: example
  maxUnhealthy: 33%
  nodeStartupTimeout: 10m
  selector:
    matchLabels:
      nodepool: nodepool-0
  unhealthyConditions:
  - type: Ready
    status: Unknown
    timeout: 300s
  - type: Ready
    status: "False"
    timeout: 300s

基础设施托管的节点组

特别感谢 Juan-Lee Pang 和 Cecile Robert-Michon

如果运行大型集群，您需要创建和销毁数百个节点，有时在几分钟内完成。尽管公共云使处理大量节点成为可能，但必须发出单独的 API 请求来创建或删除每个节点可能会导致扩展性不佳。例如，可能必须延迟 API 请求才能保持在速率限制之内。

一些公共云提供 API 来将节点组作为一个实体进行管理。例如，AWS 有 AutoScaling Groups，Azure 有 Virtual Machine Scale Sets，GCP 有 Managed Instance Groups。在此版本的 Cluster API 中，基础设施提供商可以添加对这些 API 的支持，用户可以使用 MachinePool 资源部署 Cluster API Machines 组。有关更多信息，请参阅 Cluster API 存储库中的提案。

实验性功能 MachinePool API 是一项实验性功能，默认情况下不启用。鼓励用户尝试并报告其满足需求的程度。

重新构想的 Cluster API 用户体验

clusterctl

特别感谢 Fabrizio Pandini

如果您是 Cluster API 的新手，那么您的第一次体验很可能是使用该项目的命令行工具 clusterctl。随着新的 Cluster API 版本的发布，它经过了重新设计，使用起来比以前更令人愉快。该工具是您在几个步骤中部署您的第一个工作负载集群所需的全部内容。

首先，使用 clusterctl init 来获取基础设施和引导提供商的配置，并部署组成 Cluster API 的所有组件。其次，使用 clusterctl config cluster 来创建工作负载集群清单。此清单只是 Kubernetes 对象的集合。要创建工作负载集群，只需 kubectl apply 该清单即可。如果此工作流程看起来很熟悉，请不要惊讶：使用 Cluster API 部署工作负载集群就像使用 Kubernetes 部署应用程序工作负载一样！

Clusterctl 还可以帮助进行“第 2 天”的操作。使用 clusterctl move 来迁移 Cluster API 自定义资源，例如 Clusters 和 Machines，从一个管理集群到另一个。此步骤（也称为 pivot）对于创建使用 Cluster API 自行管理的工作负载集群是必需的。最后，当有新的 Cluster API 版本可用时，使用 clusterctl upgrade 来升级所有已安装的组件。

还有一件事！Clusterctl 不仅仅是一个命令行工具。它还是一个 Go 库！将该库视为构建在 Cluster API 之上的项目的集成点。clusterctl 的所有命令行功能都可以在该库中使用，从而可以轻松地集成到您的堆栈中。要开始使用该库，请阅读其文档。

Cluster API 书籍

感谢众多贡献者！

该项目的文档内容广泛。新用户应该了解一些关于架构的背景知识，然后使用快速入门创建自己的集群。clusterctl 工具拥有自己的参考。开发人员指南为有兴趣为该项目做出贡献的任何人提供了大量信息。

除了内容本身之外，该项目的文档站点也令人愉快。它是可搜索的，具有大纲，甚至支持不同的颜色主题。如果您认为该站点很像另一个社区项目的文档 Kubebuilder，那绝非巧合！非常感谢 Kubebuilder 作者创建了如此出色的文档示例。也非常感谢 mdBook 作者创建了一个用于构建文档的出色工具。

集成 & 自定义

端到端测试框架

特别感谢 Chuck Ha

Cluster API 项目被设计为可扩展的。例如，任何人都可以开发自己的基础设施和引导提供商。但是，重要的是提供商以统一的方式工作。而且，由于该项目仍在发展中，因此需要进行一些工作，以确保提供商与核心的新版本保持同步。

端到端测试框架为开发人员提供了一组标准测试，以验证其提供商是否与当前版本的 Cluster API 正确集成，并有助于识别在 Cluster API 或提供商的新版本发布后发生的任何回归。

有关该框架的更多详细信息，请参阅 Cluster API 书中的测试和存储库中的 README。

提供商实施者指南

感谢众多贡献者！

社区维护了许多流行基础设施的基础设施提供商。但是，如果您想构建自己的基础设施或引导提供商，则提供商实施者指南将解释整个过程，从创建 git 存储库，到为您的提供商创建 CustomResourceDefinitions，再到设计、实施和测试控制器。

正在积极开发中 《提供商实施者指南》正在积极开发中，可能尚未反映 v1alpha3 版本中的所有更改。

加入我们！

Cluster API 项目是一个非常活跃的项目，涵盖了许多感兴趣的领域。如果您是基础设施专家，则可以为某个基础设施提供商做出贡献。如果您喜欢构建控制器，您会发现创新的机会。如果您对测试分布式系统感到好奇，则可以帮助开发该项目的端到端测试框架。无论您的兴趣和背景如何，您都可以对该项目产生真正的影响。

欢迎在我们的每周会议上向社区介绍您自己，在会议上，我们会留出一段时间进行问答环节。您还可以在 Kubernetes Slack 和 Kubernetes 论坛上找到维护人员和用户。请查看以下链接。我们期待与您相见！

在 Kubernetes Slack 上与我们聊天：#cluster-api
加入 sig-cluster-lifecycle Google Group 以接收日历邀请并访问文档
加入我们的 Zoom 会议，每周三太平洋时间上午 10:00
发布到 Cluster API 社区论坛