雲端控制器管理員管理

功能狀態: Kubernetes v1.11 [beta]

由於雲端供應商的開發與發行步調與 Kubernetes 專案不同,因此將供應商特定的程式碼抽象化為 cloud-controller-manager 二進位檔,可讓雲端廠商獨立於核心 Kubernetes 程式碼之外發展。

cloud-controller-manager 可以連結至任何滿足 cloudprovider.Interface 的雲端供應商。為了向後相容性,核心 Kubernetes 專案中提供的 cloud-controller-manager 使用與 kube-controller-manager 相同的雲端程式庫。Kubernetes 核心中已支援的雲端供應商應使用樹狀結構內的 cloud-controller-manager 來移轉出 Kubernetes 核心。

管理

需求

每個雲端對執行其自己的雲端供應商整合都有自己的一組需求,這與執行 kube-controller-manager 時的需求不應相差太多。一般來說,您會需要

  • 雲端身份驗證/授權:您的雲端可能需要權杖或 IAM 規則,以允許存取其 API
  • kubernetes 身份驗證/授權:cloud-controller-manager 可能需要設定 RBAC 規則才能與 kubernetes apiserver 通訊
  • 高可用性:與 kube-controller-manager 類似,您可能會想要使用領導者選舉(預設為開啟)為雲端控制器管理員建立高可用性設定。

執行 cloud-controller-manager

成功執行 cloud-controller-manager 需要對您的叢集組態進行一些變更。

  • kubeletkube-apiserverkube-controller-manager 必須根據使用者對外部 CCM 的使用方式進行設定。如果使用者具有外部 CCM(而非 Kubernetes Controller Manager 中的內部雲端控制器迴圈),則必須指定 --cloud-provider=external。否則,不應指定。

請記住,設定您的叢集以使用雲端控制器管理員將會以幾種方式變更您的叢集行為

  • 指定 --cloud-provider=external 的元件將在初始化期間新增一個污點 node.cloudprovider.kubernetes.io/uninitialized,其效果為 NoSchedule。這將節點標記為需要來自外部控制器的第二次初始化,才能排程工作。請注意,如果雲端控制器管理員無法使用,則叢集中的新節點將保持無法排程狀態。此污點很重要,因為排程器可能需要關於節點的雲端特定資訊,例如其區域或類型(高 CPU、GPU、高記憶體、點執行個體等)。
  • 關於叢集中節點的雲端資訊將不再使用本機中繼資料擷取,而是所有擷取節點資訊的 API 呼叫都將通過雲端控制器管理員。這可能表示您可以限制 kubelet 對雲端 API 的存取,以提高安全性。對於較大的叢集,您可能需要考慮雲端控制器管理員是否會達到速率限制,因為它現在負責幾乎所有從叢集內部呼叫您的雲端的 API。

雲端控制器管理員可以實作

  • 節點控制器 - 負責使用雲端 API 更新 kubernetes 節點,以及刪除在您的雲端上刪除的 kubernetes 節點。
  • 服務控制器 - 負責針對 LoadBalancer 類型的服務在您的雲端上進行負載平衡。
  • 路由控制器 - 負責在您的雲端上設定網路路由
  • 如果您正在執行樹狀結構外的供應商,您可以實作任何其他功能。

範例

如果您使用的雲端目前在 Kubernetes 核心中受支援,並且想要採用雲端控制器管理員,請參閱 kubernetes 核心中的雲端控制器管理員

對於 Kubernetes 核心中沒有的雲端控制器管理員,您可以在雲端廠商或 SIG 維護的儲存庫中找到各自的專案。

對於 Kubernetes 核心中已有的供應商,您可以將樹狀結構內的雲端控制器管理員作為 DaemonSet 在您的叢集中執行,請使用以下內容作為指南

# This is an example of how to set up cloud-controller-manager as a Daemonset in your cluster.
# It assumes that your masters can run pods and has the role node-role.kubernetes.io/master
# Note that this Daemonset will not work straight out of the box for your cloud, this is
# meant to be a guideline.

---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: cloud-controller-manager
  namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: system:cloud-controller-manager
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- kind: ServiceAccount
  name: cloud-controller-manager
  namespace: kube-system
---
apiVersion: apps/v1
kind: DaemonSet
metadata:
  labels:
    k8s-app: cloud-controller-manager
  name: cloud-controller-manager
  namespace: kube-system
spec:
  selector:
    matchLabels:
      k8s-app: cloud-controller-manager
  template:
    metadata:
      labels:
        k8s-app: cloud-controller-manager
    spec:
      serviceAccountName: cloud-controller-manager
      containers:
      - name: cloud-controller-manager
        # for in-tree providers we use registry.k8s.io/cloud-controller-manager
        # this can be replaced with any other image for out-of-tree providers
        image: registry.k8s.io/cloud-controller-manager:v1.8.0
        command:
        - /usr/local/bin/cloud-controller-manager
        - --cloud-provider=[YOUR_CLOUD_PROVIDER]  # Add your own cloud provider here!
        - --leader-elect=true
        - --use-service-account-credentials
        # these flags will vary for every cloud provider
        - --allocate-node-cidrs=true
        - --configure-cloud-routes=true
        - --cluster-cidr=172.17.0.0/16
      tolerations:
      # this is required so CCM can bootstrap itself
      - key: node.cloudprovider.kubernetes.io/uninitialized
        value: "true"
        effect: NoSchedule
      # these tolerations are to have the daemonset runnable on control plane nodes
      # remove them if your control plane nodes should not run pods
      - key: node-role.kubernetes.io/control-plane
        operator: Exists
        effect: NoSchedule
      - key: node-role.kubernetes.io/master
        operator: Exists
        effect: NoSchedule
      # this is to restrict CCM to only run on master nodes
      # the node selector may vary depending on your cluster setup
      nodeSelector:
        node-role.kubernetes.io/master: ""

限制

執行雲端控制器管理員有一些可能的限制。雖然這些限制將在即將發行的版本中解決,但重要的是您要了解生產工作負載的這些限制。

卷的支援

雲端控制器管理員未實作 kube-controller-manager 中找到的任何卷控制器,因為卷整合也需要與 kubelet 協調。當我們發展 CSI(容器儲存介面)並為彈性卷外掛程式新增更強大的支援時,將會將必要的支援新增至雲端控制器管理員,以便雲端可以完全整合卷。在此處深入瞭解樹狀結構外的 CSI 卷外掛程式 here

擴充性

cloud-controller-manager 查詢您的雲端供應商的 API,以擷取所有節點的資訊。對於非常大的叢集,請考慮可能的瓶頸,例如資源需求和 API 速率限制。

雞生蛋蛋生雞

雲端控制器管理員專案的目標是將雲端功能開發與核心 Kubernetes 專案分離。不幸的是,Kubernetes 專案的許多方面都假設雲端供應商功能與專案緊密整合。因此,採用此新架構可能會產生幾種情況,在這些情況下,會要求從雲端供應商取得資訊,但雲端控制器管理員可能無法在原始請求完成之前傳回該資訊。

Kubelet 中的 TLS 引導程式功能就是一個很好的例子。TLS 引導程式假設 Kubelet 能夠向雲端供應商(或本機中繼資料服務)詢問其所有位址類型(私有、公用等),但雲端控制器管理員無法在首先初始化節點位址類型的情況下設定節點的位址類型,這需要 kubelet 具有 TLS 憑證才能與 apiserver 通訊。

隨著此計畫的發展,將在即將發行的版本中進行變更以解決這些問題。

下一步

若要建置和開發您自己的雲端控制器管理員,請閱讀 開發雲端控制器管理員