《K8s 原始碼解析》第一章閱讀筆記

《K8s 原始碼解析》第一章閱讀筆記

K8s 系統特點

• 可移植：支援公有云、私有云、混合雲、多重雲。
• 可擴充套件：模組化、外掛化、可掛載、可組合。
• 自動化：自動部署、自動重啟、自動複製、自動伸縮/擴充套件。

1.1 K8s 發展歷史

• 2003-2004 年：Google 釋出 Brog 系統
• 2013 年左右：Google 繼 Brog 系統釋出 Omega 叢集管理系統
• 2014 年左右：Google 釋出了 K8s（作為 Brog 的開源版本釋出）
• 2015 年左右：Google 正式釋出 K8s1.0，並與 Linux 基金會合作組建了 CNCF
• 2016 年左右：K8s 成為主流
• 2017 年左右：Google 和 IBM 釋出微服務框架 Istio，Amazon 宣佈為 K8s 提供彈性容器服務，年底 K8s1.9 釋出
• 2018 年左右：K8s1.10 釋出

1.2 K8s 架構圖

K8s 系統用於給管理分散式節點叢集中的微服務或容器化應用程式，並且其提供了零停機時間部署、自動回滾、縮放和容器的自愈（其中包括自動配置、自動重啟、自動複製的高彈性基礎設施，以及容器的自動縮放等）等功能。

• K8s 系統最重要的設計之一：橫向擴充套件，即調整應用程式的副本數提高可用性

K8s 遵循微服務架構模式的程式，具有彈性、可觀察性和管理功能，適應雲平臺需求。

---

K8s 系統架構遵循C/S 架構，分為兩部分：

• Master（服務端）
• Node（客戶端）

可具有多個 Master 實現高可用，預設情況下一個 master 可完成所有工作

Master 服務端

同時被稱為主控節點，在叢集中主要負責如下任務：

1. 叢集的 “大腦”，負責管理所有節點（Node）。
2. 負責排程 Pod在哪些節點上執行。
3. 負責控制叢集執行過程中的所有狀態。

叢集所執行的所有控制命令都是 Master 接收並處理。

Node 客戶端

同時被稱為工作節點，在叢集中主要負責如下任務：

1. 負責管理所有 Container。
2. 負責監控/上報所有 Pod的執行狀態。

Master 元件包含如下：

• kube-apiserver：叢集的 HTTP REST API 介面，是叢集控制的入口。
• kube-controller-manager：叢集中所有資源物件的自動化控制中心。
• kube-scheduler：叢集中 Pod 資源物件的排程服務。

Node 元件包含如下：

• kubelet：負責管理節點上容器的建立、刪除、啟停等任務，與 Master 進行通訊。
• kube-proxy：負責 K8s 服務的通訊及負載均衡服務。
• container：負責容器的基礎管理服務，接收Kubelet元件的指令。

1.3 K8s 各元件功能

kubectl

• 官方提供的CLI

與K8s API Server（kube-apiserver）進行互動，通訊協議使用HTTP/JSON。

client-go

• 程式設計的方式進行通訊互動

K8s 系統的其他元件和 K8s API Server 通訊的方式也基於client-go實現。

熟練使用並掌握client-go是每個 K8s 開發者必備的技能。

kube-apiserver

也被稱為 Kubernetes API Server。

負責那個 K8s“資源組/資源版本/資源” 以 RESTful 風格的形式對外暴露並提供服務。K8s 叢集中的所有元件都通過此元件操作資源物件。也是唯一與Etcd 叢集進行互動的核心元件。

Etcd 叢集時分散式鍵值儲存叢集，也提供了可靠的強一致性服務發現。儲存了 K8s 系統叢集的狀態和後設資料。

kube-apiserver 具有以下重要特性：

• 將系統中的所有資源物件都封裝成 RESTful 風格的 API 介面進行管理。
• 可進行叢集狀態管理和資料管理，是唯一與 Etcd 叢集互動的元件。
• 擁有豐富的叢集安全訪問機制，以及認證、授權及准入控制器。
• 提供了叢集各元件的通訊和互動功能。

kube-controller-manager

也被稱為Controller Manager（管理控制器），負責管理叢集中的 Node、Pod 副本、Service、Endpoint、Namespace、ServiceAccount、ResourceQuota 等。

• 負責確保系統的實際狀態收斂到所需狀態，其預設是提供了一些控制器。

• 具備高可用性，即基於 Etcd 叢集上的分散式鎖實現領導者選舉機制，多例項同時執行，通過 kube-apiserver 提供的資源鎖進行選舉競爭。

即 Raft 協議中的領導者選舉機制，需要了解 Leader、Candidate 兩個節點角色。

kube-scheduler

也被稱為排程器，目前是 K8s 叢集的預設排程器。負責在叢集中為一個 Pod 資源物件找到合適的節點並在該節點上執行

每次只排程一個 Pod 資源物件，其尋找節點的過程是一個排程週期。

• 監控整個叢集的Pod 資源物件和 Node 資源物件，當監控到新的 Pod 資源物件時，通過排程演算法為其選擇最優節點。

排程演算法分為兩種，預選排程演算法和優選排程演算法。除排程策略外，K8s 支援優先順序排程、搶佔機制及親和性排程等功能。

• 支援高可用性，即上面我們所提到的領導者選舉機制。

kubelet

用於管理節點，執行在每個節點上。用來接收、處理、上報 Kube-apiserver元件下發的任務。

• 負責所有 Node 上的Pod 資源物件的管理。

• 定期監控所在 Node 的資源使用狀態並上報給 kube-apiserver 元件，可幫助 kube-scheduler 排程器為 Pod 資源物件預選節點。

• 對所在節點的映象和容器做清理工作。

其實現了三種開放介面：

• Container Runtime Interface：簡稱 CRI，提供容器執行時通用外掛介面服務。CRI 定義了容器和映象服務的介面。
• Container Nerwork Interface：簡稱 CNI，提供網路通用外掛介面服務。CNI 定義了 K8s 網路外掛的基礎。
• Container Storage Interface：簡稱 CSI，提供儲存通用外掛介面服務。CRI 定義了容器儲存卷標準規範。

kube-proxy

作為節點上的網路代理，監控 kube-apiserver 的服務和端點資源變化，並通過 iptables/ipvs 等配置負載均衡器，為以一組 Pod 提供統一的 TCP/UDP*流量轉發和負載均衡*功能。

• Kube-proxy 是參與管理 Pod-to-Service 和 External-to-Service 網路的最重要的節點元件之一。

其代理只向 K8s 服務及其後端 Pod 發出請求。

1.4 Kubernetes Project Layout 設計

Kubernetes 專案由 Go 語言編寫。

而 Go 語言的Standard Go Project Layout也就成為該專案的參考目錄結構。

詳細資訊可檢視Standard Go Project Layout

K8s 系統元件較多，各元件的程式碼入口 main*結構設計風格高度一致*，我們以核心元件為例，命令示例如下：

每個元件的初始化過程也非常類似，初始化過程示意圖如圖所示。

main 結構定義了程式執行的週期，包括程式啟動、執行到退出的過程。以kube-apiserver元件為例，其初始化過程如圖所示。