沒有那么多花里胡哨，直接進行一個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的基本工作流程：
- kubectl 客戶端首先將CLI命令轉化為RESTful的API調用，然后發送到kube-apiserver。
- kube-apiserver 在驗證這些 API 調用后，將任務元信息並存儲到etcd，接着調用 kube-scheduler 開始決策一個用於作業的Node節點。
- 一旦 kube-scheduler 返回一個適合調度的目標節點后，kube-apiserver 就把任務的節點信息存入etcd，並創建任務。
- 此時目標節點中的 kubelet正監聽apiserver，當監聽到有新任務需要調度到本節點后，kubelet通過本地runtime創建任務容器，執行作業。
- 接着kubelet將任務狀態等信息返回給apiserver存儲到etcd。
- 這樣我們的任務已經在運行了，此時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
-
K8s擁有一個完整的雲原生生態，是一個繽紛多彩同時又把復雜度拉滿的世界。
-
k8s基礎是容器，雖然docker運行時已被k8s棄用，但是學習docker依然是上手容器化最佳方式。
-
Kubernetes 官方文檔https://kubernetes.io/docs/home/
NEXT
- k8s工作流程詳解
希望小作文對你有些許幫助，如果內容有誤請指正。
您可以隨意轉載、修改、發布本文，無需經過本人同意。 沒什么用的blog：iqsing.github.io