我第一次接觸容器編排調度工具是 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://www.uj5u.com/qita/689.html
標籤：其他