圖解 K8s 核心概念和術語

我第一次接觸容器編排調度工具是 Docker 自家的 Docker Swarm，主要解決當時公司內部業務項目部署繁瑣的問題，我記得當時項目實現容器化以後，花在項目部署運維的時間大大減小了，當時以爲這玩意還挺新鮮的，原來自動化運維能夠這麼玩。後面因爲工做緣由，好久沒碰過容器方面的知識了。最近在公司的數據同步項目中，須要使用到分佈式調度數據同步執行單元，目前使用的方案是將數據同步執行單元打包成鏡像，使用 K8s 進行調度，正好趁這個機會了解一下 K8s，下面我就用圖解的形式將我所理解的 K8s 分享給你們。

K8s 三大核心功能

K8s 是一個輕便的和可擴展的開源平臺，用於管理容器化應用和服務。經過 K8s 可以進行應用的自動化部署和擴縮容。

K8s 是比容器更上一層的架構，它能夠支持多種容器技術，好比咱們熟悉的 Docker，K8s 定位是一個容器調度工具，它主要具有如下三大核心能力：

一、自動調度

k8s 將用戶部署提交的容器放到 k8s 集羣的任意一個節點中，k8s 能夠根據容器所須要的資源大小，以及節點的負載狀況來決定容器放在哪一個節點上面。

二、自動修復

當 k8s 的健康檢查機制發現某個節點出現問題，它會自動將該節點上的資源轉移到其它節點上面完成自動恢復。

三、橫向自動擴縮容

在 k8s 1.1+ 版本中，有一個功能叫 「 Horizontal Pod Autoscaler」，簡稱 「HPA」，意思是 Pod自動擴容，它能夠預先定義 Pod 的負載指標，當達到預期設定的負載指標後，就會根據指標自動觸發自動動態擴容/縮容行爲。

1）橫向自動擴容

2）橫向自動縮容

節點

從上面的圖能夠看出來，k8s 集羣的節點有兩個角色，分別爲 Master 節點和 Node 節點，整個 K8s 集羣Master 和 Node 節點關係以下圖所示：

一、Master 節點

Master 節點也稱爲控制節點，每一個 k8s 集羣都有一個 Master 節點負責整個集羣的管理控制，咱們上面介紹的 k8s 三大能力都是通過 Master 節點發起的，Master 節點包含了如下幾個組件：

• API Server：提供了 HTTP Rest 接口的服務進程，全部資源對象的增、刪、改、查等操做的惟一入口；
• Controller Manager：k8s 集羣全部資源對象的自動化控制中心；
• Scheduler：k8s 集羣全部資源對象自動化調度控制中心；
• ETCD：k8s 集羣註冊服務發現中心，能夠保存 k8s 集羣中全部資源對象的數據。

二、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/