建站
咨詢(xún)
售后
建站咨詢(xún)
新聞中心
一篇文章帶你了解Kubernetes各組件間的通信機(jī)制
作者：云端密碼 2019-11-04 11:06:36
云計(jì)算 我們對(duì)kubernetes有了一定的認(rèn)識(shí)，本文我們將繼續(xù)深入的對(duì)kubernetes在系統(tǒng)層面上進(jìn)行討論，一起看看kubernetes的各個(gè)基本組件，以及各個(gè)組件是如何相互配合來(lái)?yè)纹鹑绱藦?fù)雜的集群系統(tǒng)。
成都創(chuàng)新互聯(lián)專(zhuān)注為客戶(hù)提供全方位的互聯(lián)網(wǎng)綜合服務(wù)，包含不限于成都做網(wǎng)站、網(wǎng)站制作、成都外貿(mào)網(wǎng)站建設(shè)、拱墅網(wǎng)絡(luò)推廣、小程序開(kāi)發(fā)、拱墅網(wǎng)絡(luò)營(yíng)銷(xiāo)、拱墅企業(yè)策劃、拱墅品牌公關(guān)、搜索引擎seo、人物專(zhuān)訪(fǎng)、企業(yè)宣傳片、企業(yè)代運(yùn)營(yíng)等，從售前售中售后，我們都將竭誠(chéng)為您服務(wù)，您的肯定，是我們最大的嘉獎(jiǎng)；成都創(chuàng)新互聯(lián)為所有大學(xué)生創(chuàng)業(yè)者提供拱墅建站搭建服務(wù)，24小時(shí)服務(wù)熱線(xiàn)：18980820575，官方網(wǎng)址：www.cdcxhl.com
我們對(duì)kubernetes有了一定的認(rèn)識(shí)，本文我們將繼續(xù)深入的對(duì)kubernetes在系統(tǒng)層面上進(jìn)行討論，一起看看kubernetes的各個(gè)基本組件，以及各個(gè)組件是如何相互配合來(lái)?yè)纹鹑绱藦?fù)雜的集群系統(tǒng)。下面跟隨文章內(nèi)容，一起來(lái)領(lǐng)略kubernetes令人驚嘆的設(shè)計(jì)內(nèi)幕吧。
Kubernetes的基本組件
Kubernetes將整個(gè)集群分為控制節(jié)點(diǎn)和工作節(jié)點(diǎn)，如下圖所示。
Kubernetes中的Master是指集群控制節(jié)點(diǎn)，每個(gè)Kubernetes集群中需要一個(gè)Master節(jié)點(diǎn)來(lái)負(fù)責(zé)整個(gè)集群的管理和控制，Kubernetes中所有的控制指令都是交由Master來(lái)進(jìn)行處理。引起在集群中處于非常重要的地位，因此在部署中需進(jìn)行多節(jié)點(diǎn)單獨(dú)部署。
Maste節(jié)點(diǎn)關(guān)鍵進(jìn)程
Apiserver：提供kubernetes所有資源增刪改查的唯一入口，也是集群控制的入口，提供http Rest接口，完成集群管理，資源配額，訪(fǎng)問(wèn)控制，認(rèn)證授權(quán)，以及對(duì)etcd的操作。
Controller-manager：是集群內(nèi)所有資源對(duì)象的自動(dòng)化控制中心，負(fù)責(zé)pod和node的管理，節(jié)點(diǎn)控制器，服務(wù)控制器，副本控制器，服務(wù)賬戶(hù)和令牌控制器等
Scheduler：負(fù)責(zé)資源調(diào)度，監(jiān)聽(tīng)Apiserver，查詢(xún)是否有未調(diào)度的pod。
Etcd：在kubernetes系統(tǒng)中，主要有兩個(gè)服務(wù)需要用到etcd來(lái)存儲(chǔ)：
網(wǎng)絡(luò)插件：如flannel等需要存儲(chǔ)網(wǎng)絡(luò)配置信息
Kubernetes本身，包括各種對(duì)象的狀態(tài)和原信息配置。
除Master節(jié)點(diǎn)外，集群中其他集群被稱(chēng)為Node節(jié)點(diǎn)，較早的版本中也叫Minion。Node節(jié)點(diǎn)是集群中具體的工作負(fù)載節(jié)點(diǎn)，其可以使物理機(jī)也可以為虛擬機(jī)。
Node節(jié)點(diǎn)關(guān)鍵進(jìn)程(包括但不限于以下進(jìn)程)
kubelet：處理Master下發(fā)到本節(jié)點(diǎn)的任務(wù)，管理pod及pod的容器，每個(gè)kubelet在Apiserver上注冊(cè)自身信息，定期向Master匯報(bào)節(jié)點(diǎn)的資源使用情況，并通過(guò)cAdvisor監(jiān)控容器和節(jié)點(diǎn)信息。
kube-proxy：將到service的訪(fǎng)問(wèn)轉(zhuǎn)發(fā)到后端的多個(gè)pod實(shí)例上，維護(hù)路由信息，對(duì)于每一個(gè)TCP類(lèi)型的k8s service，kube-proxy會(huì)在本地建立一個(gè)sockerserver來(lái)負(fù)責(zé)均衡算法，使用rr負(fù)載均衡算法。
CNI網(wǎng)絡(luò)組件：作為容器平臺(tái)的網(wǎng)絡(luò)標(biāo)準(zhǔn)化組件，為容器提供跨網(wǎng)段的通信支持，是kubernetes集群overlay網(wǎng)絡(luò)的實(shí)現(xiàn)關(guān)鍵。
Docker：kubernetes支持多種容器工具，目前Docker作為主流的容器，為kubernetes集群提供容器創(chuàng)建及管理。
集群各組件間的交互
Kubernetes為所有資源增刪改查的唯一入口，各組件均以list-watch的方式向Apiserve發(fā)送請(qǐng)求。為減少Apiserver的壓力，各組件都采用緩存來(lái)緩存數(shù)據(jù)。功能模塊在某些情況下不直接訪(fǎng)問(wèn)Apiserver，而是通過(guò)訪(fǎng)問(wèn)緩存來(lái)間接訪(fǎng)問(wèn)Apiserver。
Kubelet&Apiserver
每個(gè)node上的kubelet每個(gè)一個(gè)時(shí)間周期，就會(huì)調(diào)用Apiserver的REST接口來(lái)報(bào)告自身狀態(tài)。Kubelet通過(guò)watch接口，監(jiān)聽(tīng)pod信息。監(jiān)聽(tīng)創(chuàng)建、刪除、修改事件。
Controller-manager&Apiserver
controller-manager中包含多個(gè)controller，舉例：Node Controller模塊通過(guò)API server提供的Watch接口，實(shí)現(xiàn)監(jiān)控Node信息，并做相應(yīng)處理。
Scheduler&Apiserver
Scheduler通過(guò)API server的watch接口來(lái)監(jiān)聽(tīng)，監(jiān)聽(tīng)到新建pod副本后，檢索所有符合該P(yáng)od要求的Node列表，開(kāi)始執(zhí)行Pod調(diào)度，調(diào)度成功后將pod綁定到具體節(jié)點(diǎn)。
以下是一張典型pod創(chuàng)建的流程圖，其中可以看到Apiserver處于核心的位置，集群內(nèi)的各個(gè)功能模塊的所有原數(shù)據(jù)正刪改查都是通過(guò)kube-apiserver操作etcd，當(dāng)需要獲取和操作這些數(shù)據(jù)時(shí)，通過(guò)Apiserver的REST接口來(lái)實(shí)現(xiàn)。
[[281211]]
list-watch機(jī)制
kubernetes沒(méi)有像其他分布式系統(tǒng)中額外引入MQ，是因?yàn)槠湓O(shè)計(jì)理念采用了level trigger而非edge trigger。其僅僅通過(guò)http+protobuffer的方式，實(shí)現(xiàn)list-watcher機(jī)制來(lái)解決各組件間的消息通知。因此，在了解各組件通信前，必須先了解list-watch機(jī)制在kubernetes的應(yīng)用。
List-watch是k8s統(tǒng)一的異步消息處理機(jī)制，list通過(guò)調(diào)用資源的list API羅列資源，基于HTTP短鏈接實(shí)現(xiàn);watch則是調(diào)用資源的watch API監(jiān)聽(tīng)資源變更事件，基于HTTP長(zhǎng)鏈接實(shí)現(xiàn)。在kubernetes中，各組件通過(guò)監(jiān)聽(tīng)Apiserver的資源變化，來(lái)更新資源狀態(tài)。
這里對(duì)watch簡(jiǎn)要說(shuō)明，流程如下圖所示：
這一部分流程圖看起來(lái)并不復(fù)雜，實(shí)際上里面的實(shí)現(xiàn)相當(dāng)精妙。結(jié)合這幅圖進(jìn)行簡(jiǎn)要的解釋?zhuān)?/p>
1 首先需要強(qiáng)調(diào)一點(diǎn)，list或者watch的數(shù)據(jù)，均是來(lái)自于etcd的數(shù)據(jù)，因此在Apiserver中，一切的設(shè)計(jì)都是為了獲取最新的etcd數(shù)據(jù)并返回給client。
2 當(dāng)Apiserver監(jiān)聽(tīng)到各組件發(fā)來(lái)的watch請(qǐng)求時(shí)，由于list和watch請(qǐng)求的格式相似，先進(jìn)入ListResource函數(shù)進(jìn)行分析，若解析為watch請(qǐng)求，便會(huì)創(chuàng)建一個(gè)watcher結(jié)構(gòu)來(lái)響應(yīng)請(qǐng)求。watcher的生命周期是每個(gè)http請(qǐng)求的。
- //每一個(gè)Watch請(qǐng)求對(duì)應(yīng)一個(gè)watcher結(jié)構(gòu)
- func (a *APIInstaller) registerResourceHandlers(path string, storage rest.Storage,... ...
- ……
- lister, isLister := storage.(rest.Lister)
- watcher, isWatcher := storage.(rest.Watcher) ...(1) ... case "LIST": // List all resources of a kind.
- ……
3 創(chuàng)建了watcher，但誰(shuí)來(lái)接收并緩存etcd的數(shù)據(jù)呢?Apiserver使用cacher來(lái)接收etcd的事件，cacher也是Storage類(lèi)型，這里cacher可以理解為是監(jiān)聽(tīng)etcd的一個(gè)實(shí)例，cacher針對(duì)于某個(gè)類(lèi)型的數(shù)據(jù)，其cacher通過(guò)ListAndWatch()這個(gè)方法，向etcd發(fā)送watch請(qǐng)求。etcd會(huì)將某一類(lèi)型的數(shù)據(jù)同步到watchCache這個(gè)結(jié)構(gòu)，也就是說(shuō)，ListAndWatch()將遠(yuǎn)端數(shù)據(jù)源源不斷同步到cacher結(jié)構(gòu)中來(lái)。Cacher的結(jié)構(gòu)如下所示：
- type Cacher struct {
- incomingHWM storage.HighWaterMark
- incoming chan watchCacheEvent
- sync.RWMutex
- // Before accessing the cacher's cache, wait for the ready to be ok.
- // This is necessary to prevent users from accessing structures that are
- // uninitialized or are being repopulated right now.
- // ready needs to be set to false when the cacher is paused or stopped.
- // ready needs to be set to true when the cacher is ready to use after
- // initialization.
- ready *ready
- // Underlying storage.Interface.
- storage storage.Interface
- // Expected type of objects in the underlying cache.
- objectType reflect.Type
- // "sliding window" of recent changes of objects and the current state.
- watchCache *watchCache
- reflector *cache.Reflector
- // Versioner is used to handle resource versions.
- versioner storage.Versioner
- // newFunc is a function that creates new empty object storing a object of type Type.
- newFunc func() runtime.Object
- // indexedTrigger is used for optimizing amount of watchers that needs to process
- // an incoming event.
- indexedTrigger *indexedTriggerFunc
- // watchers is mapping from the value of trigger function that a
- // watcher is interested into the watchers
- watcherIdx int
- watchers indexedWatchers
- // Defines a time budget that can be spend on waiting for not-ready watchers
- // while dispatching event before shutting them down.
- dispatchTimeoutBudget *timeBudget
- // Handling graceful termination.
- stopLock sync.RWMutex
- stopped bool
- stopCh chan struct{}
- stopWg sync.WaitGroup
- clock clock.Clock
- // timer is used to avoid unnecessary allocations in underlying watchers.
- timer *time.Timer
- // dispatching determines whether there is currently dispatching of
- // any event in flight.
- dispatching bool
- // watchersBuffer is a list of watchers potentially interested in currently
- // dispatched event.
- watchersBuffer []*cacheWatcher
- // blockedWatchers is a list of watchers whose buffer is currently full.
- blockedWatchers []*cacheWatcher
- // watchersToStop is a list of watchers that were supposed to be stopped
- // during current dispatching, but stopping was deferred to the end of
- // dispatching that event to avoid race with closing channels in watchers.
- watchersToStop []*cacheWatcher
- // Maintain a timeout queue to send the bookmark event before the watcher times out.
- bookmarkWatchers *watcherBookmarkTimeBuckets
- // watchBookmark feature-gate
- watchBookmarkEnabled bool
- }
watchCache的結(jié)構(gòu)如下所示：
- type watchCache struct {
- sync.RWMutex //同步鎖
- cond *sync.Cond //條件變量
- capacity int//歷史滑動(dòng)窗口容量
- keyFunc func(runtime.Object) (string, error)//從storage中獲取鍵值
- getAttrsFunc func(runtime.Object) (labels.Set, fields.Set, bool, error)//獲取一個(gè)對(duì)象的field和label信息
- cache []watchCacheElement//循環(huán)隊(duì)列緩存
- startIndex int//循環(huán)隊(duì)列的起始下標(biāo)
- endIndex int//循環(huán)隊(duì)列的結(jié)束下標(biāo)
- store cache.Store//
- resourceVersion uint64
- onReplace func()
- onEvent func(*watchCacheEvent)//在每次緩存中的數(shù)據(jù)發(fā)生Add/Update/Delete后都會(huì)調(diào)用該函數(shù)，來(lái)獲取對(duì)象的之前版本的值
- clock clock.Clock
- versioner storage.Versioner
- }
cache里面存放的是所有操作事件，而store中存放的是當(dāng)前最新的事件。
4 cacheWatcher從watchCache中拿到從某個(gè)resourceVersion以來(lái)的所有數(shù)據(jù)，即initEvents，然后將數(shù)據(jù)放到input這個(gè)channel里面去，通過(guò)filter然后輸出到result這個(gè)channel里面，返回?cái)?shù)據(jù)到某個(gè)client。
- type cacheWatcher struct {
- sync.Mutex//同步鎖
- input chan *watchCacheEvent//輸入管道,Apiserver都事件發(fā)生時(shí)都會(huì)通過(guò)廣播的形式向input管道進(jìn)行發(fā)送
- result chan watch.Event//輸出管道，輸出到update管道中去
- done chan struct{}
- filter filterWithAttrsFunc//過(guò)濾器
- stopped bool
- forget func(bool)
- versioner storage.Versioner
- }
從一個(gè)pod創(chuàng)建過(guò)程看k8s組件通信
我們?cè)倩氐缴厦娴腜od創(chuàng)建流程圖。從圖中我們可以看出以下信息：
1 首先各組件也會(huì)在初始化時(shí)向Apiserver發(fā)送watch請(qǐng)求，即在圖中標(biāo)0的指令。Apiserver在創(chuàng)建kubeApiserver并注冊(cè)各API路由信息時(shí)，獲取Watch請(qǐng)求的路由信息
2 從Kubectl向Apiserver發(fā)送創(chuàng)建pod請(qǐng)求起，每一步創(chuàng)建、更新操作，都會(huì)存儲(chǔ)到etcd中。
3 各組件向Apiserver發(fā)送watch請(qǐng)求，Apiserver從etcd獲取最新數(shù)據(jù)并返回。
注意：當(dāng)事件發(fā)生時(shí)，Apiserver會(huì)給這些watcher中的通道推送，每個(gè)watcher都有自己的Filter過(guò)濾，找到自己想要監(jiān)聽(tīng)的事件則通過(guò)管道的方式將該數(shù)據(jù)發(fā)送到相應(yīng)的組件。
網(wǎng)頁(yè)題目：一篇文章帶你了解kubernetes各組件間的通信機(jī)制
分享URL：http://m.5511xx.com/article/ccshije.html
