朱曄的互聯網架構實踐心得S2E3：品味Kubernetes的設計理念

Kubernetes（k8s）是一款開源的優秀的容器編排調度系統，其自己也是一款分佈式應用程序。雖然本系列文章討論的是互聯網架構，可是k8s的一些設計理念很是值得深思和借鑑，本人並不是運維專家，本文嘗試從本身看到的一些k8s的架構理念結合本身的理解來分析 k8s在穩定性、簡單、可擴展性三個方面作的一些架構設計的考量。

• 穩定性：考慮的是系統自己足夠穩定，用戶使用系統作的一些動做可以穩定落地，系統自己容錯性足夠強能夠應對網絡問題，系統自己有足夠的高可用等等。
• 簡單：考慮的是系統自己的設計足夠簡單，組件之間沒有太多耦合，組件職責單一等等。
• 可擴展性：考慮的是系統的各個模塊有層次，模塊對內對外一視同仁，外部能夠輕易實現擴展模塊插入到系統（插件），模塊實現統一的接口便於替換切換具體實現等等。
  下面，針對這三方面咱們都會來看一些k8s設計的例子，在看k8s是怎麼作的同時咱們能夠本身思考一下，若是咱們須要研發的一款產品就是相似於k8s這樣的須要高可靠的資源狀態管理協調系統，咱們會怎麼來設計呢？

一、穩定：聲明式應用程序管理

咱們知道，k8s定義了許多資源（好比Pod、Service、Deployment、ReplicaSet、StatefulSet、Job、CronJob等），在管理資源的時候咱們使用聲明式的配置（JSON、YAML等）來對資源進行增刪改查操做。咱們提供的這些配置就是描述咱們但願這些資源最終達成的一個目標狀態，叫作Spec，k8s會對觀察資源獲得資源的狀態，叫作Status，當Spec!=Status的時候，k8s的各類控制管理程序就會起做用，進行各類操做使得資源最終能夠達到咱們指望的Spec。這種聲明式的管理方式和命令式管理方式相比，雖然沒有後者這麼直接，可是容錯性會很強，後面一節會進一步詳細提到這點。並且，這種管理方式很是的簡潔，只要用戶提供合適的Spec定義便可，並不須要對外暴露幾十個幾百個不一樣的API來實現對資源的各個方面作改變。固然，咱們也能夠靈活的對一些重要的動做單獨開闢管理API（好比擴容，好比修改鏡像），這些API底層作的操做就是修改Spec，底層是統一的。

在以前第一季的系列文章S1E2中，我分享過任務表的設計，其實這裏的聲明式對象管理就是相似這樣的思想，咱們在數據庫中保存的是咱們要的結果，而後由不一樣的任務Job來進行處理最終實現這樣的結果（同時也會保存組件當前的狀態到數據庫），即便任務執行失敗也無妨，後續的任務會繼續重試，這種方式是可靠性最高的。

二、穩定：邊緣觸發 vs 水平觸發

K8s使用的是聲明式的管理方式，也就是水平觸發。另外一種作法是叫作命令式的管理，也就是邊緣觸發。好比咱們在作支付系統，用戶充值100元，提現100元而後又充值100元，對於命令式管理就是三條命令。若是提現請求丟失了，用戶帳戶的餘額就出錯了，這確定是不能接受的，命令式管理或邊緣觸發必定須要配合補償。而聲明式的管理就是告訴系統，用戶在進行了三次操做後的餘額分別是100、0和100，最終就是100，即便提現請求丟失了，最終用戶的餘額就是100。

來看下下圖的例子，在網絡良好的狀況下，邊緣觸發沒任何問題。咱們進行了開、關、開三次操做，最後的狀態是0。

在網絡出現問題的時候，丟失了關這個操做，對於邊緣觸發，最終停留在了2這個錯誤的狀態。對於水平觸發沒有這個問題，雖然當中有一段時間網絡很差，狀態錯誤停留在了1，可是網絡恢復後咱們立刻能夠感知到當前的狀態應該是0，狀態又能回到0，最終狀態也能回到正確的1。試想一下，若是咱們對咱們的Pod進行擴容縮容，若是每次告知k8s應該增長或減小多少個Pod（的這種命令式方式），最終極可能由於網絡問題，Pod的狀態不是咱們指望的。更好的作法是告訴k8s咱們但願的狀態，無論如今網絡是否有問題，某個管理組件是否有問題，pod是否有問題，最終咱們指望k8s幫咱們調整到咱們指望的狀態，寧肯慢也不要錯。

（圖來自這裏）

三、穩定：高可用設計

咱們知道etcd是基於Raft協議的分佈式鍵值數據庫/協調系統，自己推薦使用三、五、7這樣奇數節點構成集羣實現高可用。對於Master節點，咱們能夠在每個節點都部署一個etcd，這樣節點上的API Server能夠和本地的etcd直接通信，而API Server由於是輕（無）狀態的，因此能夠在以前使用負載均衡器作代理，無論是Node節點也好仍是客戶端也好均可以由負載均衡分發請求到合適的API Server上。對於相似於Job的Controller Manager以及Scheduler，顯然不適合多個節點同時運行，因此它們都會採用搶佔方式選舉Leader，只有Leader能承擔工做任務，Follower都處於待機狀態。總體結構以下圖所示：

咱們能夠想一下其它一些分佈式系統的高可用方案，以及咱們本身設計的系統的高可用方案，無非就是這三種大模式：

• 無狀態多節點 + 負載均衡
• 有狀態的主節點 + 從（或備份）節點
• 對稱同步的有狀態多節點

四、簡單：基於list-watch的發佈訂閱

經過前面的介紹咱們大概知道了k8s的一個設計原則是etcd會處於API Server以後，集羣內的各類組件是沒法直接和數據庫對話的，不只僅由於把數據庫直接暴露給各組件會特別混亂，更重要的是誰均可以直接讀寫etcd會很是不安全，須要統一通過API Server作身份認證和鑑權等安全控制（後面咱們會提到API Server的插件鏈）。

對於k8s集羣內的各類資源，k8s的控制管理器和調度器須要感知到各類資源的狀態變化（好比建立），而後根據變化事件履行本身的管理職責。考慮到解耦，顯然這裏有MQ的需求，各類管理組件能夠監聽各類資源的狀態變化事件，不須要相互感知到對方的存在，本身作本身的事情便可。若是k8s還依賴一些消息中間件實現這個功能，那麼總體的複雜度會上升，並且還須要對消息中間件進行一些安全方面的定製。

K8s給出的實現方式是仍然使用API Server來充當簡單的消息總線的角色，全部的組件經過watch機制創建HTTP長連接來隨時獲悉本身感興趣的資源的變化事件，完成本身的功能後仍是調用API Server來寫入咱們組件新的Spec，這份Spec會被其它管理程序感知到而且進行處理。Watch的機制是推的機制，能夠實時對變化進行處理，可是咱們知道考慮到網絡等各類因素，事件可能丟失，組件可能重啓，這個時候咱們須要推拉結合進行補償，所以API Server還提供了List接口，用於在watch出現錯誤的時候或是組件重啓的時候同步一次最新狀態。經過推拉結合的list-watch機制知足了時效性需求和可靠性需求。

咱們來看一下這個圖，這個圖展現了客戶端建立一個Deployment後k8s大概的工做過程：
組件初始化階段：

• Deployment Controller訂閱Deployment建立事件
• ReplicaSet Controller訂閱ReplicaSet建立事件
• Scheduler訂閱未綁定Node的Pod建立事件
• 全部Kubelet訂閱本身節點的Node和Pod綁定事件

集羣資源變動操做：

1. 客戶端調用API Server建立Deployment Spec
2. Deployment Controller收到消息須要處理新的Deployment
3. Deployment Controller調用API Server建立ReplicaSet
4. ReplicaSet Controller收到消息須要處理新的ReplicaSet
5. ReplicaSet Controller調用API Server建立Pod
6. Scheduler收到消息，須要處理的新的Pod
7. Scheduler通過處理後決定把這個Pod綁定到Node1，調用API Server寫入綁定
8. Node1上的Kubelet收到事消息須要處理Pod的部署
9. Node1上的Kubelet根據Pod的Spec進行Pod部署

能夠看到基於list-watch的API Server實現了簡單可靠的消息總線的功能，基於資源消息的事件鏈，解耦了各組件之間的耦合，配合以前提到的基於聲明式的對象管理又確保了管理穩定性。從層次上來講，master的組件都是控制面的組件，用來控制管理集羣的狀態，node的組件是執行面的組件，kubelet是一個無腦執行者的角色，它們的交流橋樑是API Server的各類事件，kubelet是沒法感知到控制器的存在的。

五、簡單：API Sever收斂資源管理入口

以下圖所示，API Server實現了基於插件+過濾器鏈的方式（好比咱們熟知的Spring MVC的攔截器鏈）來實現資源管理操做的前置校驗（身份認證、受權、准入等等）。

整個流程會有哪些環節呢：

• 身份認證，根據各類插件肯定來者是誰
• 受權，根據各類插件肯定用戶是否有資格能夠操做請求的資源
• 默認值和轉換，資源默認值設置，客戶端到etcd版本號轉換
• 管理控制，根據各類插件執行資源的驗證或修改操做，先修改後驗證
• 驗證，根據各類驗證規則驗證每個字段有效性
• 冪等和併發控制，使用樂觀併發方式（版本號方式）驗證資源還沒有被併發修改
• 審計，記錄全部資源變動日誌

若是是刪除資源，還會有額外的一些環節：

• 優雅關閉
• 終接器鉤子，能夠配置一些終接器，在這個時候回調
• 垃圾回收，級聯刪除沒有引用根的資源

對於複雜的流程式的操做，採用職責鏈+處理鏈+插件的方式來實現是很常見的作法。你可能會說這個API Server的設計整體上就不簡單，怎麼有這麼多環節，其實這纔是最簡單的作法，每個環節都有獨立的插件來運做（插件能夠獨立更新升級，也能夠根據需求動態插拔配置），每個插件只是作本身應該作的事情，若是沒有這樣的設計，恐怕會出現1萬行代碼的一個大方法。

六、簡單：Scheduler的設計

如圖所示，相似於API Server的鏈式設計，Scheduler在作Pod調度算法的時候也採用了鏈式設計：

• 待調度的Pod自己有一個優先級的概念，優先級高的先調度
• 先找出全部的可用節點
• 使用predicate（過濾器）篩選節點
• 使用priority（排序器）對節點進行排序
• 選擇最大優先級的節點調度給Pod

常見的predicate算法有：

• 端口衝突監測
• 資源是否知足
• 親和性考量
• ……

常見的priority算法有：

• 網絡拓撲臨近
• 平衡資源使用
• 資源較多節點優先
• 已使用的節點優先
• 已緩存鏡像節點優先
• ……

好比咱們在作相似路由系統這種業務系統的時候能夠借鑑這種設計模式。簡單一詞在於每個小組件簡單，它們能夠組合起來構成複雜的規則系統，這種設計比把全部邏輯堆在一塊兒簡單的多。

七、擴展：分層架構

K8s的設計理念是相似Linux的分層架構：

• 核心層：Kubernetes 最核心的功能，對外提供 API 構建高層的應用，對內提供插件式應用執行環境
• 應用層：部署（無狀態應用、有狀態應用、批處理任務、集羣應用等）和路由（服務發現、DNS 解析等）
• 管理層：系統度量（如基礎設施、容器和網絡的度量），自動化（如自動擴展、動態 Provision 等）以及策略管理（RBAC、Quota、PSP、NetworkPolicy 等）
• 接口層：kubectl 命令行工具、客戶端 SDK 以及集羣聯邦

以前介紹的一些組件大多數位於核心層和應用層。在更上層的管理層和接口層，咱們每每會作更多的一些二次開發。在以前的文章中我也介紹過，對於複雜的微服務互聯網系統，咱們也應該把微服務進行分層，從下到上分爲基礎服務、業務服務、聚合業務服務等，每一層的服務聚合下層實現一些業務邏輯，不但能夠作到服務重用，並且上層多變的業務服務的變更能夠不影響下層基礎設施的搭建。

八、擴展：接口化和插件

除了k8s大量內部組件的實現使用了插件的架構，k8s在總體設計上就把核心和外部的一些資源和服務抽象爲了統一的接口，能夠插件方式插入具體的實現，以下圖所示：

• 容器方面，容器運行時插件（Container Runtime Interface，簡稱 CRI）是 k8s v1.5 引入的容器運行時接口，它將 Kubelet 與容器運行時解耦，將原來徹底面向 Pod 級別的內部接口拆分紅面向 Sandbox 和 Container 的 gRPC 接口，並將鏡像管理和容器管理分離到不一樣的服務。
• 網絡方面，k8s支持兩種插件：
  • kubenet：這是一個基於 CNI bridge 的網絡插件（在 bridge 插件的基礎上擴展了 port mapping 和 traffic shaping ），是目前推薦的默認插件
  • CNI：CNI 網絡插件，Container Network Interface (CNI) 最先是由CoreOS發起的容器網絡規範，是Kubernetes網絡插件的基礎。
• 存儲方面，Container Storage Interface (CSI) 是從 k8s v1.9 引入的容器存儲接口，用於擴展 Kubernetes 的存儲生態。實際上，CSI 是整個容器生態的標準存儲接口，一樣適用於 Mesos、Cloud Foundry 等其餘的容器集羣調度系統
  咱們看下下面這個圖，k8s使用CRI插件來管理容器，爲容器配置網絡的時候又走了CNI插件：

CNI、CSI、CRI咱們比較熟悉了，其它更多的抽象接口這裏就不描述了，k8s就像一個大主板，主板上有各類內存、CPU、IO、網絡方面的接口，具體的實現k8s自己並不關心，用戶和社區甚至能夠根據的須要實現本身的插件。
我以爲這點是最了不得的最困難的，不少時候咱們在設計一個系統的時候一開始是沒法定義出抽象接口的，由於咱們不知道未來會面對什麼樣的實現，只有到實現愈來愈多後咱們才能抽象出接口才能制定標準。

九、擴展：PV & PVC & StorageClass

K8s在存儲方面的解耦設計特別值得一提。以下圖所示，咱們來看一下k8s在存儲這塊的解耦設計：

（圖引自Kubernetes in Action一書）
咱們要作的事情很明確，Pod須要綁定存儲資源：

• 首先，咱們確定須要有卷這種抽象，來抽象出存儲方式。可是，若是每次都讓k8s的使用者（無論是運維仍是開發）在部署Pod的時候設置須要的卷顯然耦合太強了（好比NFS卷，每次都要設置地址，用於無需也沒法關注到底層的這些細節）。卷V描述的是底層存儲能力。
• 因而，k8s抽象出持久卷PV和和持久卷聲明PVC的概念，管理員能夠先設置配置PV映射到卷，用戶只須要建立PVC來關聯PV，而後在建立Pod的時候引用PVC便可，PVC並不關注卷的一些具體細節，只關注容量需求和操做權限。PV這層抽象描述的是運維能提供出來的全局卷的資源，PVC這層描述的是用戶但願爲Pod申請的存儲資源請求。
• 可是老是須要運維先建立PV仍是不方便，k8s還提供了StorageClass這層抽象，經過把PVC關聯到指定的（或默認的）StorageClass來動態建立PV。

K8s中除了存儲抽象的V、PV、PVC、SC，還有其它的一些組件也有相似層次的抽象以及動態綁定的理念。

咱們在使用OO語言進行編程的時候，很天然知道咱們須要先定義類，而後再實例化類來建立對象，若是類特別複雜（有不一樣的實現）的話，咱們可能會使用工廠模式（或反射，外層傳入目標類型名稱）來建立對象。能夠和k8s存儲抽象比較一下，是否是這個意思，這其實就是一種解耦的方式，在架構設計中，甚至表結構設計中，咱們徹底能夠引入類和實例的概念。好比工做流系統的工做流能夠認爲是一個類模板，每一次發起的工做流就是這個工做流的實例。

總結

好了，本文大概窺探了一下k8s的架構，不知道你是否感覺到了k8s的精良設計，對內考慮了高可用以及高可靠，對外考慮到了高可擴展性。幾乎任何操做都容許失敗，最終實現一致的狀態，幾乎任何組件都容許擴展和替換，讓用戶實現本身的定製需求。

若是你的業務系統也是一套複雜的資源協調系統（k8s抽象的是運維相關的資源，咱們的業務系統能夠抽象的是其它資源），那麼k8s的設計理念有至關多的點能夠借鑑。舉一個例子，咱們在作一套很複雜的流程引擎，咱們就能夠考慮：

• 流程的執行者抽象出接口，插件方式插入系統
• 流程涉及到的資源咱們能夠先梳理清楚列出來
• 流程的管理能夠把指望結果聲明式方式存儲到數據庫
• 流程的管控組件能夠都對着統一的API服務讀寫&訂閱變化
• 流程的管控組件自己能夠採用插件鏈、職責鏈方式執行
• 流程的入口能夠由統一的網關收口作認證和鑑權等
• ……