我第一次接觸容器編排調度工具是 Docker 自家的 Docker Swarm，主要解決當時公司內部業務項目部署繁瑣的問題，我記得當時項目實現容器化之後，花在項目部署運維的時間大大減少了，當時覺得這玩意還挺新鮮的，原來自動化運維可以這麼玩。後面由於工作原因，很久沒碰過容器方面的知識了。最近在公司的數據同步項目中，需要使用到分佈式調度數據同步執行單元，目前使用的方案是將數據同步執行單元打包成鏡像，使用 K8s 進行調度，正好趁這個機會了解一下 K8s，下面我就用圖解的形式將我所理解的 K8s 分享給大家。
K8s 三大核心功能
K8s 是一個輕便的和可擴展的開源平臺，用於管理容器化應用和服務。通過 K8s 能夠進行應用的自動化部署和擴縮容。
K8s 是比容器更上一層的架構，它可以支持多種容器技術，比如我們熟悉的 Docker，K8s 定位是一個容器調度工具，它主要具備以下三大核心能力：
1、自動調度
k8s 將用戶部署提交的容器放到 k8s 集羣的任意一個節點中，k8s 可以根據容器所需要的資源大小，以及節點的負載情況來決定容器放在哪個節點上面。
2、自動修復
當 k8s 的健康檢查機制發現某個節點出現問題，它會自動將該節點上的資源轉移到其它節點上面完成自動恢復。
3、橫向自動擴縮容
在 k8s 1.1+ 版本中，有一個功能叫 “ Horizontal Pod Autoscaler”，簡稱 “HPA”，意思是 Pod自動擴容，它可以預先定義 Pod 的負載指標，當達到預期設定的負載指標後，就會根據指標自動觸發自動動態擴容/縮容行爲。
1）橫向自動擴容
2）橫向自動縮容
節點
從上面的圖可以看出來，k8s 集羣的節點有兩個角色，分別爲 Master 節點和 Node 節點，整個 K8s 集羣Master 和 Node 節點關係如下圖所示：
1、Master 節點
Master 節點也稱爲控制節點，每個 k8s 集羣都有一個 Master 節點負責整個集羣的管理控制，我們上面介紹的 k8s 三大能力都是經過 Master 節點發起的，Master 節點包含了以下幾個組件：
- API Server：提供了 HTTP Rest 接口的服務進程，所有資源對象的增、刪、改、查等操作的唯一入口；
- Controller Manager：k8s 集羣所有資源對象的自動化控制中心；
- Scheduler：k8s 集羣所有資源對象自動化調度控制中心；
- ETCD：k8s 集羣註冊服務發現中心，可以保存 k8s 集羣中所有資源對象的數據。
2、Node
Node 節點的作用是承接 Master 分配的工作負載，它主要有以下幾個關鍵組件：
- kubelet：負責 Pod 對應容器的創建、啓停等操作，與 Master 節點緊密協作；
- kube-porxy：實現 k8s 集羣通信與負載均衡的組件。
從圖上可看出，在 Node 節點上面，還需要一個容器運行環境，如果使用 Docker 技術棧，則還需要在 Node 節點上面安裝 Docker Engine，專門負責該節點容器管理工作。
Pod
Pod 是 k8s 最重要而且是最基本的一個資源對象，它的結構如下：
從以上 Pod 的結構圖可以看出，它其實是容器的一個上層包裝結構，這也就是爲什麼 K8s 可以支持多種容器類型的原因，基於這方面，我理解 k8s 的定位就是一個編排與調度工具，而容器只是它調度的一個資源對象而已。
Pod 可包含多個容器在裏面，每個 Pod 至少會有一個 Pause 容器，其它用戶定義的容器都共享該 Pause 容器，Pause 容器的主要作用是用於定義 Pod 的 ip 和 volume。
Pod 在 k8s 集羣中的位置如下圖所示：
Label
Label 在 k8s 中是一個非常核心的概念，我們可以將 Label 指定到對應的資源對象中，例如 Node、Pod、Replica Set、Service 等，一個資源可以綁定任意個 Label，k8s 通過 Label 可實現多維度的資源分組管理，後續可通過 Label Selector 查詢和篩選擁有某些 Label 的資源對象，例如創建一個 Pod，給定一個 Label，workerid=123，後續可通過 workerid=123 刪除擁有該標籤的 Pod 資源。
Replica Set
Replica Set 目的是爲了定義一個期望的場景，比如定義某種 Pod 的副本數量在任意時刻都處於 Peplica Set 期望的值，假設 Replica Set 定義 Pod 的副本數目爲：replicas=2，當該 Replica Set 提交給 Master 後，Master 會定期巡檢該 Pod 在集羣中的數目，如果發現該 Pod 掛掉了一個，Master 就會嘗試依據 Replica Set 設置的 Pod 模版創建 Pod，以維持 Pod 的數量與 Replica Set 預期的 Pod 數量相同。
通過 Replica Set，k8s 集羣實現了用戶應用的高可用性，而且大大減少了運維工作量。因此生產環境一般用 Deployment 或者 Replica Set 去控制 Pod 的生命週期和期望值，而不是直接單獨創建 Pod。
類似 Replica Set 的還有 Deployment，它的內部實現也是通過 Replica Set 實現的，可以說 Deployment 是 Replica Set 的升級版，它們之間的 yaml 配置文件格式大部分都相同。
Service
Service 是 k8s 能夠實現微服務集羣的一個非常重要的概念，顧名思義，k8s 的 Service 就是我們平時所提及的微服務架構中的“微服務”，本文上面提及的 Pod、Replica Set 等都是爲 Service 服務的資源， 如下圖表示 Service、Pod、Replica Set 的關係：
從上圖可看出，Service 定義了一個服務訪問的入口，客戶端通過這個入口即可訪問服務背後的應用集羣實例，而 Service 則是通過 Label Selector 實現關聯與對接的，Replica Set 保證服務集羣資源始終處於期望值。
以上只是一個微服務，通常來說一個應用項目會由多個不同業務能力而又彼此獨立的微服務組成，多個微服務間組成了一個強大而又高可用的應用服務集羣。
Namespace
Namespace 顧名思義是命名空間的意思，在 k8s 中主要用於實現資源隔離的目的，用戶可根據不同項目創建不同的 Namespace，通過 k8s 將資源分配到不同 Namespace 中，即可實現不同項目的資源隔離：
作者簡介
作者張乘輝，擅長消息中間件技能，負責公司百萬 TPS 級別 Kafka 集羣的維護，作者維護的公號「後端進階」不定期分享 Kafka、RocketMQ 系列不講概念直接真刀真槍的實戰總結以及細節上的源碼分析；同時作者也是阿里開源分佈式事務框架 Seata Contributor，因此也會分享關於 Seata 的相關知識；當然公號也會分享 WEB 相關知識比如 Spring 全家桶等。內容不一定面面俱到，但一定讓你感受到作者對於技術的追求是認真的！
公衆號：後端進階
GitHub：https://github.com/objcoding/
