Cluster API v1alpha3提供新功能并改善了用户体验

作者: 丹尼尔·利波维茨基(D2IQ)

群集API徽标:一直乌龟

集群API是Kubernetes项目,旨在将声明性的Kubernetes风格的API引入集群的创建,配置和管理。它在核心Kubernetes之上提供了可选的附加功能,以管理Kubernetes集群的生命周期。

在2019年10月发布v1alpha2之后,Cluster API社区的许多成员在加利福尼亚州旧金山举行会议,以计划下一个版本。该项目刚刚经历了一次重大转型,提供了一种新的体系结构,该体系结构有望使该项目更易于用户采用,并加快社区建设速度。在这两天的过程中,我们找到了我们的共同目标:实施对管理生产集群至关重要的功能,使用户体验更加直观,并使开发感到高兴。

Cluster API的v1alpha3版本为在生产中和大规模运行Kubernetes的任何人提供了重要功能。亮点包括:

对于想了解API或使用简单但功能强大的命令行界面的人,新版本将带来:

最后,对于任何扩展集群API以满足其自定义基础架构或软件需求的用户:

这要归功于许多贡献者的辛勤工作。

声明式控制平面管理

特别感谢 杰森·德提比鲁斯, 纳迪尔·吉瓦(Naadir Jeewa)查克·哈

基于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文档中。

这是一个用于集群API Docker基础架构的3副本控制平面的示例,该项目将其维护以进行测试和开发。为简便起见,未显示其名称和名称空间引用的其他必需资源,例如群集和基础结构模板。

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常见问题.

由于KCP是核心Cluster API组件,因此可以与任何提供固定控制平面端点(即负载平衡器或虚拟IP)的v1alpha3兼容的基础架构提供程序一起使用。该端点使请求能够到达多个控制平面副本。

什么是基础架构提供商? 计算资源的来源(例如机器,网络等)。社区维护着AWS,Azure,Google Cloud和VMWare的提供商。有关详细信息,请参见 供应商列表 在Cluster API Book中。

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

特别感谢 文斯·普里尼亚诺查克·哈

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

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

基于Kubeadm的ControlPlane在故障域之间分配节点。为了最大程度地减少在域中断的情况下丢失多个节点的机会,它会尝试将它们平均分配:它在故障域中部署一个现有节点最少的新节点,并在故障域中删除一个节点,而现有节点数量最少。现有的大多数节点。

MachineDeployments和MachineSet不会在故障域之间分配节点。要跨多个故障域部署您的工作节点,请为每个故障域创建一个MachineDeployment或MachineSet。

Failure Domain API可在任何基础架构上使用。这是因为每个基础架构提供程序都以自己的方式映射故障域。该API是可选的,因此,如果您的基础结构不够复杂而无法使用故障域,则无需支持它。本示例适用于Cluster API Docker Infrastructure Provider。注意,两个域被标记为适用于控制平面节点,而第三个域则不被标记为适用于控制平面节点。基于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

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

自动替换不健康的节点

特别感谢 阿尔贝托·加西亚·拉梅拉(AlbertoGarcíaLamela)乔尔速度

节点可能不健康的原因有很多。 kubelet进程可能会停止。容器运行时可能存在错误。内核可能存在内存泄漏。磁盘可能空间不足。 CPU,磁盘或内存硬件可能发生故障。可能会发生断电。此类故障在大型集群中尤为常见。

Kubernetes旨在容忍它们,并帮助您的应用程序也容忍它们。但是,在群集资源用尽之前,只有有限数量的节点可能不正常,并且Pods首先被逐出或未计划。不健康的节点应尽快修复或更换。

群集API现在包括MachineHealthCheck资源和一个监视节点运行状况的控制器。当它检测到不正常的节点时,将其删除。 (另一个Cluster API控制器检测到该节点已被删除并替换它。)您可以配置该控制器以满足您的需要。您可以配置在删除节点之前要等待多长时间。您还可以设置不正常节点数的阈值。达到阈值后,不再删除任何节点。等待可以用来容忍短暂的中断,并且可以使用阈值来防止同时替换太多节点。

控制器将仅删除由Cluster API MachineSet管理的节点。控制器不会删除控制平面节点,无论是由基于Kubeadm的控制平面还是由用户(如v1alpha2中)管理。有关更多信息,请参见 MachineHealthCheck的限制和警告.

这是MachineHealthCheck的示例。有关更多详细信息,请参见 配置MachineHealthCheck 在“群集API”一书中。

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

基础架构管理的节点组

特别感谢 塞西尔·罗伯特·米雄

如果运行大型群集,则有时需要在几分钟内创建和销毁数百个节点。尽管公共云使处理大量节点成为可能,但是必须提出单独的API请求来创建或删除每个节点,伸缩性可能会很差。例如,API请求可能必须延迟才能保持在速率限制内。

一些公共云提供API来将一组节点作为一个实体进行管理。例如,AWS具有AutoScaling组,Azure具有虚拟机规模集,而GCP具有托管实例组。在此版本的Cluster API中,基础结构提供程序可以添加对这些API的支持,并且用户可以使用MachinePool资源来部署Cluster API Machine组。有关更多信息,请参见 提案 在群集API存储库中。

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

重新构想的集群API用户体验

集群

特别感谢 法布里佐·潘迪尼(Fabrizio Pandini)

如果您是Cluster API的新手,那么您的第一手经验可能是使用该项目的命令行工具clusterctl。随着新的Cluster API版本的发布,它已经过重新设计,使其比以前更令人愉悦。该工具是您部署第一个工具所需要的全部 工作量集群 只需几个步骤。

First, use 集群 init to 获取配置 for your Infrastructure 和 Bootstrap Providers 和 deploy all of the components that make up the Cluster API. Second, use 集群 config cluster to 创建工作负载集群清单. This manifest is just a collection of Kubernetes objects. To create the 工作量集群, just kubectl apply the manifest. Don't be surprised if this workflow looks familiar: Deploying a 工作量集群 with Cluster API is just like deploying an application workload with Kubernetes!

Clusterctl also helps with the "day 2" operations. Use 集群 move to 迁移Cluster API自定义资源(例如集群和计算机)中的一个 管理集群 到另一个。此步骤-也称为 --is necessary to create a 工作量集群 that manages itself with Cluster API. Finally, use 集群 upgrade to 升级所有已安装的组件 当新的Cluster API版本可用时。

还有一件事! Clusterctl不仅是命令行工具。这也是一个Go库!将库视为基于群集API的项目的集成点。库中提供了clusterctl的所有命令行功能,可轻松集成到堆栈中。要开始使用该库,请阅读其 文件资料.

集群API书

感谢许多贡献者!

项目文件 广泛。新用户应该了解 建筑,然后使用 快速开始。 集群工具有其自己的 参考。的 开发人员指南 对于有兴趣为该项目做出贡献的任何人,都有很多信息。

除了内容本身之外,该项目的文档站点也很高兴使用。它是可搜索的,具有轮廓,甚至支持不同的颜色主题。如果您认为该网站很像另一个社区项目的文档, Kubebuilder,这不是巧合!非常感谢Kubebuilder作者创建了很好的文档示例。非常感谢 mdBook 作者,他们是创建文档的绝佳工具。

整合和定制

端到端测试框架

特别感谢 查克·哈

Cluster API项目被设计为可扩展的。例如,任何人都可以开发自己的基础架构和引导提供程序。但是,提供商必须以统一的方式工作很重要。而且,由于该项目仍在发展中,因此需要进行工作以确保提供者是最新的核心发行版。

端到端测试框架为开发人员提供了一组标准测试,以验证其提供程序是否与当前版本的Cluster API正确集成,并帮助确定在新版本的Cluster API或提供程序之后发生的任何退步。

有关该框架的更多详细信息,请参见 测验 在Cluster API Book中, 自述文件 在存储库中。

提供者实施者指南

感谢许多贡献者!

社区维护 基础设施提供商 适用于许多流行的基础架构。但是,如果您要构建自己的基础架构或引导提供程序,则 提供者实施者 指南说明了整个过程,从创建git存储库到为您的提供程序创建CustomResourceDefinitions,再到设计,实现和测试控制器。

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

加入我们!

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

在我们的每周会议上向社区介绍自己,在此期间,我们花大量时间进行问答环节。您还可以在Kubernetes 松弛以及Kubernetes论坛中找到维护者和用户。请查看下面的链接。我们期待您的光临!