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结构体就是一个工作队列，这个工作队列处理上有以下几个特点：
- 提供先进先出的处理模式
- 同样的内容放入这个工作队列多次后，这个工作队列仅仅能处理一次
- 当一个内容被处理后。这个内容能够又一次被放入队列中
- 队列关闭通知
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通讯，更新资源使用状况。