云控制器管理器管理

由于云提供商的开发和发布速度与 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

成功运行 cloud-controller-manager 需要对您的集群配置进行一些更改。

• kubelet、kube-apiserver 和 kube-controller-manager 必须根据用户对外部 CCM 的使用情况进行设置。如果用户具有外部 CCM（不是 Kubernetes Controller Manager 中的内部云控制器循环），则必须指定 --cloud-provider=external。否则，不应指定它。

请记住，设置您的集群以使用 cloud controller manager 将以几种方式改变您的集群行为

• 指定 --cloud-provider=external 的组件将在初始化期间添加一个具有 NoSchedule 效应的污点 node.cloudprovider.kubernetes.io/uninitialized。这将标记节点，表示需要由外部控制器进行第二次初始化，然后才能为其调度工作。请注意，如果 cloud controller manager 不可用，则集群中的新节点将保持不可调度状态。污点很重要，因为调度程序可能需要有关节点的云特定信息，例如其区域或类型（高 CPU、GPU、高内存、现货实例等）。
• 有关集群中节点的云信息将不再使用本地元数据检索，而是所有检索节点信息的 API 调用将通过 cloud controller manager 进行。这意味着您可以限制 kubelet 对云 API 的访问，以提高安全性。对于更大的集群，您可能需要考虑 cloud controller manager 是否会遇到速率限制，因为它现在负责集群内几乎所有对云的 API 调用。

cloud controller manager 可以实现

• 节点控制器 - 负责使用云 API 更新 Kubernetes 节点，并删除在云上删除的 Kubernetes 节点。
• 服务控制器 - 负责针对类型为 LoadBalancer 的服务在您的云上创建负载均衡器。
• 路由控制器 - 负责在您的云上设置网络路由
• 如果您运行的是树外提供商，则您可以实现您想实现的任何其他功能。

示例

如果您正在使用当前在 Kubernetes 核心支持的云，并且想要采用 cloud controller manager，请参阅 kubernetes 核心中的云控制器管理器。

对于不在 Kubernetes 核心中的 cloud controller manager，您可以在由云供应商或 SIG 维护的存储库中找到相应的项目。

对于已经在 Kubernetes 核心中的提供商，您可以在集群中将树内 cloud controller manager 作为 DaemonSet 运行，以下作为指南

admin/cloud/ccm-example.yaml

# 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: ""

限制

运行 cloud controller manager 会带来一些可能的限制。尽管这些限制在即将发布的版本中得到解决，但了解这些限制以用于生产工作负载很重要。

对卷的支持

cloud controller manager 未实现 kube-controller-manager 中的任何卷控制器，因为卷集成还需要与 kubelet 进行协调。随着我们发展 CSI（容器存储接口）并为 flex volume 插件提供更强的支持，将向 cloud controller manager 添加必要的支持，以便云能够与卷完全集成。了解有关树外 CSI 卷插件的更多信息 此处。

可扩展性

cloud-controller-manager 查询您的云提供商的 API 以检索所有节点的信息。对于非常大的集群，请考虑可能的瓶颈，例如资源需求和 API 速率限制。

鸡和蛋

cloud controller manager 项目的目标是将云功能的开发与核心 Kubernetes 项目分离。不幸的是，Kubernetes 项目的许多方面都假设云提供商功能与该项目紧密集成。因此，采用这种新的架构会创建几种情况，即正在向云提供商请求信息，但 cloud controller manager 可能无法在原始请求完成之前返回该信息。

一个很好的例子是 Kubelet 中的 TLS 引导功能。TLS 引导假设 Kubelet 能够向云提供商（或本地元数据服务）请求其所有地址类型（私有、公共等），但 cloud controller manager 无法在初始化之前设置节点的地址类型，这要求 Kubelet 拥有 TLS 证书才能与 apiserver 通信。

随着该计划的发展，将在即将发布的版本中进行更改以解决这些问题。

下一步

若要构建和开发您自己的 cloud controller manager，请阅读 开发云控制器管理器。