一文讲透ClusterAPI的前世、今生与未来

MachineDeployments与Kubernetes Deployment工作方式十分相似，因为它们管理MachineSets，后者还管理所需数量的Machines副本。

现在，我们应该能够查询已经配置的Machine，以查看其状态。

$ kubectl get machines NAME PROVIDERID PHASE controller kubernetes://871cde5a-3159-11ea-a1c6-42010a840084 provisioning worker-6c498c48db-4grxq pending worker-6c498c48db-66zk7 pending worker-6c498c48db-k5kkp pending 

我们还可以看到相应的KubernetesMachines。

$ kubectl get kubernetesmachines NAME PROVIDER-ID PHASE AGE controller kubernetes://871cde5a-3159-11ea-a1c6-42010a840084 Provisioning 53s worker-cs95w Pending 35s worker-kpbhm Pending 35s worker-pxsph Pending 35s 

不久，所有KubernetesMachines都应处于运行状态。

$ kubectl get kubernetesmachines NAME PROVIDER-ID PHASE AGE controller kubernetes://871cde5a-3159-11ea-a1c6-42010a840084 Running 2m worker-cs95w kubernetes://bcd10f28-3159-11ea-a1c6-42010a840084 Running 1m worker-kpbhm kubernetes://bcd4ef33-3159-11ea-a1c6-42010a840084 Running 1m worker-pxsph kubernetes://bccd1af4-3159-11ea-a1c6-42010a840084 Running 1m 

我们还可以看到与你的KubernetesMachines相对应的Pod。

$ kubectl get pods NAME READY STATUS RESTARTS AGE controller 1/1 Running 0 2m11s worker-cs95w 1/1 Running 0 111s worker-kpbhm 1/1 Running 0 111s worker-pxsph 1/1 Running 0 111s 

Cluster API manager生成一个kubeconfig并将其保存为一个Kubernetes Secret，名为-kubeconfig。我们可以检索它并访问集群。

$ kubectl get secret example-kubeconfig -o jsOnpath='{.data.value}' | base64 --decode > example-kubeconfig $ export KUBECOnFIG=example-kubeconfig $ kubectl get nodes NAME STATUS ROLES AGE VERSION controller NotReady master 3m16s v1.17.0 worker-cs95w NotReady  2m34s v1.17.0 worker-kpbhm NotReady  2m32s v1.17.0 worker-pxsph NotReady  2m34s v1.17.0 

最后，可以应用我们的Calico CNI解决方案。节点应该很快就准备就绪。

$ kubectl apply -f https://docs.projectcalico.org/v3.11/manifests/calico.yaml $ kubectl get nodes NAME STATUS ROLES AGE VERSION controller Ready master 5m8s v1.17.0 worker-cs95w Ready  4m26s v1.17.0 worker-kpbhm Ready  4m24s v1.17.0 worker-pxsph Ready  4m26s v1.17.0 

现在，我们可以在全新的集群上运行工作负载：

kubectl run nginx --image=nginx --replicas=3

对于其他基础设施提供程序，流程类似。你还可以在Cluster API文档中的快速入门部分找到许多其他示例。

未来：v1alpha3以及更高级的版本

我们仅仅是根据当前的情况进行延展，探讨Cluster API可能提供的功能。此外，我们还将讨论roadmap上的其他一些有趣的事情。

机器健康检查（MachineHealthCheck）

在v1alpha2中，特定于基础架构的Machine可以将其自身标记为故障，并且状态将上升到owning Machine，但是owning MachineSet不执行任何操作。这样做是因为，除了MachineSet之外的其他资源都可以拥有Machine，因此将Machine修复逻辑与MachineSet分离是有意义的。

MachineHealthCheck是一种建议的资源，用于描述节点的故障情况并在发生故障时删除相应的Machine。这将触发适当的删除行为（例如，驱散）和任何控制资源来启动替换Machine。

Kubeadm控制平面（KubeadmControlPlane）

当前，创建一个高可用控制平面并管理它通常需要使用正确的bootstrap配置（需要以正确的顺序启动）仔细配置独立的controller Machine。v1alpha3则希望通过初始的kubeadm控制平面实现来支持控制平台提供程序。从infrastructure provider的角度来看，这机会不需要进行任何更改，但是将允许用户管理控制平面的实例化和弹性伸缩，而无需手动创建相应的Machine。关于此功能，你可以查看Github上相关页面获取更多信息。

与MachineHealthChecks一起使用，可以使用Cluster API进行控制平面自动修复。

集群自动伸缩（Cluster Autoscaler）

Cluster Autoscaler是可以利用Cluster API的项目的一个示例。当前的实现要求每个受支持的云提供程序都实现扩展其环境中的实例组所需的CloudProvider和NodeGroup接口。随着Cluster API的出现，可以通过与Cluster API资源交互而不是直接与提供程序特定的API交互，来实现自动弹性伸缩逻辑，并且没有厂商锁定。

总 结

我们已经对Cluster API的当前功能以及不久的将来进行了深入的研究。该项目看起来十分强大并且完整，这令人激动。作为一个与Kubernetes相关的开源项目，Cluster API也是十分开放的，你可以通过各种渠道提出建议或是做出自己的贡献。