云控制器管理器管理

特性状态: 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 的组件将在初始化期间添加一个具有 NoSchedule 效果的污点 node.cloudprovider.kubernetes.io/uninitialized。这会将节点标记为在外部控制器进行第二次初始化之前需要进行调度工作。请注意,在云控制器管理器不可用的情况下,集群中的新节点将保持不可调度。该污点很重要,因为调度器可能需要有关节点的云特定信息,例如其区域或类型(高 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 通信。

随着这项倡议的发展,将在即将发布的版本中进行更改以解决这些问题。

下一步

要构建和开发你自己的云控制器管理器,请阅读 开发云控制器管理器