一篇文章帶你了解kubernetes各組件間的通信機制
我們對kubernetes有了一定的認識，本文我們將繼續深入的對kubernetes在系統層面上進行討論，一起看看kubernetes的各個基本組件，以及各個組件是如何相互配合來撐起如此復雜的集群系統。下面跟隨文章內容，一起來領略kubernetes令人驚嘆的設計內幕吧。
Kubernetes的基本組件
Kubernetes將整個集群分為控制節點和工作節點，如下圖所示。
Kubernetes中的Master是指集群控制節點，每個Kubernetes集群中需要一個Master節點來負責整個集群的管理和控制，Kubernetes中所有的控制指令都是交由Master來進行處理。引起在集群中處于非常重要的地位，因此在部署中需進行多節點單獨部署。
Maste節點關鍵進程
Apiserver：提供kubernetes所有資源增刪改查的唯一入口，也是集群控制的入口，提供http Rest接口，完成集群管理，資源配額，訪問控制，認證授權，以及對etcd的操作。
Controller-manager：是集群內所有資源對象的自動化控制中心，負責pod和node的管理，節點控制器，服務控制器，副本控制器，服務賬戶和令牌控制器等
Scheduler：負責資源調度，監聽Apiserver，查詢是否有未調度的pod。
Etcd：在kubernetes系統中，主要有兩個服務需要用到etcd來存儲：
網絡插件：如flannel等需要存儲網絡配置信息
Kubernetes本身，包括各種對象的狀態和原信息配置。
除Master節點外，集群中其他集群被稱為Node節點，較早的版本中也叫Minion。Node節點是集群中具體的工作負載節點，其可以使物理機也可以為虛擬機。
Node節點關鍵進程(包括但不限于以下進程)
kubelet：處理Master下發到本節點的任務，管理pod及pod的容器，每個kubelet在Apiserver上注冊自身信息，定期向Master匯報節點的資源使用情況，并通過cAdvisor監控容器和節點信息。
kube-proxy：將到service的訪問轉發到后端的多個pod實例上，維護路由信息，對于每一個TCP類型的k8s service，kube-proxy會在本地建立一個sockerserver來負責均衡算法，使用rr負載均衡算法。
CNI網絡組件：作為容器平臺的網絡標準化組件，為容器提供跨網段的通信支持，是kubernetes集群overlay網絡的實現關鍵。
Docker：kubernetes支持多種容器工具，目前Docker作為主流的容器，為kubernetes集群提供容器創建及管理。
集群各組件間的交互
Kubernetes為所有資源增刪改查的唯一入口，各組件均以list-watch的方式向Apiserve發送請求。為減少Apiserver的壓力，各組件都采用緩存來緩存數據。功能模塊在某些情況下不直接訪問Apiserver，而是通過訪問緩存來間接訪問Apiserver。
Kubelet&Apiserver
每個node上的kubelet每個一個時間周期，就會調用Apiserver的REST接口來報告自身狀態。Kubelet通過watch接口，監聽pod信息。監聽創建、刪除、修改事件。
Controller-manager&Apiserver
controller-manager中包含多個controller，舉例：Node Controller模塊通過API server提供的Watch接口，實現監控Node信息，并做相應處理。
Scheduler&Apiserver
Scheduler通過API server的watch接口來監聽，監聽到新建pod副本后，檢索所有符合該Pod要求的Node列表，開始執行Pod調度，調度成功后將pod綁定到具體節點。
以下是一張典型pod創建的流程圖，其中可以看到Apiserver處于核心的位置，集群內的各個功能模塊的所有原數據正刪改查都是通過kube-apiserver操作etcd，當需要獲取和操作這些數據時，通過Apiserver的REST接口來實現。
list-watch機制
kubernetes沒有像其他分布式系統中額外引入MQ，是因為其設計理念采用了level trigger而非edge trigger。其僅僅通過http+protobuffer的方式，實現list-watcher機制來解決各組件間的消息通知。因此，在了解各組件通信前，必須先了解list-watch機制在kubernetes的應用。
List-watch是k8s統一的異步消息處理機制，list通過調用資源的list API羅列資源，基于HTTP短鏈接實現;watch則是調用資源的watch API監聽資源變更事件，基于HTTP長鏈接實現。在kubernetes中，各組件通過監聽Apiserver的資源變化，來更新資源狀態。
這里對watch簡要說明，流程如下圖所示：
這一部分流程圖看起來并不復雜，實際上里面的實現相當精妙。結合這幅圖進行簡要的解釋：
1 首先需要強調一點，list或者watch的數據，均是來自于etcd的數據，因此在Apiserver中，一切的設計都是為了獲取最新的etcd數據并返回給client。
2 當Apiserver監聽到各組件發來的watch請求時，由于list和watch請求的格式相似，先進入ListResource函數進行分析，若解析為watch請求，便會創建一個watcher結構來響應請求。watcher的生命周期是每個http請求的。
- //每一個Watch請求對應一個watcher結構
- 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 創建了watcher，但誰來接收并緩存etcd的數據呢?Apiserver使用cacher來接收etcd的事件，cacher也是Storage類型，這里cacher可以理解為是監聽etcd的一個實例，cacher針對于某個類型的數據，其cacher通過ListAndWatch()這個方法，向etcd發送watch請求。etcd會將某一類型的數據同步到watchCache這個結構，也就是說，ListAndWatch()將遠端數據源源不斷同步到cacher結構中來。Cacher的結構如下所示：
- 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的結構如下所示：
- type watchCache struct {
- sync.RWMutex //同步鎖
- cond *sync.Cond //條件變量
- capacity int//歷史滑動窗口容量
- keyFunc func(runtime.Object) (string, error)//從storage中獲取鍵值
- getAttrsFunc func(runtime.Object) (labels.Set, fields.Set, bool, error)//獲取一個對象的field和label信息
- cache []watchCacheElement//循環隊列緩存
- startIndex int//循環隊列的起始下標
- endIndex int//循環隊列的結束下標
- store cache.Store//
- resourceVersion uint64
- onReplace func()
- onEvent func(*watchCacheEvent)//在每次緩存中的數據發生Add/Update/Delete后都會調用該函數，來獲取對象的之前版本的值
- clock clock.Clock
- versioner storage.Versioner
- }
cache里面存放的是所有操作事件，而store中存放的是當前最新的事件。
4 cacheWatcher從watchCache中拿到從某個resourceVersion以來的所有數據，即initEvents，然后將數據放到input這個channel里面去，通過filter然后輸出到result這個channel里面，返回數據到某個client。
- type cacheWatcher struct {
- sync.Mutex//同步鎖
- input chan *watchCacheEvent//輸入管道,Apiserver都事件發生時都會通過廣播的形式向input管道進行發送
- result chan watch.Event//輸出管道，輸出到update管道中去
- done chan struct{}
- filter filterWithAttrsFunc//過濾器
- stopped bool
- forget func(bool)
- versioner storage.Versioner
- }
從一個pod創建過程看k8s組件通信
我們再回到上面的Pod創建流程圖。從圖中我們可以看出以下信息：
1 首先各組件也會在初始化時向Apiserver發送watch請求，即在圖中標0的指令。Apiserver在創建kubeApiserver并注冊各API路由信息時，獲取Watch請求的路由信息
2 從Kubectl向Apiserver發送創建pod請求起，每一步創建、更新操作，都會存儲到etcd中。
3 各組件向Apiserver發送watch請求，Apiserver從etcd獲取最新數據并返回。
注意：當事件發生時，Apiserver會給這些watcher中的通道推送，每個watcher都有自己的Filter過濾，找到自己想要監聽的事件則通過管道的方式將該數據發送到相應的組件。
