K8S 核心组件 Controller manager

Posted 2023-03-01

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

controller manager 是各种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 的职责

replication controller 的使用场景

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

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

资源配置管理的三个级别

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

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

管理namespace的生命周期.

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

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