码迷,mamicode.com
首页 > Web开发 > 详细

Kubernetes1.1源代码分析(二)

时间:2016-03-27 12:46:45      阅读:238      评论:0      收藏:0      [点我收藏+]

标签:

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”。使用这个关键字,我们就可以很容易的使一个函数被并发的执行。
启动后,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结构体的介绍,可以很容易的了解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通讯,更新资源使用状况。

Kubernetes1.1源代码分析(二)

标签:

原文地址:http://blog.csdn.net/horsefoot/article/details/50990556

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!