ControllerManager控制器管理器

API服务器只是决定了各类资源实例的状态,称之为期望状态,而将实例的实际状态收敛至期望状态的,是Controller Manager 控制器管理器

Controller Manager中组合了多个执行不同非冲突任务的控制器,这些控制器会被分解到不同的进程,如果需要,我们可以自定义甚至替换它们每一个。控制器包括:

  • Replication控制器(ReplicationController资源的管理器);

  • ReplicaSet、DaemonSet以及Job控制器;

  • Deployment控制器;

  • StatefulSet控制器;

  • Node控制器;

  • Service控制器;

  • Endpoints控制器;

  • Namespace控制器;

  • PersistentVolume控制器;

  • 其他;

控制器通过监听API服务器,当发现其关注的资源类型的实例的期望状态发生了变化,会通过API服务器对资源进行相应的操作。操作通常包含:新建其他资源、更新监听的资源本身(例如,更新对象的status)。

总的来说,控制器执行一个“调和”循环,将实际状态调整为期望状态(在资源spec部分定义),然后将新的实际状态写入资源的status部分。

Replication控制器

ReplicationController的操作可以理解为一个无限循环,每次循环,控制器都会查找符合其Pod选择器定义的Pod的数量,并且将该数值和期望的复制集 (replica) 数量做比较。

控制器不会每次循环去轮询Pod, 而是通过监听机制订阅可能影响期望的复制集 (replica) 数量或者符合条件Pod数量的变更事件。

任何该类型的变化,将触发控制器重新检查期望的以及实际的复制集数量,然后做出相应操作。

当运行的Pod实例太少时,ReplicationController会运行额外的实例,但它自己实际上不会去运行Pod。它会创建新的Pod清单,发布到API服务器,让调度器以及kubelet来做调度工作并运行Pod。

Replication管理器监听API对象变更

ReplicaSet、DaemonSet、Job控制器

ReplicaSet控制器基本上做了和前面描述的Replication管理器一样的事情,所以这里不再赘述。

DaemonSet以及Job控制器比较相似,从它们各自资源集中定义的Pod模板创建Pod资源,并发布到API服务器,让调度器及kubelet来做调度并运行Pod。

Deployment控制器

Deployment控制器负责使Deployment资源的实际状态与对应资源对象的期望状态同步。

每次Deployment对象修改后(如果修改会影响到部署的Pod), Deployment控制器都会滚动升级到新的版本。通过创建一个ReplicaSet资源,然后按照Deployment中定义的策略同时伸缩新、旧ReplicaSet资源,直到旧Pod被新的代替。并不会直接创建任何Pod。

StatefulSet控制器

StatefulSet控制器,类似于ReplicaSet控制器以及其他相关控制器,根据StatefulSet资源定义创建、管理、删除Pod。其他的控制器只管理Pod,而StatefulSet控制器会初始化并管理每个Pod实例的持久卷声明(PVC)字段。

Node控制器

Node控制器管理Node资源,描述了集群工作节点。其中,Node控制器使Node对象列表与集群中实际运行的Node列表保持同步。同时监控每个Node的健康状态,删除不可达节Node的Pod。

Service控制器

Service控制器就是用来在LoadBalancer类型服务被创建或删除时,从基础设施服务请求、释放负载均衡器的。

Endpoint控制器

您可能还记得,Service不会直接连接到Pod,而是包含一个端点列表 (IP和端口),列表要么是手动,要么是根据Service定义的Pod选择器自动创建、更新。

当Service被添加、修改,或者Pod被添加、修改或删除时,控制器会选中匹配Service的Pod选择器的Pod, 将其IP和端口添加到Endpoint资源中。请记住,Endpoint对象是个独立的对象,所以当需要的时候控制器会创建它。同样地,当删除Service时,Endpoint对象也会被删除。

Endpoint控制器监听Service和Pod资源并管理Endpoint

Namespace控制器

当删除一个Namespace资源时,该命名空间里的所有资源都会被删除。这就是Namespace控制器做的事情。

PersistentVolume控制器

一旦用户创建了一个持久卷声明(PVC),Kubernetes必须找到一个合适的持久卷(PV)同时将其和声明(PVC)绑定。这些由PersistentVolume控制器实现。

对于一个持久卷声明,控制器为声明查找最佳匹配项,通过选择匹配声明中的访问模式,并且声明的容量大于需求的容量的最小持久卷。

当用户删除持久卷声明时,会解绑卷,然后根据卷的回收策略进行回收(原样保留、删除或清空)。

Last updated

Was this helpful?