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=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"]
EOF
)

配置了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
EOF
)

在這里，我們定義了特定于環境的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
EOF
)

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
EOF
)

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怎么配置使用”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！