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

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 手册中广泛且最新的文档

最后，对于任何为自定义基础设施或软件需求扩展 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 基础设施的三副本控制平面示例，该项目维护此基础设施用于测试和开发。为简洁起见，未显示其他必需资源，如集群和基础设施模板（通过其名称和命名空间引用）。

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 可以与任何 v1alpha3 兼容的、提供固定控制平面端点（即负载均衡器或虚拟 IP）的 Infrastructure Provider 一起使用。此端点使得请求能够到达多个控制平面副本。

什么是基础设施提供商 (Infrastructure Provider)？ 计算资源（例如机器、网络等）的来源。社区维护 AWS、Azure、Google Cloud 和 VMWare 的提供商。有关详细信息，请参阅 Cluster API 手册中的提供商列表。

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

特别感谢 Vince Prignano 和 Chuck Ha

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

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

基于 Kubeadm 的控制平面将节点分布在故障域中。为了最大程度地降低在域中断事件中丢失多个节点的可能性，它尝试均匀地分布它们：它在现有节点最少的故障域中部署一个新节点，并在现有节点最多的故障域中移除一个现有节点。

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

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

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 进程可能会停止。容器运行时可能存在 bug。内核可能存在内存泄漏。磁盘空间可能耗尽。CPU、磁盘或内存硬件可能发生故障。可能会发生停电。这些故障在大规模集群中尤其常见。

Kubernetes 的设计宗旨是容忍这些故障，并帮助您的应用程序容忍它们。然而，在集群资源耗尽之前，只有有限数量的节点可以是不健康的，Pod 将被逐出或根本无法调度。不健康的节点应尽快修复或替换。

Cluster API 现在包含一个 MachineHealthCheck 资源和一个监控节点健康的控制器。当它检测到不健康的节点时，它会将其移除。（另一个 Cluster API 控制器检测到节点已被移除并替换它。）您可以根据您的需求配置控制器。您可以配置在移除节点之前等待多长时间。您还可以设置不健康节点的数量阈值。达到阈值时，不再移除节点。等待时间可以用于容忍短期中断，而阈值可以防止同时替换过多的节点。

控制器将仅移除由 Cluster API MachineSet 管理的节点。控制器不会移除控制平面节点，无论是通过基于 Kubeadm 的控制平面管理，还是像 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 机器组。有关更多信息，请参阅 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 还协助“第二天”操作。使用 clusterctl move 将 Cluster API 自定义资源（例如集群和机器）从一个管理集群迁移到另一个。此步骤（也称为枢轴）对于创建使用 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 群组以接收日历邀请并访问文档
加入我们的 Zoom 会议，每周三太平洋时间上午 10:00 举行
在 Cluster API 社区论坛发布帖子