从 K8S 的 Cloud Provider 到 CCM 的演进之路-低调大师

从 K8S 的 Cloud Provider 到 CCM 的演进之路

2018-12-16 650

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：

本文转自掘金-从 K8S 的 Cloud Provider 到 CCM 的演进之路

微信关注我们

原文链接：https://yq.aliyun.com/articles/680094

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道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身份认证与授权相关的概念。如果想深入了解这些...

2018-12-17

569

在上一篇笔记中，我们已经可以使用 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...

2018-12-17

604

资源下载

更多资源

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。

Rocky Linux

Rocky Linux（中文名：洛基）是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版，作为CentOS稳定版停止维护后与RHEL（Red Hat Enterprise Linux）完全兼容的开源替代方案，由社区拥有并管理，支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性，采用模块化包装和SELinux安全架构，默认包含GNOME桌面环境及XFS文件系统，支持十年生命周期更新。

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能，例如代码缩略图，Python的插件，代码段等。还可自定义键绑定，菜单和工具栏。Sublime Text 的主要功能包括：拼写检查，书签，完整的 Python API ， Goto 功能，即时项目切换，多选择，多窗口等等。Sublime Text 是一个跨平台的编辑器，同时支持Windows、Linux、Mac OS X等操作系统。