Kubernetes 內部元件工作原理

翻譯自:https://blog.heptio.com/core-kubernetes-jazz-improv-over-orchestration-a7903ea92ca

原作者：Joe Beda (Dad of two. CTO of Heptio. Started Google Compute Engine, Kubernetes and Google Container Engine.)

      本篇文章講述了Kubernetes內部元件的工作原理，及建立POD的流程。如果你是運維人員或者是Kubernetes的使用者，你可以不需要知道Kubernetes的內部工作原理，但是如果你想理解Kubernetes內部的工作原理，這篇文章非常適合你。

     讀這篇文章的前提是，你已經大致瞭解並會運用Kubernetes。這篇文章不會去描述什麼是Kubernetes及其元件（如：Pod, Node, Kubelet）。
     本篇將討論Kubernetes核心元件及這些核心元件是如何讓Kubernetes 對"爵士樂即興演奏"。通常將像Kubernetes這樣的通用系統稱為容器的 "管絃樂編排"。但是管絃樂編排，必須有一個預先計劃的指揮家。因此，這並不是Kubernetes的一個好的描述。相反，Kubernetes更像是爵士樂即興演奏，有一系列演員互相配合協調完成演奏。

     接下來，開始介紹每個核心元件的功能。然後將看一個典型的排程和啟動一個Pod的流程。

1. Datastore: Etcd

Etcd是Kubernetes的儲存狀態的資料庫。雖然Kubernetes系統中有重要的記憶體快取，但Etcd被認為是記錄系統狀態。

Etcd的快速總結：它是一個叢集分散式資料庫，它可以提供分散式資料的一致性。這類的系統（如Zookeeper, Consul）是在    Google開發的chubby系統之後形成的，這些系統也稱為"鎖伺服器"，因為他們可以實現分散式鎖。Etcd和chubby的資料模型是一個簡單的層次化的Key，並儲存了簡單的非結構化value，這看起來像是一個檔案系統。有意思的是，在Google, chubby 被頻繁用於為實現訪問本地檔案和物件儲存的功能的抽象檔案介面。然而，分散式資料庫的高度一致性，提供了資料的嚴格寫入順序並允許client原子性的對資料做更新操作。

可靠的系統的狀態管理是任何系統中非常困難的一件事情。在分散式系統中，它是更加困難的，因為它引入了一致性演算法，如raft或paxos。通過使用etcd，Kubernetes可以專注系統的其他部分。

Etcd的watch機制是Kubernetes工作的關鍵。系統允許client去執行輕量級的對於Key值變化事件的訂閱。當要watch的資料發生變化時, client會立即得到通知。這可以用作分散式系統元件之間的協調機制。 一個元件一旦寫入etcd，其他元件可以立即對該變化作出反應。

Etcd的訊息機制正好和PubSub訊息佇列機制相反。在許多訊息佇列系統系統中，topic不儲存真正的使用者資料，但釋出到這些topic的訊息含有豐富的資料。對於像Etcd這樣的系統，Key（類似於主題）儲存了真實的資料而訊息（資料變化通知）不含獨特的豐富訊息。換句話說，對於訊息佇列來說，topic很簡單，而像Etcd則正好相反。（譯者認為此處概括的非常準確）

2. Policy Layer: API Server

Kubernetes的核心元件是API Server，它是Kubernetes系統和Etcd直接對話的唯一元件。實際上，etcd是API server的實現細節，理論上也可以用其他分散式儲存系統來支援Kubernetes.

API server是一個策略元件，提供對Etcd的過濾訪問。它的作用本質上是相對通用的，目前正在被分解處理。因此，API Server也可以用於其他系統的控制平面。

API server的主要貨物是資源，通過暴露簡單的REST API 向外提供服務。這些資源有一個標準結構可以實現一些擴充套件功能。無論如何，API Server，允許各類元件建立，讀取，寫入，更新，和監視資源。

API  Server的具體的功能：

• 認證和授權。Kubernetes有一個可插拔的認證系統。有一些內建的使用者認證機制和授權這些使用者訪問資源。此外，還有一些方法可用於向外部服務提供這些服務。這種可擴充套件性是Kubernetes構建的核心功能。
• API Server執行一組可以拒絕或修改請求的准入控制器。 這些允許策略被應用並設定預設值。 這是確保在API Server客戶端仍在等待請求確認時進入系統的資料有效性的關鍵。 雖然這些准入控制器目前正在編譯到API Server中，但目前正在進行的工作是使其成為另一種可擴充套件性機制。
• API Server 有助於API 版本控制。API 版本的一個關鍵問題是允許資源的欄位的改變，欄位新增，棄用，重新組織和以其他方式轉換。 API Server在Etcd中儲存資源的"true"表示，並根據滿足的API版本轉換/呈現該資源。 自專案早期開始，規劃版本控制和API的發展一直是Kubernetes的一項重要工作。
• API Server 一個重要特性是支援watch機制。這意味著API Server的客戶端可以使用與Etcd相同的協調模式。Kubernetes中的大多數協調包括寫入另一個元件正在監視的API伺服器資源的元件。 第二個元件將對幾乎立即發生的變化做出反應。

3. 業務邏輯：Controller Manager and Scheduler

這些是通過API Server 進行協調的元件。這些稱為Controller Manager和Scheduler的元件繫結到單獨的伺服器Master上
Scheduler元件將做許多事情讓系統工作：

1. 查詢未分配給節點的Pod(未繫結的Pod)；
2. 檢查叢集的狀態（快取在記憶體中）；
3. 選擇具有空閒空間並滿足其他約束條件的節點; 
4. 將pod繫結到該節點。

Controller Manager 元件，實現ReplicaSet的行為。（ReplicaSet可以確保任何時候都可以執行一個Pod模板的副本數量）。控制器將根據資源中的選擇器 監控ReplicaSet 資源和一組Pod。為了保持在ReplicaSet中穩定的一組Pod，控制器將建立、銷燬Pod。

4.Node Agent: Kubelet

每一個Node上都有一個Agent。這也像其他元件一樣對API Server進行身份驗證。Agent負責監視繫結到其節點的一組Pod，並確保這些Pod正常執行，並且能實時返回這些Pod的執行狀態。

5.典型的流程

為幫助理解，建立Pod的整個流程，時序圖如下：

 
這個時序圖展示了建立pod的流程，基本的流程如下：
1. 使用者提交建立Pod的請求，可以通過API Server的REST API ，也可用Kubectl命令列工具，支援Json和Yaml兩種格式；
2. API Server 處理使用者請求，儲存Pod資料到Etcd；
3. Schedule通過和 API Server的watch機制，檢視到新的pod，嘗試為Pod繫結Node；
4. 過濾主機：排程器用一組規則過濾掉不符合要求的主機，比如Pod指定了所需要的資源，那麼就要過濾掉資源不夠的主機；
5. 主機打分：對第一步篩選出的符合要求的主機進行打分，在主機打分階段，排程器會考慮一些整體優化策略，比如把一個Replication Controller的副本分佈到不同的主機上，使用最低負載的主機等；
6. 選擇主機：選擇打分最高的主機，進行binding操作，結果儲存到Etcd中；

7. kubelet根據排程結果執行Pod建立操作： 繫結成功後，會啟動container, docker run, scheduler會呼叫API Server的API在etcd中建立一個bound pod物件，描述在一個工作節點上繫結執行的所有pod資訊。執行在每個工作節點上的kubelet也會定期與etcd同步bound pod資訊，一旦發現應該在該工作節點上執行的bound pod物件沒有更新，則呼叫Docker API建立並啟動pod內的容器。

總結

通過使用API Server作為中心協調點，Kubernetes能夠以鬆耦合的方式，實現元件相互互動。 希望讀完此文，你可以對Kubernetes建立Pod的原理有更深入的認識。

此外：k8s 也提供qos 服務，ref: http://oj6ydypm2.bkt.clouddn.com/Kubernetes%E4%B8%AD%E7%9A%84%E8%B5%84%E6%BA%90%E7%AE%A1%E7%90%86_%E4%B8%81%E6%B5%B7%E6%B4%8B.pdf