Cluster API怎么配置使用

这篇文章主要介绍"Cluster API怎么配置使用"，在日常操作中，相信很多人在Cluster API怎么配置使用问题上存在疑惑，小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答"Cluster API怎么配置使用"的疑惑有所帮助！接下来，请跟着小编一起来学习吧！

Cluster API是一个Kubernetes项目，它将声明式Kubernetes风格的API用于集群的创建、配置和管理。它通过使用时CustomResourceDefinitions（CRDs）来扩展被Kubernetes API Server暴露的API来实现这些功能，从而允许用户创建新资源，例如集群（指Kubernetes集群）和Machine（指组成集群的节点的Machine）。然后每个资源的控制器负责对这些资源的更改做出反应，以启动集群。API的设计可以让不同的基础架构提供程序可以与其集成，进而提供针对其环境的特定逻辑。

Cluster API项目仍处于早期阶段，但是当前的情况已经证明了它能带来强大的功能。这

过去：v1alpha1

最初，Cluster API的v1alpha1实现要求提供程序需要在其项目中包含Cluster API控制器代码，并实现actuator（接口）以处理其环境的特定逻辑（例如，对云提供程序API的调用）。该代码作为特定于某个提供程序的管理器二进制文件运行，该二进制文件可以为管理集群所需的每个资源管理一个控制器。

现在：v1alpha2

使用Cluster API 的v1alpha1方法存在一个痛点，即它要求每个提供程序都实现一定数量的bootstrap boilerplate code，即代码不灵活并且冗长。为了解决这个问题，v1alpha2引入了bootstrap provider，它们负责生成将Machine转变为Kubernetes节点所需的数据。Kubeadm bootstrap provider则通过使用kubedam在所有环境中处理此任务。它的默认行为是为每台Machine生成一个可用于bootstrap节点的cloud-config脚本。

v1alpha2引入的另一个更改是，提供程序不再需要将Cluster API控制器代码包含在其项目中。而且Cluster API提供了对核心类型负责的独立控制器。有关这些更改的更多信息，请参阅Github上的信息。

对于此版本，现在需要部署3个管理器（而不是此前的1个）：

• Cluster API manager：用于管理核心v1alpha2资源

• Bootstrap provider manager：用于管理资源以生成将Machine转变为Kubernetes节点的数据

• Infrastructure provider manager：用于管理提供运行集群所需基础架构的资源

例如，如果我想使用kubedam在配置好的GCP上创建一个集群，我应该部署Cluster API manager（用于调和核心资源，例如集群和Machine资源），kubeadm bootstrap provider（例如，用于调和KubeadmConfig资源）以及GCP infrastructure provider（用于调和环境的特定资源，如GCPClusters和GCPMachines）。

为了了解如何应用这些资源，我们将使用我编写的Kubernetes基础架构提供程序实现来进行集群部署，即由Kubernetes本身提供基础架构的提供程序。Kubernetes节点使用kind镜像作为Kubernetes Pod运行。

首先，我们需要创建一个基础集群来为我们的Cluster API集群提供基础架构。我们将使用GKE。以下命令假定你已安装gcloud和GCP项目并设置了帐户。

警告：gcloud命令将产生一些花费，你也可以考虑使用GCP免费套餐。

Calico将作为Cluster API集群的CNI解决方案。在配置GKE集群以路由IPv4封装的数据包时，需要一些特殊的配置。为了不分散本文关于Cluster API行为的描述，我们将在此处直接运行它们，不做详细解释。

gcloud container clusters create management-cluster --cluster-version=1.14 --image-type=UBUNTUCLUSTER_CIDR=$(gcloud container clusters describe management-cluster --format="value(clusterIpv4Cidr)")gcloud compute firewall-rules create allow-management-cluster-pods-ipip --source-ranges=$CLUSTER_CIDR --allow=ipipkubectl apply -f <(cat <
配置了GKE集群后，我们现在可以开始部署必要的管理器（manager）。
# Install cluster api managerkubectl apply -f https://github.com/kubernetes-sigs/cluster-api/releases/download/v0.2.8/cluster-api-components.yaml# Install kubeadm bootstrap providerkubectl apply -f https://github.com/kubernetes-sigs/cluster-api-bootstrap-provider-kubeadm/releases/download/v0.1.5/bootstrap-components.yaml# Install kubernetes infrastructure providerkubectl apply -f https://github.com/dippynark/cluster-api-provider-kubernetes/releases/download/v0.2.1/provider-components.yaml# Allow cluster api controller to interact with kubernetes infrastructure resources# If the kubernetes provider were SIG-sponsored this would not be necesarry ;)# https://cluster-api.sigs.k8s.io/providers/v1alpha1-to-v1alpha2.html#the-new-api-groupskubectl apply -f https://github.com/dippynark/cluster-api-provider-kubernetes/releases/download/v0.2.1/capi-kubernetes-rbac.yaml
现在，我们可以部署我们的集群。
kubectl apply -f <(cat <
在这里，我们定义了特定于环境的KubernetesCluster资源。这将为运行Kubernetes集群提供必要的基础架构组件。例如，GCPCluster可能会提供VPC、防火墙规则和负载均衡器以访问API Server。而我们的KubernetesCluster只为API Server设置了LoadBalancer类型的Kubernetes服务。我们可以查询KubernetesCluster来查看其状态。
$ kubectl get kubernetesclusterNAME      PHASE         HOST             PORT   AGEexample   Provisioned   35.205.255.206   443    51s
我们从核心集群资源中引用特定于提供程序的集群资源，该资源提供了集群的网络详细信息。KubernetesCluster将被修改为由集群资源所拥有。
现在，我们准备部署我们的Machine。在这里，我们创建一个controller Machine，它引用infrastructure provider中特定的KubernetesMachine资源以及bootstrap provider中特定的KubeadmConfig资源。
kubectl apply -f <(cat <
kubeadm bootstrap provider将KubeadmConfig资源转换为cloud-config脚本，Kubernetes infrastructure provider使用该脚本来bootstrap Kubernetes Pod以形成新集群的控制平面。
Kubernetes infrastructure provider通过依靠systemd（它作为kind镜像的一部分运行）来实现这一目的。然后从cloud-config脚本生成一个bash脚本，以创建和运行指定的文件和命令。使用Kubernetes Secret将脚本安装到Pod中，当containerd socket可以使用之后，就使用systemd路径单元触发该脚本。你可以到controller pod中执行，并运行journalctl -u cloud-init来查看此脚本的输出。cat /opt/cloud-init/bootstrap.sh将显示完整脚本。
Kubelet运行之后，它将通过在etcd中创建controller Node对象（也在controller Pod上运行）向集群注册自己。
现在，我们可以部署我们的worker Machine了。这看起来与controller Machine 配置非常类似，但我们还会利用MachineDeployment、KubeadmConfigTemplate和KubernetesMachineTemplate来请求worker节点的多个副本。
kubectl apply -f <(cat <
MachineDeployments与Kubernetes Deployment工作方式十分相似，因为它们管理MachineSets，后者还管理所需数量的Machines副本。
现在，我们应该能够查询已经配置的Machine，以查看其状态。
$ kubectl get machinesNAME                      PROVIDERID                                          PHASEcontroller                kubernetes://871cde5a-3159-11ea-a1c6-42010a840084   provisioningworker-6c498c48db-4grxq                                                       pendingworker-6c498c48db-66zk7                                                       pendingworker-6c498c48db-k5kkp                                                       pending
我们还可以看到相应的KubernetesMachines。
$ kubectl get kubernetesmachinesNAME           PROVIDER-ID                                         PHASE          AGEcontroller     kubernetes://871cde5a-3159-11ea-a1c6-42010a840084   Provisioning   53sworker-cs95w                                                       Pending        35sworker-kpbhm                                                       Pending        35sworker-pxsph                                                       Pending        35s
不久，所有KubernetesMachines都应处于运行状态。
$ kubectl get kubernetesmachinesNAME           PROVIDER-ID                                         PHASE     AGEcontroller     kubernetes://871cde5a-3159-11ea-a1c6-42010a840084   Running   2mworker-cs95w   kubernetes://bcd10f28-3159-11ea-a1c6-42010a840084   Running   1mworker-kpbhm   kubernetes://bcd4ef33-3159-11ea-a1c6-42010a840084   Running   1mworker-pxsph   kubernetes://bccd1af4-3159-11ea-a1c6-42010a840084   Running   1m
我们还可以看到与你的KubernetesMachines相对应的Pod。
$ kubectl get podsNAME           READY   STATUS    RESTARTS   AGEcontroller     1/1     Running   0          2m11sworker-cs95w   1/1     Running   0          111sworker-kpbhm   1/1     Running   0          111sworker-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 nodesNAME           STATUS     ROLES    AGE     VERSIONcontroller     NotReady   master   3m16s   v1.17.0worker-cs95w   NotReady      2m34s   v1.17.0worker-kpbhm   NotReady      2m32s   v1.17.0worker-pxsph   NotReady      2m34s   v1.17.0
最后，可以应用我们的Calico CNI解决方案。节点应该很快就准备就绪。
$ kubectl apply -f https://docs.projectcalico.org/v3.11/manifests/calico.yaml$ kubectl get nodesNAME           STATUS   ROLES    AGE     VERSIONcontroller     Ready    master   5m8s    v1.17.0worker-cs95w   Ready       4m26s   v1.17.0worker-kpbhm   Ready       4m24s   v1.17.0worker-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怎么配置使用"的学习就结束了，希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习，快去试试吧！若想继续学习更多相关知识，请继续关注网站，小编会继续努力为大家带来更多实用的文章！