共計(jì) 10044 個(gè)字符，預(yù)計(jì)需要花費(fèi) 26 分鐘才能閱讀完成。
這篇文章主要介紹“Cluster API 怎么配置使用”，在日常操作中，相信很多人在 Cluster API 怎么配置使用問題上存在疑惑，丸趣 TV 小編查閱了各式資料，整理出簡單好用的操作方法，希望對(duì)大家解答”Cluster API 怎么配置使用”的疑惑有所幫助！接下來，請(qǐng)跟著丸趣 TV 小編一起來學(xué)習(xí)吧！
Cluster API 是一個(gè) Kubernetes 項(xiàng)目，它將聲明式 Kubernetes 風(fēng)格的 API 用于集群的創(chuàng)建、配置和管理。它通過使用時(shí) CustomResourceDefinitions（CRDs）來擴(kuò)展被 Kubernetes API Server 暴露的 API 來實(shí)現(xiàn)這些功能，從而允許用戶創(chuàng)建新資源，例如集群（指 Kubernetes 集群）和 Machine（指組成集群的節(jié)點(diǎn)的 Machine）。然后每個(gè)資源的控制器負(fù)責(zé)對(duì)這些資源的更改做出反應(yīng)，以啟動(dòng)集群。API 的設(shè)計(jì)可以讓不同的基礎(chǔ)架構(gòu)提供程序可以與其集成，進(jìn)而提供針對(duì)其環(huán)境的特定邏輯。
Cluster API 項(xiàng)目仍處于早期階段，但是當(dāng)前的情況已經(jīng)證明了它能帶來強(qiáng)大的功能。這
過去：v1alpha1
最初，Cluster API 的 v1alpha1 實(shí)現(xiàn)要求提供程序需要在其項(xiàng)目中包含 Cluster API 控制器代碼，并實(shí)現(xiàn) actuator（接口）以處理其環(huán)境的特定邏輯（例如，對(duì)云提供程序 API 的調(diào)用）。該代碼作為特定于某個(gè)提供程序的管理器二進(jìn)制文件運(yùn)行，該二進(jìn)制文件可以為管理集群所需的每個(gè)資源管理一個(gè)控制器。
現(xiàn)在：v1alpha2
使用 Cluster API 的 v1alpha1 方法存在一個(gè)痛點(diǎn)，即它要求每個(gè)提供程序都實(shí)現(xiàn)一定數(shù)量的 bootstrap boilerplate code，即代碼不靈活并且冗長。為了解決這個(gè)問題，v1alpha2 引入了 bootstrap provider，它們負(fù)責(zé)生成將 Machine 轉(zhuǎn)變?yōu)?Kubernetes 節(jié)點(diǎn)所需的數(shù)據(jù)。Kubeadm bootstrap provider 則通過使用 kubedam 在所有環(huán)境中處理此任務(wù)。它的默認(rèn)行為是為每臺(tái) Machine 生成一個(gè)可用于 bootstrap 節(jié)點(diǎn)的 cloud-config 腳本。
v1alpha2 引入的另一個(gè)更改是，提供程序不再需要將 Cluster API 控制器代碼包含在其項(xiàng)目中。而且 Cluster API 提供了對(duì)核心類型負(fù)責(zé)的獨(dú)立控制器。有關(guān)這些更改的更多信息，請(qǐng)參閱 Github 上的信息。
對(duì)于此版本，現(xiàn)在需要部署 3 個(gè)管理器（而不是此前的 1 個(gè)）：
Cluster API manager：用于管理核心 v1alpha2 資源
Bootstrap provider manager：用于管理資源以生成將 Machine 轉(zhuǎn)變?yōu)?Kubernetes 節(jié)點(diǎn)的數(shù)據(jù)
Infrastructure provider manager：用于管理提供運(yùn)行集群所需基礎(chǔ)架構(gòu)的資源
例如，如果我想使用 kubedam 在配置好的 GCP 上創(chuàng)建一個(gè)集群，我應(yīng)該部署 Cluster API manager（用于調(diào)和核心資源，例如集群和 Machine 資源），kubeadm bootstrap provider（例如，用于調(diào)和 KubeadmConfig 資源）以及 GCP infrastructure provider（用于調(diào)和環(huán)境的特定資源，如 GCPClusters 和 GCPMachines）。
為了了解如何應(yīng)用這些資源，我們將使用我編寫的 Kubernetes 基礎(chǔ)架構(gòu)提供程序?qū)崿F(xiàn)來進(jìn)行集群部署，即由 Kubernetes 本身提供基礎(chǔ)架構(gòu)的提供程序。Kubernetes 節(jié)點(diǎn)使用 kind 鏡像作為 Kubernetes Pod 運(yùn)行。
首先，我們需要?jiǎng)?chuàng)建一個(gè)基礎(chǔ)集群來為我們的 Cluster API 集群提供基礎(chǔ)架構(gòu)。我們將使用 GKE。以下命令假定你已安裝 gcloud 和 GCP 項(xiàng)目并設(shè)置了帳戶。
警告：gcloud 命令將產(chǎn)生一些花費(fèi)，你也可以考慮使用 GCP 免費(fèi)套餐。
Calico 將作為 Cluster API 集群的 CNI 解決方案。在配置 GKE 集群以路由 IPv4 封裝的數(shù)據(jù)包時(shí)，需要一些特殊的配置。為了不分散本文關(guān)于 Cluster API 行為的描述，我們將在此處直接運(yùn)行它們，不做詳細(xì)解釋。
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 集群后，我們現(xiàn)在可以開始部署必要的管理器（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現(xiàn)在，我們可以部署我們的集群。
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
)在這里，我們定義了特定于環(huán)境的 KubernetesCluster 資源。這將為運(yùn)行 Kubernetes 集群提供必要的基礎(chǔ)架構(gòu)組件。例如，GCPCluster 可能會(huì)提供 VPC、防火墻規(guī)則和負(fù)載均衡器以訪問 API Server。而我們的 KubernetesCluster 只為 API Server 設(shè)置了 LoadBalancer 類型的 Kubernetes 服務(wù)。我們可以查詢 KubernetesCluster 來查看其狀態(tài)。
$ kubectl get kubernetescluster
NAME PHASE HOST PORT AGE
example Provisioned 35.205.255.206 443 51s我們從核心集群資源中引用特定于提供程序的集群資源，該資源提供了集群的網(wǎng)絡(luò)詳細(xì)信息。KubernetesCluster 將被修改為由集群資源所擁有。
現(xiàn)在，我們準(zhǔn)備部署我們的 Machine。在這里，我們創(chuàng)建一個(gè) 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 資源轉(zhuǎn)換為 cloud-config 腳本，Kubernetes infrastructure provider 使用該腳本來 bootstrap Kubernetes Pod 以形成新集群的控制平面。
Kubernetes infrastructure provider 通過依靠 systemd（它作為 kind 鏡像的一部分運(yùn)行）來實(shí)現(xiàn)這一目的。然后從 cloud-config 腳本生成一個(gè) bash 腳本，以創(chuàng)建和運(yùn)行指定的文件和命令。使用 Kubernetes Secret 將腳本安裝到 Pod 中，當(dāng) containerd socket 可以使用之后，就使用 systemd 路徑單元觸發(fā)該腳本。你可以到 controller pod 中執(zhí)行，并運(yùn)行 journalctl -u cloud-init 來查看此腳本的輸出。cat /opt/cloud-init/bootstrap.sh 將顯示完整腳本。
Kubelet 運(yùn)行之后，它將通過在 etcd 中創(chuàng)建 controller Node 對(duì)象（也在 controller Pod 上運(yùn)行）向集群注冊(cè)自己。
現(xiàn)在，我們可以部署我們的 worker Machine 了。這看起來與 controller Machine 配置非常類似，但我們還會(huì)利用 MachineDeployment、KubeadmConfigTemplate 和 KubernetesMachineTemplate 來請(qǐng)求 worker 節(jié)點(diǎn)的多個(gè)副本。
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 工作方式十分相似，因?yàn)樗鼈児芾?MachineSets，后者還管理所需數(shù)量的 Machines 副本。
現(xiàn)在，我們應(yīng)該能夠查詢已經(jīng)配置的 Machine，以查看其狀態(tài)。
$ 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我們還可以看到相應(yīng)的 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 都應(yīng)處于運(yùn)行狀態(tài)。
$ 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 相對(duì)應(yīng)的 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 111sCluster API manager 生成一個(gè) kubeconfig 并將其保存為一個(gè) 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最后，可以應(yīng)用我們的 Calico CNI 解決方案。節(jié)點(diǎn)應(yīng)該很快就準(zhǔn)備就緒。
$ 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現(xiàn)在，我們可以在全新的集群上運(yùn)行工作負(fù)載：
kubectl run nginx –image=nginx –replicas=3
對(duì)于其他基礎(chǔ)設(shè)施提供程序，流程類似。你還可以在 Cluster API 文檔中的快速入門部分找到許多其他示例。
未來：v1alpha3 以及更高級(jí)的版本
我們僅僅是根據(jù)當(dāng)前的情況進(jìn)行延展，探討 Cluster API 可能提供的功能。此外，我們還將討論 roadmap 上的其他一些有趣的事情。
機(jī)器健康檢查（MachineHealthCheck）
在 v1alpha2 中，特定于基礎(chǔ)架構(gòu)的 Machine 可以將其自身標(biāo)記為故障，并且狀態(tài)將上升到 owning Machine，但是 owning MachineSet 不執(zhí)行任何操作。這樣做是因?yàn)椋?MachineSet 之外的其他資源都可以擁有 Machine，因此將 Machine 修復(fù)邏輯與 MachineSet 分離是有意義的。
MachineHealthCheck 是一種建議的資源，用于描述節(jié)點(diǎn)的故障情況并在發(fā)生故障時(shí)刪除相應(yīng)的 Machine。這將觸發(fā)適當(dāng)?shù)膭h除行為（例如，驅(qū)散）和任何控制資源來啟動(dòng)替換 Machine。
Kubeadm 控制平面（KubeadmControlPlane）
當(dāng)前，創(chuàng)建一個(gè)高可用控制平面并管理它通常需要使用正確的 bootstrap 配置（需要以正確的順序啟動(dòng)）仔細(xì)配置獨(dú)立的 controller Machine。v1alpha3 則希望通過初始的 kubeadm 控制平面實(shí)現(xiàn)來支持控制平臺(tái)提供程序。從 infrastructure provider 的角度來看，這機(jī)會(huì)不需要進(jìn)行任何更改，但是將允許用戶管理控制平面的實(shí)例化和彈性伸縮，而無需手動(dòng)創(chuàng)建相應(yīng)的 Machine。關(guān)于此功能，你可以查看 Github 上相關(guān)頁面獲取更多信息。
與 MachineHealthChecks 一起使用，可以使用 Cluster API 進(jìn)行控制平面自動(dòng)修復(fù)。
集群自動(dòng)伸縮（Cluster Autoscaler）
Cluster Autoscaler 是可以利用 Cluster API 的項(xiàng)目的一個(gè)示例。當(dāng)前的實(shí)現(xiàn)要求每個(gè)受支持的云提供程序都實(shí)現(xiàn)擴(kuò)展其環(huán)境中的實(shí)例組所需的 CloudProvider 和 NodeGroup 接口。隨著 Cluster API 的出現(xiàn)，可以通過與 Cluster API 資源交互而不是直接與提供程序特定的 API 交互，來實(shí)現(xiàn)自動(dòng)彈性伸縮邏輯，并且沒有廠商鎖定。
到此，關(guān)于“Cluster API 怎么配置使用”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實(shí)踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識(shí)，請(qǐng)繼續(xù)關(guān)注丸趣 TV 網(wǎng)站，丸趣 TV 小編會(huì)繼續(xù)努力為大家?guī)砀鄬?shí)用的文章！
