Kubernetes1.1源码分析(二)

穿精又带淫゛_ 提交于 2020-04-08 13:35:26

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通讯,更新资源使用状况。

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!