云控制器管理器管理

特性状态: Kubernetes v1.11 [beta]

由于云提供商的开发和发布速度与 Kubernetes 项目不同,因此将提供商特定的代码抽象到 云控制器管理器 二进制文件中,允许云供应商独立于 Kubernetes 核心代码进行演进。

云控制器管理器 可以链接到满足 cloudprovider.Interface 的任何云提供商。为了保持向后兼容性,核心 Kubernetes 项目中提供的 云控制器管理器 使用与 kube-controller-manager 相同的云库。预计 Kubernetes 核心中已受支持的云提供商将使用树内云控制器管理器,以退出 Kubernetes 核心。

管理

要求

每个云都有其自身的一组运行其自身云提供商集成的要求,这不应与运行 kube-controller-manager 的要求有太大不同。作为一般经验法则,您需要

  • 云身份验证/授权:您的云可能需要令牌或 IAM 规则才能允许访问其 API
  • kubernetes 身份验证/授权:云控制器管理器可能需要 RBAC 规则才能与 kubernetes apiserver 通信
  • 高可用性:与 kube-controller-manager 类似,您可能需要使用领导者选举(默认启用)为云控制器管理器设置高可用性。

运行云控制器管理器

成功运行云控制器管理器需要对您的集群配置进行一些更改。

  • kubeletkube-apiserverkube-controller-manager 必须根据用户使用外部 CCM 的情况进行设置。如果用户拥有外部 CCM(不是 Kubernetes 控制器管理器中的内部云控制器循环),则必须指定 --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(容器存储接口)并为 flex 卷插件添加更强大的支持,将向云控制器管理器添加必要的支持,以便云可以完全与卷集成。了解有关树外 CSI 卷插件的更多信息 此处

可伸缩性

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

先有鸡还是先有蛋

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

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

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

接下来

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