K8S 核心组件 Controller manager

controller 的职责

在K8S 拥有很多controller 他们的职责是保证集群中各种资源的状态和用户定义(yaml)的状态一致, 如果出现偏差, 则修正资源的状态.

controller manager 的职责

controller manager 是各种controller的管理者,是集群内部的管理控制中心.

controller manager 的结构

image.png

Replication controller

controller manager 中的 Replication controller(副本控制器) 和 K8S 中的资源 replication controller 不是同一个东西, 为了区别, 此处将资源类型的 replication controller 用RC 表示, controller manager 中的replication controller 仍然用 replication controller 表示,指代副本控制器.

replication controller 的核心作用是保障集群中某个 RC 关联的pod副本数与预设值一致. 当pod 重启策略为always 时(RestartPolicy=Always), Replication Controller 才会管理该 POD 的操作(创建, 销毁, 重启等), 在默认情况下, POD 对象被创建成功后不会消失, 唯一例外是当pod 处于succeed 或failed 状态的实践过长(超时参数由系统设定)时, 该pod 会被系统自动回收, 管理该 pod 的副本控制器将在其他工作节点上重新创建,运行该POD 副本.

RC 中的POD 模版就像模具, POD 一旦通过模版制作出来,就和RC 再也没有联系了. 无论模版如何变化, 甚至换成一个新的模版, 也不会影响到已经创建的POD . 因此POD 可以通过修改标签来脱离 RC 的管控. 改方法可以用于将POD 从集群中迁移, 数据修复等调试.

replication controller 的职责

1. 确保集群中有且仅有N 个POD的实例, N 是RC 中定义的POD 副本数量
2. 通过调整 RC 的 spec.replicas 属性值来扩容或缩容
3. 通过改变 RC 中的 POD 模版(主要是镜像), 来实现滚动升级.

replication controller 的使用场景

1. 重新调度
2. 弹性伸缩
3. 滚动升级

当 RC 的spec.relicas 设置为0 时, 相关pod 将会被删除.

Node Controller

kubelet 在进程启动时通过API SERVER 注册自身节点信息, 并定时想API SERVER 回报状态信息. API server 将状态信息更新到ETCD 中.

Node Controller 核心工作流

image.png

1. controller manager 判断是否有 --cluster-cidr 参数, 如果有在每个节点设置spec.PodCIDR 并保障cidr 不冲突
2. 逐个读取Node 信息, 多次尝试修改nodeStatusMap中的节点状态信息, 将该节点信息和 Node Controller 的 nodeStatusMap 中保存的信息作比较.
   1. 如果判断出没有收到 kubelet 发送的信息, 第一次收到 kubelet 发送的的节点信息, 或在该处理过程中节点状态编程非"健康", 则在 nodeStatusMap 中保存该节点状态信息, 并用 Node Controller 所在节点的系统时间,作为探测时间和节点状态变化时间.
   2. 如果判断出在指定时间内受到的新的节点信息, 且节点状态发生变化, 则在 nodeStatusMap 中保存该界节点的状态信息. 并用 Node Controller 所在节点的系统时间,作为探测时间和节点状态变化时间.
   3. 如果判断出在指定时间内收到新的节点信息, 但状态没有变化则在 nodeStatusMap 中保存该节点的状态信息. 并用 Node Controller 所在节点的系统时间作为探测时间, 将上次节点信息中的节点状态变化时间作为该节点的状态变化时间. 如果判断出某段时间(gracePeriod) 内没有收到节点状态信息, 则设置节点状态为"位置", 并通过api server 保存节点状态.
3. 逐个读取节点信息, 如果节点状态变为非"就绪"状态, 则将节点加入待删除队列, 否则将节点从该队列删除. 如果节点为非就绪状态, 且系统指定了 cloud provider, 则 Node Controller 调用 cloud provider 查看节点, 若发现节点故障 则删除etcd中的信息, 并删除该节点相关的pod 等资源信息.

ResourceQuota Controller

资源配置管理的三个级别

1. 容器级别, 可以对 CPU 和 内存进行限制
2. Pod 级别, 可以对一个pod 内所有容器的可用资源进行限制
3. Namespace 级别, 为 Namespace (多租户) 级的资源限制包括( pod 数量, RC 数量, service 数量 ResourceQuota 数量, secret 数量, 可持有PV 数量)

K8S 的配额管理是通过admiss control 来控制的, admission control 当前提供了两种方式进行配额约束, 分别是 LimitRanger 与 ResourceQuota. 其中 LimitRanger 作用于 POD 和 Container , ResourceQuota 作用于 Namespace.

ResourceQuota controller 流程图

image.png

如图所示, 如果在 POD 中声明了 limitRanger, 则用户通过 api server 清酒创建或修改资源时, admission controller 会计算当前配额的使用情况, 如果不符合配额约束则失败. 对于定义了resourceQuota 的Namespace, ResourceQuota Controller 组件则负责顶起统计和生成该Namespace 的资源总量, 然后将结果写入etcd 的 resourceQuotaStatusStorage 目录(resourceQuota/status)下, 这些指被admission controller 使用.

Namespace Controller

管理namespace的生命周期.

Namespace的优雅删除(通过设置DeletionTimestamp属性), Namespace 会被设置为Terminating 状态并保存到etcd中, Namespace Controller开始删除下面的所有资源, 与此同时Admission Controller 的 NamespaceLifecycle 插件会阻止在该 Namespace 创建资源.

Service Controller 和 Endpoint Controller

Service Endpoint Pod 三者之间的关系.

image.png

• endpoint 表示一个service 对应的所有pod副本的访问地址, endpoint controller 就是负责生成和维护所有 endpoint 对象的控制器. endpoint 被kube-proxy 所消费, kube-proxy 获取每个service 的endpoint, 实现 service的负载均衡功能

service controller 属于K8S 集群与外部的云平台之间的一个接口控制器, Service Controller 监听 Service的变化, 如果该 Service 是一个 Loadbalance 类型(externalLoadBalances=true), 则 service controller 确保在外部的云平台上该Service 对应的 Loadbalance 被相印的创建, 删除,更新.