Kubernetes权威指南——核心组件运行机制（Controller Manager原理解析）

核心组件运行机制2、Controller Manager原理解析2.1、Replication Controller2.2、Node Controller2.3、ResourceQuota Controller2.4、Namespace Controller2.5、Service Controller与Endpoints Controller2、Controller Manager原理解析一般来说智能系统和自动系统通常会通过一个“操作系统”来不断修正系统的工作状态。在Kubernetes集群中每个Controller都是这样的一个“操作系统”​它们通过API Server提供的List-Watch接口实时监控集群中特定资源的状态变化当发生各种故障导致某资源对象的状态发生变化时Controller会尝试将其状态调整为期望的状态。比如当某个Node意外宕机时NodeController会及时发现此故障并执行自动化修复流程确保集群始终处于预期的工作状态。Controller Manager是Kubernetes中各种操作系统的管理者是集群内部的管理控制中心也是Kubernetes自动化功能的核心。如图所示Controller Manager内部包含Replication Controller、Node Controller、ResourceQuotaController、Namespace Controller、ServiceAccountController、Token Controller、Service Controller及Endpoint Controller这8种Controller每种Controller都负责一种特定资源的控制流程而Controller Manager正是这些Controller的核心管理者。由于ServiceAccount Controller与Token Controller是与安全相关的两个控制器并且与Service Account、Token 密切相关所以我们将对它们的分析放到后面讲解。在Kubernetes集群中与Controller Manager并重的另一个组件是Kubernetes Scheduler它的作用是将待调度的Pod包括通过API Server新创建的Pod及RC为补足副本而创建的Pod等通过一些复杂的调度流程计算出最佳目标节点然后绑定到该节点上。本章最后会介绍Kubernetes Scheduler调度器的基本原理。2.1、Replication Controller为了区分Controller Manager中的Replication Controller副本控制器和资源对象Replication Controller我们将资源对象Replication Controller简写为RC而本节中的Replication Controller是指“副本控制器”​以便于后续分析。Replication Controller的核心作用是确保在任何时候集群中某个RC关联的Pod副本数量都保持预设值。如果发现Pod的副本数量超过预期值则Replication Controller会销毁一些Pod副本反之Replication Controller会自动创建新的Pod副本直到符合条件的Pod副本数量达到预设值。需要注意只有当Pod的重启策略是Always时RestartPolicyAlways​Replication Controller才会管理该Pod的操作例如创建、销毁、重启等​。在通常情况下Pod对象被成功创建后不会消失唯一的例外是当Pod处于succeeded或failed状态的时间过长超时参数由系统设定时该Pod会被系统自动回收管理该Pod的副本控制器将在其他工作节点上重新创建、运行该Pod副本。RC中的Pod模板就像一个模具模具制作出来的东西一旦离开模具它们之间就再也没关系了。同样一旦Pod被创建完毕无论模板如何变化甚至换成一个新的模板也不会影响到已经创建的Pod了。此外Pod可以通过修改它的标签来脱离RC的管控。该方法可以用于将Pod从集群中迁移、数据修复等调试。对于被迁移的Pod副本RC会自动创建一个新的副本替换被迁移的副本。需要注意的是删除一个RC不会影响它所创建的Pod。如果想删除一个被RC所控制的Pod则需要将该RC的副本数Replicas属性设置为0这样所有的Pod副本就都会被自动删除。最好不要越过RC直接创建Pod因为ReplicationController会通过RC管理Pod副本实现自动创建、补足、替换、删除Pod副本这样能提高系统的容灾能力减少由于节点崩溃等意外状况造成的损失。即使你的应用程序只用到一个Pod副本我们也强烈建议你使用RC来定义Pod。总结一下Replication Controller的职责如下所述。1确保在当前集群中有且仅有N个Pod实例N是在RC中定义的Pod副本数量。2通过调整RC的spec.replicas属性值来实现系统扩容或者缩容。3通过改变RC中的Pod模板主要是镜像版本来实现系统的滚动升级。最后总结一下Replication Controller的典型使用场景如下所述。1重新调度Rescheduling​。如前面所述不管想运行1个副本还是1000个副本副本控制器都能确保指定数量的副本存在于集群中即使发生节点故障或Pod副本被终止运行等意外状况。2弹性伸缩Scaling​。手动或者通过自动扩容代理修改副本控制器的spec.replicas属性值非常容易实现增加或减少副本的数量。3滚动更新Rolling Updates​。副本控制器被设计成通过逐个替换Pod的方式来辅助服务的滚动更新。推荐的方式是创建一个只有一个副本的新RC若新RC副本数量加1则旧RC的副本数量减1直到这个旧RC的副本数量为0然后删除该旧RC。通过上述模式即使在滚动更新的过程中发生了不可预料的错误Pod集合的更新也都在可控范围内。在理想情况下滚动更新控制器需要将准备就绪的应用考虑在内并保证在集群中任何时刻都有足够数量的可用Pod。2.2、Node Controllerkubelet进程在启动时通过API Server注册自身的节点信息并定时向API Server汇报状态信息API Server在接收到这些信息后会将这些信息更新到etcd中。在etcd中存储的节点信息包括节点健康状况、节点资源、节点名称、节点地址信息、操作系统版本、Docker版本、kubelet版本等。节点健康状况包含“就绪”​True​“未就绪”​False和“未知”​Unknown三种。Node Controller通过API Server实时获取Node的相关信息实现管理和监控集群中的各个Node的相关控制功能Node Controller的核心工作流程如图所示。对流程中关键点的解释如下。1Controller Manager在启动时如果设置了–cluster-cidr参数那么为每个没有设置Spec.PodCIDR的Node都生成一个CIDR地址并用该CIDR地址设置节点的Spec.PodCIDR属性这样做的目的是防止不同节点的CIDR地址发生冲突。2逐个读取Node信息多次尝试修改nodeStatusMap中的节点状态信息将该节点信息和Node Controller的nodeStatusMap中保存的节点信息做比较。如果判断出没有收到kubelet发送的节点信息、第1次收到节点kubelet发送的节点信息或在该处理过程中节点状态变成非“健康”状态则在nodeStatusMap中保存该节点的状态信息并用Node Controller所在节点的系统时间作为探测时间和节点状态变化时间。如果判断出在指定时间内收到新的节点信息且节点状态发生变化则在nodeStatusMap中保存该节点的状态信息并用Node Controller所在节点的系统时间作为探测时间和节点状态变化时间。如果判断出在指定时间内收到新的节点信息但节点状态没发生变化则在nodeStatusMap中保存该节点的状态信息并用Node Controller所在节点的系统时间作为探测时间将上次节点信息中的节点状态变化时间作为该节点的状态变化时间。如果判断出在某段时间gracePeriod内没有收到节点状态信息则设置节点状态为“未知”​并且通过API Server保存节点状态。3逐个读取节点信息如果节点状态变为非“就绪”状态则将节点加入待删除队列否则将节点从该队列中删除。如果节点状态为非“就绪”状态且系统指定了Cloud Provider则Node Controller调用CloudProvider查看节点若发现节点故障则删除etcd中的节点信息并删除和该节点相关的Pod等资源的信息。2.3、ResourceQuota Controller作为完备的企业级的容器集群管理平台Kubernetes也提供了ResourceQuota Controller资源配额管理这一 高级功能资源配额管理确保了指定的资源对象在任何时候都不会超量占用系统物理资源避免了由于某些业务进程的设计或实现的缺陷导致整个系统运行紊乱甚至意外宕机对整个集群的平稳运行和稳定性有非常重要的作用。目前Kubernetes支持如下三个层次的资源配额管理。1容器级别可以对CPU和Memory进行限制。2Pod级别可以对一个Pod内所有容器的可用资源进行限制。3Namespace级别为Namespace多租户级别的资源限制包括Pod数量Replication Controller数量Service数量ResourceQuota数量Secret数量可持有的PV数量。Kubernetes的配额管理是通过Admission Control准入控制来控制的Admission Control当前提供了两种方式的配额约束分别是LimitRanger与ResourceQuota。其中LimitRanger作用于Pod和ContainerResourceQuota则作用于Namespace限定一个Namespace里的各类资源的使用总额。如图所示如果在Pod定义中同时声明了LimitRanger则用户通过API Server请求创建或修改资源时Admission Control会计算当前配额的使用情况如果不符合配额约束则创建对象失败。对于定义了ResourceQuota的NamespaceResourceQuotaController组件则负责定期统计和生成该Namespace下的各类对象的资源使用总量统计结果包括Pod、Service、RC、Secret和Persistent Volume等对象实例个数以及该Namespace下所有Container实例所使用的资源量目前包括CPU和内存​然后将这些统计结果写入etcd的resourceQuotaStatusStorage目录resourceQuotas/status下。写入resourceQuotaStatusStorage的内容包含Resource名称、配额值ResourceQuota对象中spec.hard域下包含的资源的值​、当前使用值ResourceQuota Controller统计出来的值​。随后这些统计信息被AdmissionControl使用以确保相关Namespace下的资源配额总量不会超过ResourceQuota中的限定值。2.4、Namespace Controller用户通过API Server可以创建新的Namespace并将其保存在etcd中Namespace Controller定时通过API Server读取这些Namespace的信息。如果Namespace被API标识为优雅删除通过设置删除期限实现即设置DeletionTimestamp属性​则将该NameSpace的状态设置成Terminating并保存到etcd中。同时NamespaceController删除该Namespace下的ServiceAccount、 RC、Pod、Secret、PersistentVolume、ListRange、ResourceQuota和Event等资源对象。在Namespace的状态被设置成Terminating后由Admission Controller的NamespaceLifecycle插件来阻止为该Namespace创建新的资源。同时在NamespaceController删除该Namespace中的所有资源对象后Namespace Controller对该Namespace执行finalize操作删除Namespace的spec.finalizers域中的信息。如果Namespace Controller观察到Namespace设置了删除期限同时Namespace的spec.finalizers域值是空的那么Namespace Controller将通过API Server删除该Namespace资源。2.5、Service Controller与Endpoints Controller本节讲解Endpoints Controller在这之前让我们先看看Service、Endpoints与Pod的关系。如图所示Endpoints表示一个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 Controller监听Service的变化如果该Service是一个LoadBalancer类型的ServiceexternalLoadBalancerstrue​则Service Controller确保在外部的云平台上该Service对应的LoadBalancer实例被相应地创建、删除及更新路由转发表根据Endpoints的条目​。