一文講透Cluster API的前世、今生與未來

2020 年 5 月 15 日
筆記
Kubernetes

作者：Luke Addison

原文鏈接：//blog.jetstack.io/blog/cluster-api-past-present-and-future/

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

Cluster API項目仍處於早期階段，但是當前的情況已經證明了它能帶來強大的功能。這篇文章的目的是總結迄今為止該項目的功能，並展望後續版本的功能。

過去、現在和未來

撰寫這篇文章的時候，Cluster API最新發佈的版本實現了v1alpha2。在這裡，我們將討論該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行為的描述，我們將在此處直接運行它們，不做詳細解釋。有關詳細信息，可以參考Kubernetes基礎架構提供程序代碼庫。

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 //github.com/kubernetes-sigs/cluster-api/releases/download/v0.2.8/cluster-api-components.yaml

# Install kubeadm bootstrap provider
kubectl apply -f //github.com/kubernetes-sigs/cluster-api-bootstrap-provider-kubeadm/releases/download/v0.1.5/bootstrap-components.yaml

# Install kubernetes infrastructure provider
kubectl apply -f //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 ;)
# //cluster-api.sigs.k8s.io/providers/v1alpha1-to-v1alpha2.html#the-new-api-groups
kubectl apply -f //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 //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的當前功能以及不久的將來進行了深入的研究。該項目看起來十分強大並且完整，這令人激動。作為一個與Kubernetes相關的開源項目，Cluster API也是十分開放的，你可以通過各種渠道提出建議或是做出自己的貢獻。

Tags: Kubernetes