controller 的职责
在K8S 拥有很多controller 他们的职责是保证集群中各种资源的状态和用户定义(yaml)的状态一致, 如果出现偏差, 则修正资源的状态.
controller manager 的职责
controller manager 是各种controller的管理者,是集群内部的管理控制中心.
controller manager 的结构
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 的职责
- 确保集群中有且仅有N 个POD的实例, N 是RC 中定义的POD 副本数量
- 通过调整 RC 的 spec.replicas 属性值来扩容或缩容
- 通过改变 RC 中的 POD 模版(主要是镜像), 来实现滚动升级.
replication controller 的使用场景
- 重新调度
- 弹性伸缩
- 滚动升级
当 RC 的spec.relicas 设置为0 时, 相关pod 将会被删除.
Node Controller
kubelet 在进程启动时通过API SERVER 注册自身节点信息, 并定时想API SERVER 回报状态信息. API server 将状态信息更新到ETCD 中.
Node Controller 核心工作流
- controller manager 判断是否有 --cluster-cidr 参数, 如果有在每个节点设置spec.PodCIDR 并保障cidr 不冲突
- 逐个读取Node 信息, 多次尝试修改nodeStatusMap中的节点状态信息, 将该节点信息和 Node Controller 的 nodeStatusMap 中保存的信息作比较.
- 如果判断出没有收到 kubelet 发送的信息, 第一次收到 kubelet 发送的的节点信息, 或在该处理过程中节点状态编程非"健康", 则在 nodeStatusMap 中保存该节点状态信息, 并用 Node Controller 所在节点的系统时间,作为探测时间和节点状态变化时间.
- 如果判断出在指定时间内受到的新的节点信息, 且节点状态发生变化, 则在 nodeStatusMap 中保存该界节点的状态信息. 并用 Node Controller 所在节点的系统时间,作为探测时间和节点状态变化时间.
- 如果判断出在指定时间内收到新的节点信息, 但状态没有变化则在 nodeStatusMap 中保存该节点的状态信息. 并用 Node Controller 所在节点的系统时间作为探测时间, 将上次节点信息中的节点状态变化时间作为该节点的状态变化时间. 如果判断出某段时间(gracePeriod) 内没有收到节点状态信息, 则设置节点状态为"位置", 并通过api server 保存节点状态.
- 逐个读取节点信息, 如果节点状态变为非"就绪"状态, 则将节点加入待删除队列, 否则将节点从该队列删除. 如果节点为非就绪状态, 且系统指定了 cloud provider, 则 Node Controller 调用 cloud provider 查看节点, 若发现节点故障 则删除etcd中的信息, 并删除该节点相关的pod 等资源信息.
ResourceQuota Controller
资源配置管理的三个级别
- 容器级别, 可以对 CPU 和 内存进行限制
- Pod 级别, 可以对一个pod 内所有容器的可用资源进行限制
- Namespace 级别, 为 Namespace (多租户) 级的资源限制包括( pod 数量, RC 数量, service 数量 ResourceQuota 数量, secret 数量, 可持有PV 数量)
K8S 的配额管理是通过admiss control 来控制的, admission control 当前提供了两种方式进行配额约束, 分别是 LimitRanger 与 ResourceQuota. 其中 LimitRanger 作用于 POD 和 Container , ResourceQuota 作用于 Namespace.
ResourceQuota controller 流程图
如图所示, 如果在 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 三者之间的关系.
- 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 被相印的创建, 删除,更新.
