从 K8S 的 Cloud Provider 到 CCM 的演进之路
Kubernetes 是一个云原生平台,但为了让 Kubernetes 能够更好地运行在公有云平台上,能够灵活地使用、管理云上其他的基础资源和基础服务,云厂商需要实现自己的适配器。本文详细解读了 Kubernetes 从 Cloud Provider 到 Cloud Controller Mananger(CCM) 的演变过程及其实现细节,希望有助于大家更好地在公有云平台上构建基于 Kubernetes 的容 器服务。
Cloud Provider 背景概要
基于 Kubernetes 的容器云
容器云最主要的功能是帮助用户把所有的应用以容器的形式在集群中跑起来。目前很多的容器云平台通过 Docker 及 Kubernetes 等技术给应用提供运行平台,从而实现运维自动化、快速部署应用、弹性伸缩和动态调整应用环境资源,提高研发运营效率。
Cloud Provider 与云厂商
为了更好地让 Kubernetes 在公有云平台上运行,并且提供容器云服务,云厂商需要实现自己的 Cloud Provider,即实现:
cloudprovider.Interface(https://github.com/kubernetes/kubernetes/blob/master/pkg/cloudprovider/cloud.go)。
它是 Kubernetes 中开放给云厂商的通用接口,便于 Kubernetes 自动管理和利用云服务商提供的资源,这些资源包括虚拟机资源、负载均衡服务、弹性公网 IP、存储服务等。
如下图所示,Kubernetes 核心库内置了很多主流云厂商的实现,包括 AWS、GCE、Azure:
Cloud Provider 的重构之路
近几年来, Kubernetes 逐渐成为在私有云、公有云和混合云环境中大规模部署容器化应用的事实标准,以至于越来越多的云厂商加入了进来,而 Cloud Provider 的实现也越来越多。
作为在 Kubernetes 核心库中的代码,这必将影响其快速更新和迭代。 所以产生了把 Cloud Provider 移出 Kubernetes 核心库并进行重构的提案(Refactor Cloud Provider out of Kubernetes Core)。
在 Kubernetes v1.6,引入了 Cloud Controller Manager(CCM),目的就是最终替代 Cloud Provider。截止到最新的 Kubernetes v1.11,还是处于 beta 阶段。
Cloud Provider 解析
Cloud Provider 的作用
在 Kubernetes 中有三个组件对 Cloud Provider 有依赖,分别是:
-
kube-controller-manager
-
kubelet
-
kube-apiserver
这三个组件对 Cloud Provider 的依赖部分会最终编译进相应的二进制中,详细的依赖关系图如下所示:
kube-controller-manager 对于 Cloud Provider 的依赖
kube-controller-manager 对 Cloud Provider 的依赖分布在四个 Controller 中。
-
Node Controller:Node Controller 使用 Cloud Provider 来检查 Node 是否已经在云上被删除了。如果 Cloud Provider 返回有 Node 被删除,那么 Node Controller 立马就会把此 Node 从 Kubernetes 中删除。
-
Route Controller:用来配置 Node 的路由。Kubernetes 容器网络基本原则 [每个 Pod 都拥有一个独立的 IP 地址(IP per Pod),而且假定所有的 Pod 都在一个可以直接连通的、扁平的网络空间中。而在云上,Node 的基础设施是由云厂商提供的,所以 Route Controller 需要调用 Cloud Provider 来配置云上的 Node 的底层路由。]
-
Service Controller:Service Controller 不光维护了当前可用 Node 的列表,而且它同时负责创建、删除、更新类型是 LoadBalancer 的 Service、使用云厂商额外提供的负载均衡服务、弹性公网 IP 等。
-
PersistentVolumeLabel Controller:PersistentVolumeLabel Controller 使用 Cloud Provider 来创建、删除、挂载、卸载 Node 上的卷,这是因为卷也是云厂商额外提供的云存储服务。
kubelet 对于 Cloud Provider 的依赖
kubelet 中的 Node Status 使用 Cloud Provider 来获得 Node 的信息。包括:
-
nodename:运行 kubelet 的节点名字
-
InstanceID, ProviderID, ExternalID, Zone Info(在初始化 kubelet 的时候需要)
-
周期性同步的 Node 的 IP
kube-apiserver 对于 Cloud Provider 的依赖
kube-apiserver 使用 Cloud Provider 来给所有 Node 派发 SSH Keys。
Cloud Provider 的设计
云厂商在实现自己的 Cloud Provider 时只需要实现 cloudprovider.Interface 即可,如下:
在此重点阐述两个比较重要的接口 LoadBalancer() 与 Routes()。
LoadBalancer() 的接口设计
LoadBalancer() 接口用来为 kube-controller-manager 的 Service Controller 服务,接口说明如下:
Routes() 的接口设计
Routes() 接口用来为 kube-controller-manager 的 Route Controller 服务,接口说明如下:
Cloud Provider 的演变之路
从 Kubernetes v1.6 开始,Kubernetes 的编译产物中多了一个二进制:cloud-controller manager,它就是用来替代 Cloud Provider 。
因为原先的 Cloud Provider 与 Mater 中的组件 kube-controller-manager、kube-apiserver 以及 Node 中的组件 kubelet 耦合很紧密,所以这三个组件也需要进行重构。
kube-controller-manager 的重构策略
kube-controller-manager 中有四个 controller 与 Cloud Provider 相关,相应的重构策略如下:
-
Route Controller
-
移入 CCM,并在相应的 controller loop 中运行。
-
Service Controller
-
移入 CCM,并在相应的 controller loop 中运行。
-
PersistentVolumeLabel Controller
-
移入 CCM,并在相应的 controller loop 中运行。
-
Node Controller
-
在 CCM 中增加新 controller:Cloud Node Controller。
-
Cloud Node Controller 除了实现原来 Node Controller 的功能外,增加新功能:
-
CIDR 的管理
-
监控节点的状态
-
节点 Pod 的驱逐策略
-
kube-apiserver 的重构策略
对于 kube-apiserver 使用 Cloud Provider 的两个功能:
-
分发 SSH Keys
-
移入 CCM
-
对于 PV 的 Admission Controller
-
在 kubelet 中实现
kubelet的重构策略
kubelet 需要增加一个新功能:在 CCM 还未初始化 kubelet 所在节点时,需标记此节点类似“ NotReady ”的状态,防止 scheduler 调度 Pod 到此节点时产生一系列错误。此功能通过给节点加上如下 Taints 并在 CCM 初始化后删去此 Taints 来实现:
Cloud Controller Manager 解析
Cloud Controller Manager 架构
按照上述方法进行重构后,新的模块 Cloud Controller Manager 将作为一个新的组件直接部署在集群内,如下图所示:
CCM 组件内各小模块的功能与原先 Cloud Provider 的差不多(见第二部分对 Cloud Provider 的解析)。
对于云厂商来说,需要:
-
实现 cloudprovider.Interface 接口的功能,这部分在 Cloud Provider 中已经都实现,直接迁移便可。
-
实现自己的 Cloud Controller Manager,并在部署 Kubernetes 时,把 CCM 按要求部署在集群内(部署时的注意事项及部署参考实践见第五部分)。
Cloud Controller Manager 实现举例
Cloud Controller Manager 实现举例如下:
Cloud Controller Manager 的部署
总体要求
-
云厂商提供给 CCM 的 API 需要有认证鉴权机制,防止恶意行为的发生;
-
因为 CCM 运行在集群内,所以需要 RBAC 规则去跟 kube-apiserver 进行通讯;
-
为了提高 CCM 的可用,可选择主功能。
K8S 相关组件的启动配置变化
将 Cloud Provider 改为 CCM 后,相关组件启动的配置需要修改。
kube-controller-manager 启动配置变化
不指定 cloud-provider。
kube-apiserver 启动配置变化
-
不指定 cloud-provider
-
在 admission-control 中删去 PersistentVolumeLabel
-
admission-control 中增加 Initializers
-
runtime-config 中增加 admissionregistration.k8s.io/v1alpha1
kubelet 启动配置变化
指定 cloud-provider=external,在 kubelet 被调度之前需要被 CCM 初始化。(Node 会被打上 Taints:node.cloudprovider.kubernetes.io/uninitialized=true:NoSchedule)
启动 CCM 举例
启用 initializers 并添加 InitializerConifguration
CCM 为了给 PV 打标签需要:
-
启用 initializers
(https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/#enable-initializers-alpha-feature)
-
添加 InitializerConifguration:persistent-volume-label-initializer-config.yaml 如下:
创建 CCM 的 RBAC
启动 CCM
可以通过 DaemonSet 或者 Deployment 的方式启动 CCM:
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
详解K8S与Rancher 2.0内的身份认证与授权
Rancher 2.0正式版已全面发布。Rancher 2.0是一个开源的Kubernetes管理平台,为企业用户提供Kubernetes-as-a-Service (Kubernetes即服务),并且能够实现多Kubernetes集群的统一纳管。这一创造性的统一纳管功能将解决生产环境中企业用户可能面临的基础设施不同的困境。Rancher 2.0是业界第一个能统一纳管来自Google(GKE)、Amazon(EKS)和Azure(AKS)等公有云上托管的Kubernetes服务的平台。 在Rancher 2.0中,我们重点关注的一个领域就是身份认证和授权。在Kubernetes强大的基础功能之外,Rancher 2.0格外专注于简易性和易用性,它是一个既强大又易于使用的系统。Rancher 2.0让管理员能够管理多集 群环境,同时还能够帮助用户快速启动并运行环境。本文将从身份认证和授权的角度,介绍Rancher能够给组织、管理员和用户带来哪些好处。 在深入讨论Rancher能带来什么之前,我们将先在本文前半部分简要回顾一下Kubernetes身份认证与授权相关的概念。如果想深入了解这些...
- 下一篇
循序渐进的手动安装k8s笔记-3
在上一篇笔记中,我们已经可以使用 k8s1.6 版本搭建一个基础的集群,在集群内部可以完成不同 node 之间的 pod 互通并且可以完成服务发现。但已经完成的这个集群仍然是通过不安全的 8080 端口进行的,并且除了最基本的 apiserver 和 controller-manager 之间以外,其他组件间通讯都没有认证措施。这一次,我准备在集群中加入 TLS 验证来加强集群的安全性,不过这次只加入认证并不考虑授权,同时加入 kubeconfig 配置文件的机制,将apiserver地址和一些客户端证书存放在 kubeconfig 配置文件中。再安装一个新的插件 Dashboard ,用于以web方式管理集群。 这次使用的 k8s 版本是比较新的 1.10.8 。第一个原因是已经决 定使用 kubeconfig 来进行配置所以旧版本不是必须的,另一个原因是在使用 tls 证书时 1.6.0 版本出现了一些 bug,所以就决定直接将 k8s 更换成比较新的版本。到目前为止 k8s 仍在快速迭代,所以建议在使用的时候选择新一些的版本。 参考资料: 《Kubernetes权威指南》 Kub...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
-
Docker使用Oracle官方镜像安装(12C,18C,19C)
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- CentOS8编译安装MySQL8.0.19
- Docker快速安装Oracle11G,搭建oracle11g学习环境
- SpringBoot2配置默认Tomcat设置,开启更多高级功能
- MySQL8.0.19开启GTID主从同步CentOS8
- CentOS7,8上快速安装Gitea,搭建Git服务器
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果
推荐阅读
最新文章
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- CentOS6,CentOS7官方镜像安装Oracle11G
- SpringBoot2整合Redis,开启缓存,提高访问速度
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装
- SpringBoot2配置默认Tomcat设置,开启更多高级功能
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作
- Hadoop3单机部署,实现最简伪集群
- MySQL8.0.19开启GTID主从同步CentOS8
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果