Kubernetes 架構與設計

什麼是kubernetes？

官方說明：
Kubernetes is an open-source system for automating deployment, scaling, and management of containerized applications.It groups containers that make up an application into logical units for easy management and discovery.

說簡單點，Kubernetes 就是自動化容器管理平臺，它跟通常的 PaaS 平臺同樣，也都支持好比服務部署、自動運維、資源調度、擴縮容、自我修復、負載均衡，服務發現等功能。

講點不同的，Kubernets 到底有什麼特別的地方？以個人理解仍是在於能力抽象，抽象能夠分爲兩大塊：基礎設施 和 API。

1.基礎設施的抽象

基礎設施包括不少，好比runtime（docker、rkt、pouch），存儲，網絡等。還有不一樣的雲服務提供商，集羣環境的差別都會很大。
像存儲、網絡這類都是難啃的骨頭，若是 Kubernetes 想吃，那就會出現大量的 PR，這些代碼量甚至會比主體代碼倍上好幾倍，不只會提高代碼的複雜度，還會影響系統的穩定性。

因此 Kubernetes 根本不想吃，可是又想作雲無關，便開始實現各種 interface，作各類抽象。好比容器運行時接口（CRI）、容器網絡接口（CNI）、容器存儲接口（CSI）。這些接口讓 Kubernetes 變得無比開放，而其自己則能夠專一於內部部署及容器調度。

Kubernetes 生態中也會有不少通用的功能，好比服務發現、負載均衡、日誌系統、監控系統等，這些都有提供默認方案，且這些方案都是可選、可插拔的。這些也均可以看做是 PaaS 平臺的基礎設施，在 Kubernetes 上也沒有強綁強銷的買賣，給用戶提供了高度的靈活性。

2. API 的抽象

Kubernetes 的各類功能都離不開它定義的資源對象，這些對象均可以經過 API 被提交到集羣的 Etcd 中。API 的定義和實現都符合 HTTP REST 的格式，用戶能夠經過標準的 HTTP 動詞（POST、PUT、GET、DELETE）來完成對相關資源對象的增刪改查。

經常使用的資源對象，好比 Deployment、DaemonSet、Job、PV 等。API 的抽象也意在這部分資源對象的定義。Kubernetes 有新的功能實現，通常會建立新的資源對象，而功能也依託於該對象進行實現。

我以爲這兩部分的抽象，纔是極大的成就了當前的 Kubernetes，使其成爲業界標準的關鍵之一。

設計

Kubernetes 已是一個很是龐大的分佈式系統了，在深刻各種源碼實現以前，值得先了解下 Kubernetes 的設計理念。
這裏先學習下 Kubernetes 的聲明式設計及控制閉環。

1. 聲明式

Kubernetes 採用了聲明式（Declarative）的資源管理模式，該模式會有以下幾個步驟：

• 聲明：用戶經過聲明式的配置文件（json/yaml等）向 Kubernetes 告訴所指望達到的應用狀態。（好比：運行 2 個副本的 nginx 服務）
• 觀測：Kubernetes 會觀測到用戶的聲明，並自動分析出須要執行的操做及用戶所指望達到的應用狀態。（好比選取合適的節點，配置相應的負載均衡策略等）
• 行動：Kubernetes 控制器會負責具體的工做執行，以達到用戶聲明的應用狀態，該過程是全自動化。
• 持續觀測與收斂：大型分佈式系統必然會存在各類異常，好比系統崩潰、容器退出等。Kubernetes 天然會持續關注系統的實時狀態，當遇到異常時可以及時的進行自我修復。好比用戶聲明瞭 2 個 nginx 服務，當其中有個 nginx 掛了，或者所在的宿主機掛了，kubernetes 會自動發現，並尋找合適的節點，再運行一個新的 nginx 服務，以維持用戶所指望達到的應用狀態。

在命令式（Imperative）設計模式中，用戶須要指明一步一步的具體流程和指令，而並不是像聲明式模式同樣直接指明最終想要達到的狀態。
能夠簡單假想下，若是用命令式來實現 Kubernetes集羣，會如何實現？

必然 scheduler 模塊自身不只須要完成本來的調度工做，還攜帶了 apiserver & controller等功能；scheduler 不只須要執行命令，還須要關心命令執行的結果；不少複雜的概念都會堆積在 scheduler 模塊上，致使該模塊愈來愈重，愈來愈複雜。

相對於命令式操做，聲明式操做會更穩定且更容易被用戶接受，由於該API中隱含了用戶想要操做的目標對象，而這些對象恰好都是名詞性質的，好比Service、Deployment、PV等；且聲明式的配置文件更貼近「人類語言」，好比YAML、JSON。

因此相比較，命令式思想在分佈式系統和微服務架構中會存在各類困境。

2. 控制閉環

Kubernetes 使用了聲明式設計模式，這裏控制閉環又起到了什麼做用呢？
咱們能夠從該系統的需求入手分析：

• 持續觀測、校訂，最終將運行狀態達到用戶指望的狀態。
• 感知用戶的行爲並執行。好比修改 Pod 數量，應用升級/回滾等等。

聲明僅僅只是聲明，用戶丟過來一個 yaml 文件後，該如何智能的轉化爲一系列可執行操做，且達到上面所描述的需求？

調度器是核心，但它只是負責從集羣節點中選擇合適的 node 來運行 pods，顯然讓調度器來實現上訴的功能不太合適，而須要有專門的控制器組件來實現。

Kubernetes 實現了大量的 controllers，它們經過 list-watch etcd 來感知集羣數據的更新，而後 24 小時不間斷的工做以達到期待的狀態，在該過程當中它們也會把建立的各種數據反饋回 kube-apiserver & etcd，從而造成了數據流的閉環。

Kube-controller-manager 不只完成了 Kubernetes 集羣功能的半片天，還提供很強大的擴展能力，可讓用戶輕鬆的實現本身的 controllers。

架構

Kubernetes 架構是借鑑了 Borg 的設計理念，以下圖：

Kubernetes 主要由如下幾個核心組件組成：

• Etcd：是高可用的key/value存儲系統，用於持久化存儲集羣中的全部資源對象，好比：Node，Pod，Serivce，RC,namespace等。API server提供了操做etcd的封裝接口API，以Rest的方式提供，這些API基本上都是集羣中資源對象的增刪改查及監聽資源變化的接口，好比建立Pod、RC，監聽Pod的變化等接口。API server是鏈接其餘全部服務組件的中間樞紐。
• API Server：提供了資源對象的惟一操做入口，其餘組件都必須經過它提供的 API 來操做資源數據，經過對相關的資源數據"全量查詢" + "變化監聽"，這些組件能夠很"實時"的完成相關的業務功能。好比提交一個新的 Pod 到 API server 中，Controller Manger 能夠當即就發現並開始做用。它還有一套完備的安全機制，包括認證、受權及准入控制等相關模塊。
• Controller Manger：集羣內部的管理控制中心，主要完成了集羣的故障檢測和恢復的自動化工做。好比對 RC 定義的 Pod 進行維護；根據 service 和 Pod的關係，完成服務的 Endpoints 對象的建立和更新；還有 Node 的發現、管理和狀態監控，死亡容器所佔資源及本地緩存的鏡像文件的清理等工做。
• Scheduler: 集羣的調度器，負責 Pod 在集羣節點中的調度分配。
• Kubelet：負責本地節點上 Pod 的建立、修改、監控、刪除等生命週期管理，同時會上報本 Node 的狀態信息到 API server。
• Kube-proxy：實現 Service 的代理及軟件模式的負載均衡器。
• Kubectl：集羣內部的客戶端能夠直接使用 kubectl 命令管理集羣；集羣外的客戶端須要使用 kubectl Porxy 進行反向代理來訪問 API server。
• cAdvisor: 在 Node 節點運行的 Kubelet 服務中內嵌了一個 cAdvisor 服務，cAdvisor 是谷歌的開源項目，用於實時監控 Docker 上運行的容器的性能指標。

除了這些核心組件，還有一些推薦的服務：

• Kube-DNS：負責爲整個集羣提供 DNS 服務。
• Heapster：提供資源監控服務。
• Dashboard：提供 GUI。
• Fluentd-ES：提供集羣日誌系統。
• ….

分層架構

Kubernetes 有相似於 Linux 的分層架構，以下圖所示：

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

• 生態系統：在接口層之上的龐大容器集羣管理調度的生態系統，能夠劃分爲兩個範疇。

  • Kubernetes 外部：日誌、監控、配置管理、CI、CD、Workflow、FaaS、OTS應用、ChatOps 等
  • Kubernetes 內部：CRI、CNI、CSI、鏡像倉庫、Cloud Provider、集羣自身的配置和管理等。

參考資料

• https://kubernetes.io/docs/co...
• https://github.com/kubernetes...
• https://kubernetes.feisky.xyz...
• https://segmentfault.com/a/11...