Kubernetes 云管理控制器
FEATURE STATE: Kubernetes v1.18
beta
该功能目前处于 beta 状态,意味着:
- 版本名称包含 beta (例如 v2beta3)。
- 代码经过了充分测试,启用该功能被认为是安全的。默认情况下被启用。
- 对整体功能的支持在未来不会被移除,尽管细节上可能会做更改。
- 在后续的 beta 或稳定版本中,对象的模式、语义可能以不兼容的方式发生变化。当这种情况发生时,我们将提供迁移到下一个版本的说明。这可能需要删除、编辑和重建 API 对象,编辑过程可能需要一些思考。这可能导致依赖该功能的应用程序停机一段时间。
- 建议仅在非业务关键场景使用该功能,因为在后续版本中可能会发生不兼容的更改。如果您有多个可以独立升级的集群,那么您可能可以放松这个限制。
- 请尝试使用我们的 beta 版功能,并给出反馈!在它们退出 beta 测试阶段之后,我们将很难去做更多的更改。
Kubernetes v1.6 包含一个新的二进制文件,叫做 cloud-controller-manager
。cloud-controller-manager
是一个嵌入了特定云服务控制循环逻辑的守护进程。这些特定云服务控制循环逻辑最初存在于 kube-controller-manager
中。由于云服务提供商开发和发布的速度与 Kubernetes 项目不同,将服务提供商专用代码从 cloud-controller-manager
二进制中抽象出来有助于云服务厂商在 Kubernetes 核心代码之外独立进行开发。
cloud-controller-manager
可以被链接到任何满足 cloudprovider.Interface 约束的云服务提供商。为了兼容旧版本,Kubernetes 核心项目中提供的 cloud-controller-manager 使用和 kube-controller-manager
相同的云服务类库。已经在 Kubernetes 核心项目中支持的云服务提供商预计将通过使用 in-tree 的 cloud-controller-manager 过渡到 Kubernetes 核心之外。在将来的 Kubernetes 发布中,所有的云管理控制器将在 Kubernetes 核心项目之外,由 sig 领导者或者云服务厂商进行开发。
管理
需求
每个云服务都有一套各自的需求用于系统平台的集成,这不应与运行 kube-controller-manager
的需求有太大差异。作为经验法则,你需要:
- 云服务认证 / 授权:您的云服务可能需要使用令牌或者 IAM 规则以允许对其 API 的访问
- kubernetes 认证 / 授权:cloud-controller-manager 可能需要 RBAC 规则以访问 kubernetes apiserver
- 高可用:类似于 kube-controller-manager,您可能希望通过主节点选举(默认开启)配置一个高可用的云管理控制器。
运行云管理控制器
您需要对集群配置做适当的修改以成功地运行云管理控制器:
- 一定不要为
kube-apiserver
和kube-controller-manager
指定--cloud-provider
标志。这将保证它们不会运行任何云服务专用循环逻辑,这将会由云管理控制器运行。未来这个标记将被废弃并去除。 kubelet
必须使用--cloud-provider=external
运行。这是为了保证让 kubelet 知道在执行任何任务前,它必须被云管理控制器初始化。
请记住,设置群集使用云管理控制器将用多种方式更改群集行为:
- 指定了
--cloud-provider=external
的 kubelet 将被添加一个node.cloudprovider.kubernetes.io/uninitialized
的污点,导致其在初始化过程中不可调度(NoSchedule
)。这将标记该节点在能够正常调度前,需要外部的控制器进行二次初始化。请注意,如果云管理控制器不可用,集群中的新节点会一直处于不可调度的状态。这个污点很重要,因为调度器可能需要关于节点的云服务特定的信息,比如他们的区域或类型(high cpu, gpu, high memory, spot instance 等)。 - 集群中节点的云服务信息将不再能够从本地元数据中获取,取而代之的是所有获取节点信息的 API 调用都将通过云管理控制器。这意味着你可以通过限制到 kubelet 云服务 API 的访问来提升安全性。在更大的集群中您可能需要考虑云管理控制器是否会遇到速率限制,因为它现在负责集群中几乎所有到云服务的 API 调用。
对于 v1.8 版本,云管理控制器可以实现:
- node 控制器 - 负责使用云服务 API 更新 kubernetes 节点并删除在云服务上已经删除的 kubernetes 节点。
- service 控制器 - 负责在云服务上为类型为 LoadBalancer 的 service 提供负载均衡器。
- route 控制器 - 负责在云服务上配置网络路由。
- 如果您使用的是 out-of-tree 提供商,请按需实现其余任意特性。
示例
如果当前 Kubernetes 内核支持您使用的云服务,并且想要采用云管理控制器,请参见 kubernetes 内核中的云管理控制器。
对于不在 Kubernetes 内核中的云管理控制器,您可以在云服务厂商或 sig 领导者的源中找到对应的项目。
对于已经存在于 Kubernetes 内核中的提供商,您可以在集群中将 in-tree 云管理控制器作为守护进程运行。请使用如下指南:
admin/cloud/ccm-example.yaml |
---|
|
限制
运行云管理控制器会有一些可能的限制。虽然以后的版本将处理这些限制,但是知道这些生产负载的限制很重要。
对 Volume 的支持
云管理控制器未实现 kube-controller-manager
中的任何 volume 控制器,因为和 volume 的集成还需要与 kubelet 协作。由于我们引入了 CSI (容器存储接口,container storage interface) 并对弹性 volume 插件添加了更强大的支持,云管理控制器将添加必要的支持,以使云服务同 volume 更好的集成。请在 这里 了解更多关于 out-of-tree CSI volume 插件的信息。
可扩展性
在以前为云服务提供商提供的架构中,我们依赖 kubelet 的本地元数据服务来获取关于它本身的节点信息。通过这个新的架构,现在我们完全依赖云管理控制器来获取所有节点的信息。对于非常大的集群,您需要考虑可能的瓶颈,例如资源需求和 API 速率限制。
鸡和蛋的问题
云管理控制器的目标是将云服务特性的开发从 Kubernetes 核心项目中解耦。不幸的是,Kubernetes 项目的许多方面都假设云服务提供商的特性同项目紧密结合。因此,这种新架构的采用可能导致某些场景下,当一个请求需要从云服务提供商获取信息时,在该请求没有完成的情况下云管理控制器不能返回那些信息。
Kubelet 中的 TLS 引导特性是一个很好的例子。目前,TLS 引导认为 Kubelet 有能力从云提供商(或本地元数据服务)获取所有的地址类型(私有、公用等),但在被初始化之前,云管理控制器不能设置节点地址类型,而这需要 kubelet 拥有 TLS 证书以和 apiserver 通信。
随着这种措施的演进,将来的发行版中将作出改变来解决这些问题。
开发自己的云管理控制器
要构建和开发您自己的云管理控制器,请阅读 开发云管理控制器 文档。