云控制器管理器管理

功能状态: 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 需要对您的集群配置进行一些更改。

  • 必须根据用户对外部 CCM 的使用情况设置 kubeletkube-apiserverkube-controller-manager。如果用户有外部 CCM(而不是 Kubernetes 控制器管理器中的内部云控制器循环),则必须指定 --cloud-provider=external。否则,不应指定。

请记住,设置集群以使用云控制器管理器将以几种方式更改您的集群行为。

  • 指定 --cloud-provider=external 的组件将在初始化期间添加一个污点 node.cloudprovider.kubernetes.io/uninitialized,其效果为 NoSchedule。这会将节点标记为需要外部控制器进行第二次初始化,然后才能调度工作。请注意,如果云控制器管理器不可用,则集群中的新节点将无法调度。该污点很重要,因为调度程序可能需要有关节点的云特定信息,例如其区域或类型(高 CPU、GPU、高内存、Spot 实例等)。
  • 有关集群中节点的云信息将不再使用本地元数据检索,而是所有检索节点信息的 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(容器存储接口)并为 flex 卷插件添加更强的支持,必要的支持将添加到云控制器管理器,以便云可以与卷完全集成。在此处了解有关树外 CSI 卷插件的更多信息 这里

可扩展性

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

先有鸡还是先有蛋

云控制器管理器项目的目标是将云功能的开发与核心 Kubernetes 项目分离。不幸的是,Kubernetes 项目的许多方面都假设云提供商功能与该项目紧密集成。因此,采用这种新架构可能会导致多种情况,即请求从云提供商获取信息,但是云控制器管理器可能无法在原始请求完成之前返回该信息。

这方面的一个很好的例子是 Kubelet 中的 TLS 引导功能。TLS 引导假设 Kubelet 有能力向云提供商(或本地元数据服务)请求其所有地址类型(私有、公共等),但是云控制器管理器无法在首先初始化的情况下设置节点的地址类型,这要求 kubelet 具有与 apiserver 通信的 TLS 证书。

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

下一步

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