沒有那麼多花裡胡哨，直接進行一個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 文件。

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 是叢集中每個節點上執行的網路代理， 實現 Kubernetes 服務（Service） 概念的一部分。用於處理單個主機子網劃分並向外部世界公開服務。它跨叢集中的各種隔離網路將請求轉發到正確的 pod/容器。

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

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

容器執行時（Container Runtime）

容器執行時負責建立容器執行環境。

Kubernetes 支援多個容器執行時: Docker（即將被廢棄）、containerd、CRI-O以及任何實現 Kubernetes CRI (容器執行環境介面)的runtime。

三、tips

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

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

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

NEXT

• k8s工作流程詳解

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

您可以隨意轉載、修改、釋出本文，無需經過本人同意。 沒什麼用的blog：iqsing.github.io