圖解 Kubernetes 架構

Kubernetes 整體架構圖

Kubernetes 各組件介紹 Kube-Master「控制節點」

• Kube-Master 的工作流程圖

1. Kubecfg 將特定的請求發送給 Kubernetes Client（比如：創建 Pod 的請求）。
2. Kubernetes Client 將請求發送給 API Server。
3. API Server 會根據請求的類型選擇用何種 REST API 對請求作出處理（比如：創建 Pod 時 Storage 類型是 Pods 時，其對應的就是 REST Storage API）。
4. REST Storage API 會對請求作相應的處理並將處理的結果存入高可用鍵值存儲系統 Etcd 中。
5. 在 API Server 響應 Kubecfg 的請求後，Scheduler 會根據 Kubernetes Client 獲取的集群中運行 Pod 及 Minion / Node 信息將未分發的 Pod 分發到可用的 Minion / Node 節點上。

API Server 「資源操作入口」

• API Server 提供了資源對象的唯一操作入口，其它所有組件都必須通過它提供的 API 來操作資源數據。只有 API Server 會與存儲通信，其它模塊都必須通過 API Server 訪問集群狀態。
• API Server 作為 Kubernetes 系統的入口，封裝了核心對象的增刪改查操作。API Server 以 RESTFul 接口方式提供給外部客戶和內部組件調用，API Server 再對相關的資源數據（全量查詢 + 變化監聽）進行操作，以達到實時完成相關的業務功能。
• 以 API Server 為 Kubernetes 入口的設計主要有以下好處：1. 保證了集群狀態訪問的安全。2. API Server 隔離了集群狀態訪問和後端存儲做到，這樣 API Server 狀態訪問的方式不會因為後端存儲技術 Etcd 的改變而改變，讓後端存儲方式選擇更加靈活，方便了整個架構的擴展。

Controller Manager 「內部管理控制中心」

Controller Manager 用於做到 Kubernetes 集群故障檢測和恢復的自動化工作。Controller Manager 主要負責執行以下各種控制器：

• Replication Controller

Replication Controller 的作用主要是定期關聯 Replication Controller (RC) 和 Pod，以保證集群中一個 RC (一種資源對象) 所關聯的 Pod 副本數始終保持為與預設值一致。

• Node Controller

Kubelet 在啟動時會通過 API Server 註冊自身的節點信息，並定時向 API Server 匯報狀態信息。API Server 在接收到信息後將信息更新到 Etcd 中。

Node Controller 通過 API Server 實時獲取 Node 的相關信息，做到管理和監控集群中的各個 Node 節點的相關控制功能。

• ResourceQuota Controller

資源配額管理控制器用於確保指定的資源對象在任何時候都不會超量占用系統上物理資源。

• Namespace Controller

用戶通過 API Server 可以創建新的 Namespace 並保存在 Etcd 中，Namespace Controller 定時通過 API Server 讀取這些 Namespace 信息來操作 Namespace。

比如：Namespace 被 API 標記為優雅刪除，則將該 Namespace 狀態設置為 Terminating 並保存到 Etcd 中。同時 Namespace Controller 刪除該 Namespace 下的 ServiceAccount、RC、Pod 等資源對象。

• Service Account Controller

Service Account Controller (服務帳號控制器)，主要在命名空間內管理 ServiceAccount，以保證名為 default 的 ServiceAccount 在每個命名空間中存在。

• Token Controller

Token Controller（令牌控制器）作為 Controller Manager 的一部分，主要用作：監聽 serviceAccount 的創建和刪除動作以及監聽 secret 的添加、刪除動作。

• Service Controller

Service Controller 是屬於 Kubernetes 集群與外部平台之間的一個接口控制器，Service Controller 主要用作監聽 Service 的變化。

比如：創建的是一個 LoadBalancer 類型的 Service，Service Controller 則要確保外部的雲平台上對該 Service 對應的 LoadBalancer 實例被創建、刪除以及相應的路由轉PO表被更新。

• Endpoint Controller

Endpoints 表示了一個 Service 對應的所有 Pod 副本的訪問地址，而 Endpoints Controller 是負責生成和維護所有 Endpoints 對象的控制器。

Endpoint Controller 負責監聽 Service 和對應的 Pod 副本的變化。定期關聯 Service 和 Pod (關聯信息由 Endpoint 對象維護)，以保證 Service 到 Pod 的映射總是最新的。

Scheduler「集群分發調度器」

• Scheduler 主要用於收集和分析當前 Kubernetes 集群中所有 Minion / Node 節點的資源 (包括記憶體、CPU 等) 負載情況，然後依據資源占用情況分發新建的 Pod 到 Kubernetes 集群中可用的節點。
• Scheduler 會實時監測 Kubernetes 集群中未分發和已分發的所有運行的 Pod。
• Scheduler 會實時監測 Minion / Node 節點信息，由於會頻繁查找 Minion/Node 節點，Scheduler 同時會緩存一份最新的信息在本地。
• Scheduler 在分發 Pod 到指定的 Minion / Node 節點後，會把 Pod 相關的信息 Binding 寫回 API Server，以方便其它組件使用。

Kube-Node「服務節點」

• Kubelet 結構圖

Kubelet 「節點上的 Pod 管家」

• 負責 Node 節點上 Pod 的創建、修改、監控、刪除等全生命周期的管理。
• 定時上報本地 Node 的狀態信息給 API Server。
• Kubelet 是 Master API Server 和 Minion / Node 之間的橋梁，接收 Master API Server 分配給它的 Commands 和 Work。
• Kubelet 通過 Kube ApiServer 間接與 Etcd 集群交互來讀取集群配置信息。
• Kubelet 在 Node 上做的主要工作具體如下：1. 設置容器的環境變量、給容器綁定 Volume、給容器綁定 Port、根據指定的 Pod 運行一個單一容器、給指定的 Pod 創建 Network 容器。2. 同步 Pod 的狀態，從 cAdvisor 獲取 Container Info、 Pod Info、 Root Info、 Machine info。3. 在容器中運行命令、殺死容器、刪除 Pod 的所有容器。

Proxy「負載均衡、路由轉PO」

• Proxy 是為了解決外部網路能夠訪問集群中容器提供的應用服務而設計的，Proxy 運行在每個 Minion / Node 上。
• Proxy 提供 TCP / UDP 兩種 Sockets 連接方式 。每創建一個 Service，Proxy 就會從 Etcd 獲取 Services 和 Endpoints 的配置信息（也可以從 File 獲取），然後根據其配置信息在 Minion / Node 上啟動一個 Proxy 的進程並監聽相應的服務端口。當外部請求發生時，Proxy 會根據 Load Balancer 將請求分發到後端正確的容器處理。
• Proxy 不但解決了同一宿主機相同服務端口衝突的問題，還提供了 Service 轉PO服務端口對外提供服務的能力。Proxy 後端使用隨機、輪循等負載均衡算法進行調度。

Kubectl 「集群管理命令行工具集」

• Kubectl 是 Kubernetes 的 客戶端的工具。 通過 Kubectl 命令對 API Server 進行操作，API Server 響應並返回對應的命令結果，從而達到對 Kubernetes 集群的管理。

本文在 「Kubernetes 總架構圖」的基礎上整理和修改。

http://www.google.com

http://t.cn/RdHiHXX

http://t.cn/RdHimG5

http://t.cn/RdHRDq8

我的人生也許不正確，但是沒有錯。

——北條悟史