3、controller-manager模块

在controller manager模块中有几个重要的结构体。当中包含EndpointController、ReplicationManager、GCController、NodeController、ServiceController、RouteController、ResourceQuotaController，以下会进行介绍。在controller manager模块还有几个处于试验阶段的功能和结构体，这里不会进行介绍。

3.1、EndpointController

EndpointController是个入口控制器结构体，表示一组包含服务的Pods副本。里面有POD入口控制器podController变量和Service入口控制器serviceController变量，里面还有POD存储变量podStore和Service存储变量serviceStore。EndpointController结构体中还有queue变量和client变量。

type EndpointController struct {

    client *client.Client

    serviceStore cache.StoreToServiceLister

    podStore     cache.StoreToPodLister

    queue *workqueue.Type

    serviceController *framework.Controller

    podController     *framework.Controller

}

POD存储变量podStore和Service存储变量serviceStore都使用到了Store接口，Store接口事实上就是一个通用的KEY/VALUE键值存储接口，这个接口用来实现对对象的操作，包含添加对象、更新对象、删除对象、列出全部KEY、列出全部对象、通过KEY查询对象等操作。KEY/VALUE键值存储接口的具体实现使用到了threadSafeMap结构体：

type threadSafeMap struct {

    lock  sync.RWMutex

    items map[string]interface{}

    indexers Indexers

    indices Indices

}

从中能够看出变量items事实上就是GO语言的map类型。通过map来实现KEY到VALUE的映射。

在threadSafeMap结构体中有个变量lock，这是一个读写相互排斥锁，通过这个锁来保证对map的操作是线程安全的，也就是多个线程同一时候操作map时不会产生不确定的结果。

POD存储变量podStore和Service存储变量serviceStore都是用来作为EndpointController端的缓存使用。

EndpointController结构体中queue变量是一个Type结构体：

type Type struct {

    queue []t

    dirty set

    processing set

    cond *sync.Cond

    shuttingDown bool

}

Type结构体就是一个工作队列，这个工作队列处理上有以下几个特点：

1. 提供先进先出的处理模式
2. 同样的内容放入这个工作队列多次后，这个工作队列仅仅能处理一次
3. 当一个内容被处理后。这个内容能够又一次被放入队列中
4. 队列关闭通知

EndpointController结构体中client变量是一个Client结构体：

type Client struct {

    *RESTClient

    *ExtensionsClient

    *DiscoveryClient

}

通过这个Client结构体来实现EndpointController结构体中serviceController和podController与kubernetes api-server的通讯。

POD入口控制器podController变量和Service入口控制器serviceController变量都使用到了Controller结构体:

type Controller struct {

    config         Config

    reflector      *cache.Reflector

    reflectorMutex sync.RWMutex

}

Controller结构体是一个通用的控制器结构体。这个结构体中有config、reflector和reflectorMutex三个变量。config变量是一个Config结构体，Config结构体的作用是负责控制器结构体全部的设置工作。Reflector变量是一个Reflector结构体。这个结构体是一个反射器结构体，负责监控指定的资源，而且通过反射机制对指定存储中的不论什么改变做出相应。ReflectorMutex这个变量同前面介绍过的threadSafeMap结构体中lock变量都使用到了RWMutex结构体，用来做读写相互排斥锁使用。

上面介绍了EndpointController这个结构体。以下介绍kuberneters controller manager怎样使用这个结构体的。

首先controller manager创建Endpoint控制器，而且依照EndpointController结构体对Endpoint控制器中的serviceStore、podStore、queue、serviceController和podController几个变量进行初始化。

然后将serviceController和podController作为GO程序进行启动。也就是通过关键字“go”来执行，Go语言对并发编程的支持是天生的、自然的和高效的。

Go语言为此专门创造出了一个关键字“go”。使用这个关键字，我们就能够非常easy的使一个函数被并发的执行。

启动后，serviceController和podController两个控制器開始各自工作。这两个控制器都使用client变量同api-server进行通讯。将从api-server获取到的service和pod信息存放到本地serviceStore和podStore两个变量中缓存。之后都是通过对本地缓存进行处理，这两个控制器定期对缓存进行更新。以降低同api-server之间的通讯。这两个控制器都将须要处理的内容放入变量queue的队列中，getPodServiceMemberships函数会依据pod信息找到相应的service信息，这样就保证了变量queue的队列中仅仅有service信息。

接着Endpoint控制器启动了几个worker程序，这些worker程序的作用在于处理queue队列中的service内容，在处理完之后标识service内容为已处理。Endpoint控制器默认启动5个worker来处理，当然能够启动很多其它的worker来加快queue队列中内容的处理速度，可是这种话也会添加很多其它的CPU负载和网络负载。

每个worker程序都从变量queue队列中取出一个service内容进行处理，最后同api-server进行通讯。对不存在的service创建endpoints，对已经存在的service更新endpoints。

3.2、ReplicationManager

以下介绍controller manager模块中ReplicationManager结构体，这是个副本控制器结构体，用来对kuberneters上已经执行的POD进行控制对象同步的，实际上这个副本控制器应该命名为ReplicationController，之所以没有这样命名，是为了同API对象“ReplicationController”进行区分。

type ReplicationManager struct {

    kubeClient client.Interface

    podControl controller.PodControlInterface

    burstReplicas int

    syncHandler func(rcKey string) error

    expectations controller.ControllerExpectationsInterface

    rcStore cache.StoreToReplicationControllerLister

    rcController *framework.Controller

    podStore cache.StoreToPodLister

    podController *framework.Controller

    podStoreSynced func() bool

    queue *workqueue.Type

}

ReplicationManager结构体中变量kubeClient是一个GO语言接口。用来同api-server通讯，变量podControl是一个GO语言接口，用来创建和删除POD。在ReplicationManager结构体中非常多变量类型在上面EndpointController结构体中都已经介绍过。这里不在反复介绍，这里直接介绍kuberneters controller manager怎样使用ReplicationManager这个结构体的。

首先controller manager创建ReplicationManager控制器，而且依照ReplicationManager结构体对ReplicationManager控制器中的几个变量进行初始化。

然后将rcController和podController作为GO程序进行启动，启动后，rcController和podController两个控制器開始各自工作。这两个控制器都使用client变量同api-server进行通讯，将从api-server获取到的replicationcontroller和pod信息存放到本地rcStore和podStore两个变量中缓存，之后都是通过对本地缓存进行处理。这两个控制器定期对缓存进行更新。以降低同api-server之间的通讯。

这两个控制器都将须要处理的内容放入变量queue的队列中。由worker进行处理。

ReplicationManager控制器启动了几个worker程序，这些worker程序的作用在于处理queue队列中的replicationcontroller内容，在处理完之后标识replicationcontroller内容为已处理。

ReplicationManager控制器默认启动5个worker来处理，每个worker程序都从变量queue队列中取出一个replicationcontroller内容进行处理，终于会比較replicationcontroller中配置的POD副本数和系统中POD实际执行个数。假设这两个数值同样，那么不进行处理，假设replicationcontroller中配置的POD副本数大于系统中POD实际执行个数，那么会创建POD，假设replicationcontroller中配置的POD副本数小于系统中POD实际执行个数。那么会删除POD，删除的过程中会依照系统中POD执行状态进行排序，先删除比較早期状态的POD。比方假设同一时候not-ready状态和ready状态，那么会先删除not-ready状态的POD，假设unscheduled状态和scheduled状态。那么会先删除unscheduled状态的POD。假设pending状态和running状态，那么会先删除pending状态的POD。

创建POD或者删除POD都是向api-server发送POST请求。请求的过程作为GO程序进行启动，也就是通过关键字“go”来执行。前面已经介绍过了GO程序。每次启动一个GO程序。相当于一次并发执行，能够看出来假设并发数太多，会影响api-server以及整个kubernetes自身性能。所以基于kubernetes性能需求上的考虑，对于POD的创建或者删除。每次一批最多处理500个操作，也就是说kubernetes控制住了replicationcontroller操作POD副本的并发数。

3.3、GCController

在controller manager模块中还有个结构体叫做GCController：

type GCController struct {

    kubeClient     client.Interface

    podStore       cache.StoreToPodLister

    podStoreSyncer *framework.Controller

    deletePod      func(namespace, name string) error

    threshold      int

}

这个结构体负责对POD进行回收处理，当终止状态的POD数量超过了kubernetes设定的上限值，那么通过GCController结构体对POD进行回收处理，回收过程通过删除POD来完毕，直到终止状态的POD数量在kubernetes设定的上限值以内，删除POD时，会先删除最早创建的POD,kubernetes设定的上限值默认是12500。

这个结构体的使用方式比較简单。通过对前面EndpointController结构体和ReplicationManager结构体的介绍，能够非常easy的了解kubernetes怎样使用GCController这个结构体的。这里就不具体进行介绍了。

到此为止。我们介绍了controll manager中三个结构体的使用。这三个结构体各自是EndpointController、ReplicationManager和GCController，controll manager都是通过GO程序来使用这三个结构体的，也就是通过关键字“go”来执行。

3.4、NodeController

以下介绍controller manager模块中NodeController结构体。这个结构体负责对Node进行监控。

type NodeController struct {

    allocateNodeCIDRs       bool

    cloud                   cloudprovider.Interface

    clusterCIDR             *net.IPNet

    deletingPodsRateLimiter util.RateLimiter

    knownNodeSet            sets.String

    kubeClient              client.Interface

    lookupIP func(host string) ([]net.IP, error)

    nodeStatusMap map[string]nodeStatusData

    now           func() unversioned.Time

    evictorLock *sync.Mutex

    podEvictor         *RateLimitedTimedQueue

    terminationEvictor *RateLimitedTimedQueue

    podEvictionTimeout time.Duration

    maximumGracePeriod time.Duration

    recorder           record.EventRecorder

    podController *framework.Controller

    podStore      cache.StoreToPodLister

    nodeController *framework.Controller

    nodeStore      cache.StoreToNodeLister

    forcefullyDeletePod func(*api.Pod)

}

这个结构体中变量knownNodeSet是一个字符串集合类型，在GO语言语法中是没有set类型的。所以kubernetes自己实现了一个set类型。

变量podEvictor是一个NODE删除队列。用来存放已经不存在的NODE信息。目的是为了删除这些NODE上的POD信息。

controller manager创建NodeController控制器，接着NodeController控制器将结构体中nodeController和podController作为GO程序进行启动，然后使用GO程序启动三个处理逻辑，第一个处理逻辑是监控NODE状态。第二个处理逻辑是删除指定NODE上面全部的POD，第三个处理逻辑是删除指定NODE上全部终止状态的POD。

我们着重看看这三个处理逻辑。先看监控NODE状态这个处理逻辑。这个处理逻辑首先从api-server查询出来全部NODE信息，在变量knownNodeSet中进行查找，变量knownNodeSet用来存放在Kubernetes上已经注冊的全部NODE名称。假设不在已经注冊的NODE集合中，那么说明是新注冊的NODE，插入到已经注冊的集合中。然后查找是否存在已经被删除的NODE信息，假设存在。那么从已经注冊的NODE集合中删除，而且将NODE名称放入NODE删除队列中。

假设kubernetes是在云提供商的资源上部署的，那么这里还能够用云提供商的资源自己主动给NODE分配IP和掩码。

再看删除指定NODE上面全部的POD的处理逻辑。

这个处理逻辑依据NODE删除队列中的NODE信息依次处理，将每个NODE上面全部的POD都删除掉，对于已经处于终止状态的POD不进行处理。

最后看删除指定NODE上全部终止状态的POD的处理逻辑。这个处理逻辑实际上是第二个删除逻辑的补充，它同第二个处理逻辑的差别在于，这个逻辑仅仅处理NODE上面处于终止状态的POD，而且这些POD在冷却期时间内一直处于终止状态。

3.5、ServiceController

以下介绍controller manager模块中ServiceController结构体。这个结构体负责对用到云提供商负载均衡资源的service进行同步操作。

type ServiceController struct {

    cloud            cloudprovider.Interface

    kubeClient       client.Interface

    clusterName      string

    balancer         cloudprovider.TCPLoadBalancer

    zone             cloudprovider.Zone

    cache            *serviceCache

    eventBroadcaster record.EventBroadcaster

    eventRecorder    record.EventRecorder

    nodeLister       cache.StoreToNodeLister

}

controller manager创建ServiceController控制器，然后监控用到云提供商负载均衡资源的service变化。用来确保这些外部负载均衡被正确的创建和删除。

Kubernetes能够对接多种云提供商，包含AWS、GCE、OpenStack、Mesos、rackspace，为了方便測试，kubernetes还提供了仿真云提供商。

3.6、RouteController

controller manager模块中另一个RouteController结构体，这个结构体负责对云提供商路由规则进行同步操作，并非全部的云提供商都支持这个功能。假设使用x86逻辑部署kubernetes，事实上根本都用不到云提供商，在这里就不具体分析这个结构体的使用了。

3.7、ResourceQuotaController

controller manager模块中另一个ResourceQuotaController结构体。这个结构体负责跟踪kubernetes中的配额使用状况。

type ResourceQuotaController struct {

    kubeClient client.Interface

    syncTime   <-chan time.Time

    syncHandler func(quota api.ResourceQuota) error

}

在kubernetes中同意对以下资源设置配额：POD数、Service数、ReplicationController数、ResourceQuota数、Secret数、persistent volume数、容器使用的总CPU大小、容器使用的总内存大小。

controller manager创建ResourceQuotaController后，就启动了一个GO程序。负责同步kuberneters中上述资源使用状况。

同步过程首先查询上述资源使用状况，当发现如今资源使用情况同上一次资源使用情况不一致的时候，通过与api-server通讯，更新资源使用状况。