Cluster API怎么配置使用

共计 10044 个字符，预计需要花费 26 分钟才能阅读完成。

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

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=UBUNTU
CLUSTER_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=ipip
kubectl apply -f  (cat  EOF
apiVersion: apps/v1
kind: DaemonSet
metadata:
 name: forward-ipencap
 namespace: kube-system
 labels:
 app: forward-ipencap
spec:
 selector:
 matchLabels:
 name: forward-ipencap
 template:
 metadata:
 labels:
 name: forward-ipencap
 spec:
 hostNetwork: true
 initContainers:
 - name: forward-ipencap
 command:
 - sh
 - -c
 - |
 apk add iptables
 iptables -C FORWARD -p ipencap -j ACCEPT || iptables -A FORWARD -p ipencap -j ACCEPT
 image: alpine:3.11
 securityContext:
 capabilities:
 add: [NET_ADMIN]
 containers:
 - name: sleep-forever
 image: alpine:3.11
 command: [tail]
 args: [-f ,  /dev/null]
)

配置了 GKE 集群后，我们现在可以开始部署必要的管理器（manager）。

# Install cluster api manager
kubectl apply -f https://github.com/kubernetes-sigs/cluster-api/releases/download/v0.2.8/cluster-api-components.yaml
# Install kubeadm bootstrap provider
kubectl apply -f https://github.com/kubernetes-sigs/cluster-api-bootstrap-provider-kubeadm/releases/download/v0.1.5/bootstrap-components.yaml
# Install kubernetes infrastructure provider
kubectl 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-groups
kubectl apply -f https://github.com/dippynark/cluster-api-provider-kubernetes/releases/download/v0.2.1/capi-kubernetes-rbac.yaml

现在，我们可以部署我们的集群。

kubectl apply -f  (cat  EOF
apiVersion: infrastructure.lukeaddison.co.uk/v1alpha2
kind: KubernetesCluster
metadata:
 name: example
spec:
 controlPlaneServiceType: LoadBalancer
apiVersion: cluster.x-k8s.io/v1alpha2
kind: Cluster
metadata:
 name: example
spec:
 clusterNetwork:
 services:
 cidrBlocks: [172.16.0.0/12]
 pods:
 cidrBlocks: [192.168.0.0/16]
 serviceDomain:  cluster.local 
 infrastructureRef:
 apiVersion: infrastructure.lukeaddison.co.uk/v1alpha2
 kind: KubernetesCluster
 name: example
)

在这里，我们定义了特定于环境的 KubernetesCluster 资源。这将为运行 Kubernetes 集群提供必要的基础架构组件。例如，GCPCluster 可能会提供 VPC、防火墙规则和负载均衡器以访问 API Server。而我们的 KubernetesCluster 只为 API Server 设置了 LoadBalancer 类型的 Kubernetes 服务。我们可以查询 KubernetesCluster 来查看其状态。

$ kubectl get kubernetescluster
NAME PHASE HOST PORT AGE
example Provisioned 35.205.255.206 443 51s

我们从核心集群资源中引用特定于提供程序的集群资源，该资源提供了集群的网络详细信息。KubernetesCluster 将被修改为由集群资源所拥有。

现在，我们准备部署我们的 Machine。在这里，我们创建一个 controller Machine，它引用 infrastructure provider 中特定的 KubernetesMachine 资源以及 bootstrap provider 中特定的 KubeadmConfig 资源。

kubectl apply -f  (cat  EOF
apiVersion: bootstrap.cluster.x-k8s.io/v1alpha2
kind: KubeadmConfig
metadata:
 name: controller
spec:
 initConfiguration:
 nodeRegistration:
 kubeletExtraArgs:
 eviction-hard: nodefs.available 0%,nodefs.inodesFree 0%,imagefs.available 0%
 cgroups-per-qos:  false 
 enforce-node-allocatable:  
 clusterConfiguration:
 controllerManager:
 extraArgs:
 enable-hostpath-provisioner:  true 
apiVersion: infrastructure.lukeaddison.co.uk/v1alpha2
kind: KubernetesMachine
metadata:
 name: controller
apiVersion: cluster.x-k8s.io/v1alpha2
kind: Machine
metadata:
 name: controller
 labels:
 cluster.x-k8s.io/cluster-name: example
 cluster.x-k8s.io/control-plane:  true 
spec:
 version:  v1.17.0 
 bootstrap:
 configRef:
 apiVersion: bootstrap.cluster.x-k8s.io/v1alpha2
 kind: KubeadmConfig
 name: controller
 infrastructureRef:
 apiVersion: infrastructure.lukeaddison.co.uk/v1alpha2
 kind: KubernetesMachine
 name: controller
)

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  EOF
apiVersion: infrastructure.lukeaddison.co.uk/v1alpha2
kind: KubernetesMachineTemplate
metadata:
 name: worker
spec:
 template:
 spec: {}
apiVersion: bootstrap.cluster.x-k8s.io/v1alpha2
kind: KubeadmConfigTemplate
metadata:
 name: worker
spec:
 template:
 spec:
 joinConfiguration:
 nodeRegistration:
 kubeletExtraArgs:
 eviction-hard: nodefs.available 0%,nodefs.inodesFree 0%,imagefs.available 0%
 cgroups-per-qos:  false 
 enforce-node-allocatable:  
apiVersion: cluster.x-k8s.io/v1alpha2
kind: MachineDeployment
metadata:
 name: worker
 labels:
 cluster.x-k8s.io/cluster-name: example
 nodepool: default
spec:
 replicas: 3
 selector:
 matchLabels:
 cluster.x-k8s.io/cluster-name: example
 nodepool: default
 template:
 metadata:
 labels:
 cluster.x-k8s.io/cluster-name: example
 nodepool: default
 spec:
 version:  v1.17.0 
 bootstrap:
 configRef:
 apiVersion: bootstrap.cluster.x-k8s.io/v1alpha2
 kind: KubeadmConfigTemplate
 name: worker
 infrastructureRef:
 apiVersion: infrastructure.lukeaddison.co.uk/v1alpha2
 kind: KubernetesMachineTemplate
 name: worker
)

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，名为 clusterName -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  none  2m34s v1.17.0
worker-kpbhm NotReady  none  2m32s v1.17.0
worker-pxsph NotReady  none  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  none  4m26s v1.17.0
worker-kpbhm Ready  none  4m24s v1.17.0
worker-pxsph Ready  none  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 怎么配置使用”的学习就结束了，希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习，快去试试吧！若想继续学习更多相关知识，请继续关注丸趣 TV 网站，丸趣 TV 小编会继续努力为大家带来更多实用的文章！