我第一次接觸容器編排排程工具是 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 全家桶等。內容不一定面面俱到，但一定讓你感受到作者對於技術的追求是認真的！ 公眾號：後端進階 技術部落格：https://objcoding.com/ GitHub：https://github.com/objcoding/ ![公眾號「後端進階」，專注後端技術分享！](https://gitee.com/objcoding/md-picture/raw/master/img/official_accoun