【本文專欄於[頭條號]、[知乎]同步發佈，可關注同名賬號訂閱相關文章，每週固定更新】
【本篇文章共計6129字，閱讀約需17分鐘，其中涉及概念較多，建議先收藏再看。】
在之前的《一篇文章帶你瞭解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過濾，找到自己想要監聽的事件則通過管道的方式將該數據發送到相應的組件。