Kubernetes設計理念學習筆記
前言
前一段時間花費了不少時間，系統的學習了一下kubernetes的相關設計的資料，在這整理分享一下，希望能夠幫助有需要的人。
PS文章大量資料參考自網路。重要的參考資源就是JimmySong的HandBook。
Kubernetes是什麼
Kubernetes最初源於谷歌內部的Borg，提供了面向應用的容器叢集部署和管理系統。Kubernetes的目標旨在消除編排物理/虛擬計算，網路和儲存基礎設施的負擔，並使應用程式運營商和開發人員完全將重點放在以容器為中心的原語上進行自助運營。Kubernetes 也提供穩定、相容的基礎（平臺），用於構建定製化的workflows 和更高階的自動化任務。 Kubernetes 具備完善的叢集管理能力，包括多層次的安全防護和准入機制、多租戶應用支撐能力、透明的服務註冊和服務發現機制、內建負載均衡器、故障發現和自我修復能力、服務滾動升級和線上擴容、可擴充套件的資源自動排程機制、多粒度的資源配額管理能力。 Kubernetes 還提供完善的管理工具，涵蓋開發、部署測試、運維監控等各個環節。
作用就像下面這附圖所示，Kubernetes是雲原生軟體系統的作業系統。
架構設計
Kubernetes主要由以下幾個核心元件組成：
- etcd，儲存了整個叢集的狀態； apiserver提供了資源操作的唯一入口，並提供認證、授權、訪問控制、API註冊和發現等機制；
- controller manager，負責維護叢集的狀態，比如故障檢測、自動擴充套件、滾動更新等；
- scheduler，負責資源的排程，按照預定的排程策略將Pod排程到相應的機器上；
- kubelet，負責維護容器的生命週期，同時也負責Volume（CSI）和網路（CNI）的管理；
- Container runtime，負責映象管理以及Pod和容器的真正執行（CRI）；
- kube-proxy，負責為Service提供cluster內部的服務發現和負載均衡；
所以我們在手動部署的時候也是需要在master上部署etcd,kube-apiserver,kube-controller-manager,kube-scheduler,在node上部署kublet，kube-proxy
Kubernetes可以分為五個層次，由上到下分別為：生態系統，介面層，管理層，應用層，核心層。
生態系統：在介面層之上的龐大容器叢集管理排程的生態系統
介面層：kubectl命令列工具、客戶端SDK以及叢集聯邦，說到介面層就的說到其API設計原則
管理層：系統度量（如基礎設施、容器和網路的度量），自動化（如自動擴充套件、動態Provision等）以及策略管理（RBAC、Quota、PSP、NetworkPolicy等）
應用層：部署（無狀態應用、有狀態應用、批處理任務、叢集應用等）和路由（服務發現、DNS解析等）
核心層：Kubernetes最核心的功能，對外提供API構建高層的應用，對內提供外掛式應用執行環境
API相關設計
API原則
- 所有API應該是宣告式的。宣告式的操作，相對於命令式操作，對於重複操作的效果是穩定的，這對於容易出現數據丟失或重複的分散式環境來說是很重要的。另外，宣告式操作更容易被使用者使用，可以使系統向用戶隱藏實現的細節，隱藏實現的細節的同時，也就保留了系統未來持續優化的可能性。此外，宣告式的API，同時隱含了所有的API物件都是名詞性質的，例如Service、Volume這些API都是名詞，這些名詞描述了使用者所期望得到的一個目標分散式物件。
- API物件是彼此互補而且可組合的。這裡面實際是鼓勵API物件儘量實現面向物件設計時的要求，即“高內聚，鬆耦合”，對業務相關的概念有一個合適的分解，提高分解出來的物件的可重用性。
- 高層API以操作意圖為基礎設計。如何能夠設計好API，跟如何能用面向物件的方法設計好應用系統有相通的地方，高層設計一定是從業務出發，而不是過早的從技術實現出發。因此，針對Kubernetes的高層API設計，一定是以Kubernetes的業務為基礎出發，也就是以系統排程管理容器的操作意圖為基礎設計。
- 低層API根據高層API的控制需要設計。設計實現低層API的目的，是為了被高層API使用，考慮減少冗餘、提高重用性的目的，低層API的設計也要以需求為基礎，要儘量抵抗受技術實現影響的誘惑。
- 儘量避免簡單封裝，不要有在外部API無法顯式知道的內部隱藏的機制。簡單的封裝，實際沒有提供新的功能，反而增加了對所封裝API的依賴性。內部隱藏的機制也是非常不利於系統維護的設計方式，例如StatefulSet和ReplicaSet，本來就是兩種Pod集合，那麼Kubernetes就用不同API物件來定義它們，而不會說只用同一個ReplicaSet，內部通過特殊的演算法再來區分這個ReplicaSet是有狀態的還是無狀態。
- API操作複雜度與物件數量成正比。這一條主要是從系統性能角度考慮，要保證整個系統隨著系統規模的擴大，效能不會迅速變慢到無法使用，那麼最低的限定就是API的操作複雜度不能超過O(N)，N是物件的數量，否則系統就不具備水平伸縮性了。
- API物件狀態不能依賴於網路連線狀態。由於眾所周知，在分散式環境下，網路連線斷開是經常發生的事情，因此要保證API物件狀態能應對網路的不穩定，API物件的狀態就不能依賴於網路連線狀態。
- 儘量避免讓操作機制依賴於全域性狀態，因為在分散式系統中要保證全域性狀態的同步是非常困難的。
API結構
API原理
總結
kubernetes來自於谷歌的Brog但其在開源精神的洗禮下完成了再一次升級，尤其API的設計感覺堪稱業界典範。要想了解一個軟體技術人員的水平到底如何只需要看看他給出的介面設計就能瞭解一二了。
又發現了一個不錯的面試題目。
參考資料
- https://jimmysong.io/kubernetes-handbook
- 極客時間的專欄，深入剖析Kubernetes