一、概述

为集群内部的管理控制中心，负责集群内的 Node 、Pod 副本、服务端点（ Endpoint ）、命名空间（ Namespace ）、服务账号（ ServiceAccount ）、资源定额（ ResourceQuota) 等的管理，当某个 Node 意外岩机时， Controller Manager 会及时发现此故障并执行自动化修复流程，确保集群始终处于预期的工作状态。

主要包括：

1
2
3
4
5
6
7
8
Replication Controller 
Node Controller
ResourceQuota Controller 
Namespace Controller 
ServiceAccount Controller 
Token Controller
Service Controller 
Endpoint Controller

在 Kubernetes 集群中，每个 Controller 都是不断修正系统的工作状态，它们通过API Server 提供的接口实时监控整个集群里的每个资源对象的当前状态，当发生各种故障导致系统状态发生变化时，会尝试着将系统状态从“现有状态”修正到“期望状态”

二、Replication Controller

是确保在任何时候集群中 RC 所关联的 Pod 副本数保持预设值。只有当 Pod 的重启策略是 Always 时（ RestartPolicy=Always), Replication Controller 才会管理该 Pod 的操作（例如创建、销毁、重启等）。在通常情况下， Pod 对象被成功创建后不会消失，唯一的例外是当 Pod 处于 succeeded/failed 状态的时间过长（超时参数由系统设定）时，该 Pod 会被系统自动回收，管理该 Pod 的副本控制器将在其他工作节点上重新创建、运行该 Pod 副本。

最好不要越过 RC 直接创建 Pod ，因为 Replication Controller 会通过 RC 管理 Pod 副本，实现自动创建、补足、替换、删除 Pod 副本，这样能提高系统的容灾能力，减少由于节点崩溃等意外状况造成的损失。

职责：

  • 确保当前集群中有且仅有N个 Pod 实例，N是 RC 中定义的 Pod 副本数量。
  • 调整 RC spec.replicas 属性值来实现系统扩容或者缩容。
  • 改变 RC 中的 Pod 模板（主要是镜像版本）来实现系统的滚动升级。

使用场景

  • 重新调度 Rescheduling
  • 弹性伸缩 Scaling
  • 滚动更新 Rolling Updates 。

三、Node Controller

kubelet 程在启动时通过 API Server 注册自身的节点信息，并定时向 API Server 汇报状态信息， API Server 接收到这些信息后，将这些信息更新到 etcd 中， etcd 存储的节点信息包括节点健康状况、节点资源、节点名称、节点地址信息、操作系统版本、 Docker 版本、 kubelet版本等 节点健康状况包含就绪（ True ）未就绪（ False ）和未知”（u nown）

Node Controller 通过 API Server 实时获取 Node 的相关信息 实现管理和监控集群中的各个Node 节点的相关控制功能。

image-20211107220327058

流程如下：

  • Controller Manager 在启动时如果设置了--cluster-cidr 参数，那么为每个没有设置Spec.PodCIDR的Node 节点生成一个 CIDR 地址，井用该 CIDR 地址设置节点的 Spec.PodCIDR属性，这样做的目的是防止不同节点的 CIDR 地址发生冲突
  • 读取节点信息，将该节点信息和 Nod Controller nodeStatusMap 中保存的节点信息做比较，尝试修改和nodeStatusMap中的节点状态信息。
    • 判断出没有收到kubelet 发送的节点信息、第一次收到节点 kubelet 发送的节点信息，或在该处理过程中节点状态变成非“健康”状态，则在 nodeStatusMap 中保存该节点的状态信息，并用 Node Controller 所在节点的系统时间作为探测时间和节点状态变化时间。
    • 如果判断出在指定时间内收到新的节点信息，且节点状态发生变化，则 nodeStatusMap 中保存该节点 的状态信息，并用 NodeController 所在节点的系统时间作为探测时间和节点状态变化时间。
    • 如果判断出在指定时间内收到新的节点信息，但节点状态没发生变化，则在 nodeStatusMap 中保存该节点的状态信息，井用 Node Controller 所在节点的系统时间作为探测时间，用上次节点信息中的节点状态变化时间作为该节点的状态变化时间 。
    • 判断在某段时间（ gracePeriod ）内没有收到节点状态信息，则设置节点状态为“未知” （unKnown ）
  • 如果节点状态变为非“就绪”状态，则将节点加入待删除队列，否则将节点从该队列中删除 如果节点状态为非“就绪”状态，且系统指定了 Cloud Provider, Node Controller 调用 Cloud Provider 查看节点,若发现节点故障，则删除 etcd 中的节点信息，并删除和该节点相关的 Pod 等资源的信息。

四、ResourceQuota Controller

资源配额管理确保了指定的资源对象在任何时候都不会超量占用系统物理资源，避免了由于某些业务 的设计或实现的缺陷导致 个系统运行紊乱甚至意外岩机，对整个集群的平稳运行和稳定性有非常重要的作用。

支持三个层次的资源配额

  • 容器级别 ，可以对 CPU Memory 进行限制
  • Pod 级别，可以 Pod 内所有容器的可用资源进行限制。
  • Namespace 级别 Namespace （多租户）级别的资源限制
    • Pod 数量
    • Replication Controller 数量
    • Service 数量
    • ResourceQuota 数量
    • Secret数量
    • 可持有的 PV (Persistent Volume ）数量

配额管理是通过 Admission Control (准入控制)来控制的 。Admission Control 当前提供了两种方式的配额约束，分别是 LimitRanger 和ResourceQuota 。其中 imitRanger用于 Pod和Container 上，而 ResourceQuota 则作用于 Namespace 上，限定 Namespace 里的各类资源的使用总额。

如果在 Pod 定义中同时声明了 LimitRanger ，则用户通过 API Server 请求创建或修改资源时， Admission Control 会计算当前配额的使用情况，如果不符合配额约束，则创建对象失败。

定义了 ResourceQuota的Namespace, ResourceQuota Controller 组件则负责定期统计和生成该 Namespace 下的各类对象的资源使用总量，统计结果包括 Pod Service RC Secret Persistent Volume 等对象实例个数，以及该 Namespace 下所有 Container 实例所使用的资源量（目前包括 CPU 和内存），然后将这些统计结果写入etcd 的resourceQuotaStatusStorage目录（resourceQuotas status ）中。写 resourceQuotaStatusStorage 的内容包含 resource 名称、配额值（ ResourceQuota 对象中 spec.hard 域下包含的资源的值）、当前使用值（ ResourceQuota Controller 统计出来的值）。随后这些信息被 Admission Control 使用，以确保相关 Namespace下的资源配额总量不会超过 ResourceQuota 中的限定值。

image-20211108210946652

五、Namespace Controller

用户通过 API Server 以创建新 Namespace 并保存在 etcd 中， Namespace Controller定时通过 API Server 读取这些 Namespace 信息。 Namespace被API 标识为优雅删除 （通过设删除期限，即 DeletionTimestamp 属性被设置）， 则将 NameSpace 状态设置成Terminating保存到 etcd 中。同时 Namespace Controller 删除该 Namespace 下的 ServiceAccount RC Pod Secret PersistentVolume ListRange ResourceQuota Event 等资源对象

Namespace 的状态被设置成’terminating ”后，由 Admission Controller 的NamespaceLifecycle插件来*阻止为该 mamespace 创建新资源 *。 Namespace Controller 删除完该 Namespace所有资源对象后， 对该 Namespace执行finalize 是删除Namespace的spec.finalizer 域中的信息

如果观察到 Namespace 设置了删除期限， Namespace的spec.finalizer 域值是空， 那么 将通 API Server 除该 Namespace 资源。

六、Service Controller Endpoint Controller

Service、Endpoints、Pod的关系：

image-20211108212003669

Endpoint 表示 Service 对应所有 Pod 副本的访问地址， Endpoints Controller 就是负则生成和维护所有 Endpoints控制器

负责监听 Service 和对应的 Pod副本的变化，如果监测到 Service 被删除，则删除和该Service 同名的 Endpoints 对象。如果监测到新的 Service 被创建或者修改，则根据该 Service信息获得相关的 Pod表，然后创建或者更新 Service 对应的 Endpoints 对象 如果监测到 Pod的事件，则更新它所对应的 Service的Endpoints 对象（增加、删除或者修改对应的 Endpoint条目）

Endpoints 对象被每个Node上的kube-proxy进程使用，kube-proxy获取每个Service的Endpoints,实现Service的负载均衡。

Service Controller属于 Kubernetes 集群与外部的云平台之间的一个接口控制器。监听 Service 的变化，如果是 LoadBalancer类型的 Service，则 Service Controller 确保外部的云平台上该Service 对应的 LoadBalancer 实例被相应地创建、删除及更新路由转发 （根据 Endpoints条目）