k8s 架構與組件詳解

沒有那麼多花裏胡哨，直接進行一個 K8s 架構與組件的學習。

一、K8s 架構

k8s 系統在設計是遵循 c-s 架構的，也就是我們圖中 apiserver 與其餘組件的交互。在生產中通常會有多個 Master 以實現 K8s 系統服務高可用。K8s 集羣至少有一個工作節點，節點上運行 K8s 所管理的容器化應用。

在 Master 通常上包括 kube-apiserver、etcd 存儲、kube-controller-manager、cloud-controller-manager、kube-scheduler 和用於 K8s 服務的 DNS 服務器（插件）。這些對集羣做出全局決策 (比如調度)，以及檢測和響應集羣事件的組件集合也稱爲控制平面。

**其實 K8s 官方並沒有Master這一說，只是大多數安裝工具（kubeadm）或者腳本爲了架構更明瞭會把控制平面中的組件安裝到一臺機器上即 Master 機器，並且不會在此機器上運行用戶容器。**這不是強制性的，所以你也可以對將控制平面實行分佈式部署，不過這樣的話高可用會是一個不小的挑戰。

在 Node 上組件包括 kubelet 、kube-porxy 以及服務於 pod 的容器運行時 (runtime)。外部 storage 與 registry 用於爲容器提供存儲與鏡像倉庫服務。

從 kubectl 開始，我們來看一下 K8s 的基本工作流程：

1.kubectl 客戶端首先將 CLI 命令轉化爲 RESTful 的 API 調用，然後發送到 kube-apiserver。2.kube-apiserver 在驗證這些 API 調用後，將任務元信息並存儲到 etcd，接着調用 kube-scheduler 開始決策一個用於作業的 Node 節點。3. 一旦 kube-scheduler 返回一個適合調度的目標節點後，kube-apiserver 就把任務的節點信息存入 etcd，並創建任務。4. 此時目標節點中的 kubelet 正監聽 apiserver，當監聽到有新任務需要調度到本節點後，kubelet 通過本地 runtime 創建任務容器，執行作業。5. 接着 kubelet 將任務狀態等信息返回給 apiserver 存儲到 etcd。6. 這樣我們的任務已經在運行了，此時 control-manager 發揮作用保證任務一直是我們期望的狀態。

二、K8s 組件介紹

1、控制平面組件

kube-apiserver

API 服務器爲 K8s 集羣資源操作提供唯一入口，並提供認證、授權、訪問控制、API 註冊和發現機制。

Kubernetes API 服務器的主要實現是 kube-apiserver。kube-apiserver 設計上考慮了水平伸縮，也就是說，它可通過部署多個實例進行伸縮。你可以運行 kube-apiserver 的多個實例，並在這些實例之間進行流量平衡。

etcd

etcd 是兼具一致性和高可用性的鍵值數據庫，可以作爲保存 Kubernetes 所有集羣數據的後臺數據庫 (例如 Pod 的數量、狀態、命名空間等）、API 對象和服務發現細節。在生產級 k8s 中 etcd 通常會以集羣的方式存在，安全原因，它只能從 API 服務器訪問。

etcd 也是 k8s 生態的關鍵應用。關於 etcd 可參考 etcd 文檔 [1]。

kube-scheduler

kube-scheduler 負責監視新創建、未指定運行 Node 的 Pods，決策出一個讓 pod 運行的節點。

例如，如果應用程序需要 1GB 內存和 2 個 CPU 內核，那麼該應用程序的 pod 將被安排在至少具有這些資源的節點上。每次需要調度 pod 時，調度程序都會運行。調度程序必須知道可用的總資源以及分配給每個節點上現有工作負載的資源。

調度決策考慮的因素包括單個 Pod 和 Pod 集合的資源需求、硬件 / 軟件 / 策略約束、親和性和反親和性規範、數據位置、工作負載間的干擾和最後時限。

kube-controller-manager

k8s 在後臺運行許多不同的控制器進程，當服務配置發生更改時（例如，替換運行 pod 的鏡像，或更改配置 yaml 文件中的參數），控制器會發現更改並開始朝着新的期望狀態工作。

從邏輯上講，每個控制器都是一個單獨的進程， 但是爲了降低複雜性，它們都被編譯到同一個可執行文件，並在一個進程中運行。

控制器包括:

• 節點控制器（Node Controller）: 負責在節點出現故障時進行通知和響應 • 任務控制器（Job controller）: 監測代表一次性任務的 Job 對象，然後創建 Pods 來運行這些任務直至完成 • 端點控制器（Endpoints Controller）: 填充端點 (Endpoints) 對象(即加入 Service 與 Pod)• 服務帳戶和令牌控制器（Service Account & Token Controllers）: 爲新的命名空間創建默認帳戶和 API 訪問令牌

cloud-controller-manager

雲控制器管理器使得你可以將你的集羣連接到雲提供商的 API 之上， 同時可以將雲平臺交互組件與本地集羣中組件分離。

cloud-controller-manager 僅運行特定於雲平臺的控制迴路。如果我們在自己的環境中運行 Kubernetes，大多數時候非混合雲環境是用不到這個組件的。

與 kube-controller-manager 類似，cloud-controller-manager 將若干邏輯上獨立的 控制迴路組合到同一個可執行文件中，供你以同一進程的方式運行。你可以對其執行水平擴容（運行不止一個副本）以提升性能或者增強容錯能力。

下面的控制器都包含對雲平臺驅動的依賴：

• 節點控制器（Node Controller）: 用於在節點終止響應後檢查雲提供商以確定節點是否已被刪除 • 路由控制器（Route Controller）: 用於在底層雲基礎架構中設置路由 • 服務控制器（Service Controller）: 用於創建、更新和刪除雲提供商負載均衡器

2.Node 中組件

節點組件在每個節點上運行，維護運行的 Pod 並提供 Kubernetes 運行環境。

kubelet

一個在集羣中每個 node 上運行的代理。它保證容器都 運行在 Pod 中。kubelet 定期接收新的或修改過的 pod 規範 PodSpecs（主要通過 kube-apiserver）並確保 pod 及容器健康並以所需狀態運行。該組件還向 kube-apiserver 報告運行它的主機的健康狀況。

kubelet 不會管理不是由 Kubernetes 創建的容器。

kube-proxy

kube-proxy[2] 是集羣中每個節點上運行的網絡代理， 實現 Kubernetes 服務（Service） 概念的一部分。用於處理單個主機子網劃分並向外部世界公開服務。它跨集羣中的各種隔離網絡將請求轉發到正確的 pod / 容器。

kube-proxy 維護節點上的網絡規則。這些網絡規則允許從集羣內部或外部的網絡會話與 Pod 進行網絡通信。

如果操作系統提供了數據包過濾層並可用的話，kube-proxy 會通過它來實現網絡規則。否則， kube-proxy 僅轉發流量本身。

容器運行時（Container Runtime）

容器運行時負責創建容器運行環境。

Kubernetes 支持多個容器運行時: Docker（即將被廢棄）、containerd、CRI-O 以及任何實現 Kubernetes CRI (容器運行環境接口)[3] 的 runtime。

三、tips

K8s 擁有一個完整的雲原生生態，是一個繽紛多彩同時又把複雜度拉滿的世界。

k8s 基礎是容器，雖然 docker 運行時已被 k8s 棄用，但是學習 docker 依然是上手容器化最佳方式。

Kubernetes 官方文檔 https://kubernetes.io/docs/home/

NEXT

•k8s 工作流程詳解

希望小作文對你有些許幫助，如果內容有誤請指正。

您可以隨意轉載、修改、發佈本文，無需經過本人同意。 

References

[1] etcd 文檔: https://etcd.io/docs/
[2] kube-proxy: https://kubernetes.io/zh/docs/reference/command-line-tools-reference/kube-proxy/
[3] Kubernetes CRI (容器運行環境接口): https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md
[4] iqsing.github.io: https://iqsing.github.io

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/QwOVdmru-YpdALBCKvKafA