這篇文章主要介紹“Cluster API怎么配置使用”，在日常操作中，相信很多人在Cluster API怎么配置使用問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”Cluster API怎么配置使用”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

修水網站建設公司創(chuàng)新互聯(lián),修水網站設計制作，有大型網站制作公司豐富經驗。已為修水上千提供企業(yè)網站建設服務。企業(yè)網站搭建\外貿網站制作要多少錢，請找那個售后服務好的修水做網站的公司定做！

Cluster API是一個Kubernetes項目，它將聲明式Kubernetes風格的API用于集群的創(chuàng)建、配置和管理。它通過使用時CustomResourceDefinitions（CRDs）來擴展被Kubernetes API Server暴露的API來實現這些功能，從而允許用戶創(chuàng)建新資源，例如集群（指Kubernetes集群）和Machine（指組成集群的節(jié)點的Machine）。然后每個資源的控制器負責對這些資源的更改做出反應，以啟動集群。API的設計可以讓不同的基礎架構提供程序可以與其集成，進而提供針對其環(huán)境的特定邏輯。

Cluster API項目仍處于早期階段，但是當前的情況已經證明了它能帶來強大的功能。這

過去：v1alpha1

最初，Cluster API的v1alpha1實現要求提供程序需要在其項目中包含Cluster API控制器代碼，并實現actuator（接口）以處理其環(huán)境的特定邏輯（例如，對云提供程序API的調用）。該代碼作為特定于某個提供程序的管理器二進制文件運行，該二進制文件可以為管理集群所需的每個資源管理一個控制器。

現在：v1alpha2

使用Cluster API 的v1alpha1方法存在一個痛點，即它要求每個提供程序都實現一定數量的bootstrap boilerplate code，即代碼不靈活并且冗長。為了解決這個問題，v1alpha2引入了bootstrap provider，它們負責生成將Machine轉變?yōu)镵ubernetes節(jié)點所需的數據。Kubeadm bootstrap provider則通過使用kubedam在所有環(huán)境中處理此任務。它的默認行為是為每臺Machine生成一個可用于bootstrap節(jié)點的cloud-config腳本。

v1alpha2引入的另一個更改是，提供程序不再需要將Cluster API控制器代碼包含在其項目中。而且Cluster API提供了對核心類型負責的獨立控制器。有關這些更改的更多信息，請參閱Github上的信息。

對于此版本，現在需要部署3個管理器（而不是此前的1個）：

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

• Bootstrap provider manager：用于管理資源以生成將Machine轉變?yōu)镵ubernetes節(jié)點的數據

• Infrastructure provider manager：用于管理提供運行集群所需基礎架構的資源

例如，如果我想使用kubedam在配置好的GCP上創(chuàng)建一個集群，我應該部署Cluster API manager（用于調和核心資源，例如集群和Machine資源），kubeadm bootstrap provider（例如，用于調和KubeadmConfig資源）以及GCP infrastructure provider（用于調和環(huán)境的特定資源，如GCPClusters和GCPMachines）。

為了了解如何應用這些資源，我們將使用我編寫的Kubernetes基礎架構提供程序實現來進行集群部署，即由Kubernetes本身提供基礎架構的提供程序。Kubernetes節(jié)點使用kind鏡像作為Kubernetes Pod運行。

首先，我們需要創(chuàng)建一個基礎集群來為我們的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 <
配置了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 <
在這里，我們定義了特定于環(huán)境的KubernetesCluster資源。這將為運行Kubernetes集群提供必要的基礎架構組件。例如，GCPCluster可能會提供VPC、防火墻規(guī)則和負載均衡器以訪問API Server。而我們的KubernetesCluster只為API Server設置了LoadBalancer類型的Kubernetes服務。我們可以查詢KubernetesCluster來查看其狀態(tài)。
$ kubectl get kubernetescluster
NAME      PHASE         HOST             PORT   AGE
example   Provisioned   35.205.255.206   443    51s
我們從核心集群資源中引用特定于提供程序的集群資源，該資源提供了集群的網絡詳細信息。KubernetesCluster將被修改為由集群資源所擁有。
現在，我們準備部署我們的Machine。在這里，我們創(chuàng)建一個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腳本，以創(chuàng)建和運行指定的文件和命令。使用Kubernetes Secret將腳本安裝到Pod中，當containerd socket可以使用之后，就使用systemd路徑單元觸發(fā)該腳本。你可以到controller pod中執(zhí)行，并運行journalctl -u cloud-init來查看此腳本的輸出。cat /opt/cloud-init/bootstrap.sh將顯示完整腳本。
Kubelet運行之后，它將通過在etcd中創(chuàng)建controller Node對象（也在controller Pod上運行）向集群注冊自己。
現在，我們可以部署我們的worker Machine了。這看起來與controller Machine 配置非常類似，但我們還會利用MachineDeployment、KubeadmConfigTemplate和KubernetesMachineTemplate來請求worker節(jié)點的多個副本。
kubectl apply -f <(cat <
MachineDeployments與Kubernetes Deployment工作方式十分相似，因為它們管理MachineSets，后者還管理所需數量的Machines副本。
現在，我們應該能夠查詢已經配置的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
我們還可以看到相應的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都應處于運行狀態(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相對應的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解決方案。節(jié)點應該很快就準備就緒。
$ 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可以將其自身標記為故障，并且狀態(tài)將上升到owning Machine，但是owning MachineSet不執(zhí)行任何操作。這樣做是因為，除了MachineSet之外的其他資源都可以擁有Machine，因此將Machine修復邏輯與MachineSet分離是有意義的。
MachineHealthCheck是一種建議的資源，用于描述節(jié)點的故障情況并在發(fā)生故障時刪除相應的Machine。這將觸發(fā)適當的刪除行為（例如，驅散）和任何控制資源來啟動替換Machine。
Kubeadm控制平面（KubeadmControlPlane）
當前，創(chuàng)建一個高可用控制平面并管理它通常需要使用正確的bootstrap配置（需要以正確的順序啟動）仔細配置獨立的controller Machine。v1alpha3則希望通過初始的kubeadm控制平面實現來支持控制平臺提供程序。從infrastructure provider的角度來看，這機會不需要進行任何更改，但是將允許用戶管理控制平面的實例化和彈性伸縮，而無需手動創(chuàng)建相應的Machine。關于此功能，你可以查看Github上相關頁面獲取更多信息。
與MachineHealthChecks一起使用，可以使用Cluster API進行控制平面自動修復。
集群自動伸縮（Cluster Autoscaler）
Cluster Autoscaler是可以利用Cluster API的項目的一個示例。當前的實現要求每個受支持的云提供程序都實現擴展其環(huán)境中的實例組所需的CloudProvider和NodeGroup接口。隨著Cluster API的出現，可以通過與Cluster API資源交互而不是直接與提供程序特定的API交互，來實現自動彈性伸縮邏輯，并且沒有廠商鎖定。
到此，關于“Cluster API怎么配置使用”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續(xù)學習更多相關知識，請繼續(xù)關注創(chuàng)新互聯(lián)網站，小編會繼續(xù)努力為大家?guī)砀鄬嵱玫奈恼拢?/p>            
            
                        

            分享題目：ClusterAPI怎么配置使用            

            分享地址：http://weahome.cn/article/pdjjoj.html