Kubernetes 的基本概念和術語

  • 2019 年 12 月 30 日
  • 筆記

Master

Kubernetes 里的 Master 指的是集群的控制節點，負責整個集群的管理和控制。 在 Master 上運行中以下關鍵進程：

  • Kubernetes API Server（kube-apiserver）：提供了 HTTP Rest 介面的關鍵服務進程，是 Kubernetes 里所有資源的增刪改查等操作的唯一入口，也是集群控制的入口進程
  • Kubernetes Controller Manager（kube-controller-manager）：Kubernetes 里所有資源對象的自動化控制中心
  • Kubernetes Scheduler（kube-scheduler）：負責資源調度（Pod 調度）的進程 此外在 Master 上通常還需要不是 etcd 服務，因為 Kubernetes 里的所有資源對象的數據都被保存在 etcd 中。Node Node 是 Kubernetes 集群中的工作負載的節點，每個 Node 都會被 Master 分配一些工作負載（docker 容器）。 在 Node 上運行著以下關鍵進程：
  • kubelet：負責 Pod 對應的容器的創建、啟停等任務，同時與 Master 密切協助，實現集群管理的基本功能
  • kube-proxy：實現 Kubernetes Service 的通訊與負載均衡機制的重要組件
  • Docker Engine（Docker）：Docker 引擎，負責本機的容器創建和管理工作

Pod

每個 Pod 都有一個特殊的被稱為「根容器」的 Pause 容器，除了 Pause 容器，每個 Pod 還包含一個或多個緊密相關的用戶業務容器。 Kubernetes 為每個 Pod 都分配了一個唯一的 IP 地址，稱之為 Pod IP，一個 Pod 里的多個容器共享 Pod IP 地址。 在 Kubernetes 里，一個 Pod 里的容器與另外主機上的 Pod 里的容器能夠直接通訊。 為什麼要有一個 Pause 容器？ 1.引入業務無關的且不易死亡的 Pause 容器作為 Pod 的根容器，以它的狀態代表整個容器組的狀態。 2.Pod 里的多個業務容器共享 Pause 容器的 IP，共享 Pause 容器掛載的 Volume，簡化了密切關聯的業務容器之間的通訊問題，也解決了他們之間的文件共享問題。

Label

Label（標籤）是 Kubernetes 系統中另外一個核心概念。一個 Label 是一個 key=value 的鍵值對，其中 key 與 value 由用戶自己指定。Label 可以被附加到各種資源對象上，例如 Node、Pod、Service、RC 等，一個資源對象可以定義任意數量的 Label ，同一個 Label 也可以被添加到任意數量的資源對象上。Label 通常在資源對象定義的時確定，也可以在對象創建後動態的添加或者刪除。

Replication Controller

RC 的定義包括以下幾個部分：

  • Pod 期待的副本數量
  • 用於篩選目標 Pod 的 Label Selector
  • 當 Pod 的副本數量小於預期數量時，用於創建新 Pod 的 Pod 模板（template） Replica Set 與 Deployment 這兩個重要的資源對象逐步替代了之前 RC 的作用。 RC(Replica Set)的一些特性與作用：
  • 在大多數的情況下，我們通過定義一個 RC 實現 Pod 的創建及副本數量的自動控制
  • 在 RC 里包括完成的 Pod 定義模板
  • RC 通過 Label Selector 機制實現對 Pod 副本的自動控制
  • 通過改變 RC 里的 Pod 副本數量，可以實現 Pod 的擴容和縮容
  • 通過改變 RC 里 Pod 模板中的鏡像版本，可以實現 Pod 的滾動升級

Deployment

Deployment 內部使用了 Replica Set 來實現目的。 Deployment 的典型使用場景有以下幾個：

  • 創建一個 Deployment 對象來生成對應的 Replica Set 並完成 Pod 副本的創建
  • 檢查 Deployment 的狀態來看部署動作是否完成（Pod 副本數量是否達到預期的值）
  • 更新 Deployment 以創建新的 Pod（比如鏡像升級）
  • 如果當前 Deployment 不穩定，則回滾到一個早先的 Deployment 版本
  • 暫停 Deployment 以便於一次性修改多個 PodTemplateSpec 的配置項，之後在恢復 Deployment ，進行先得發布
  • 擴展 Deployment 以應對高負載
  • 查看 Deployment 的狀態，以此作為發布是否成功的指標
  • 清理不再需要的舊版本 ReplicaSets

Horizontal Pod Autoscaler

Horizontal Pod Autoscaler（Pod 橫向自動擴容，HPA）通過追蹤分析指定 RC 控制的所有目標 Pod 的負載變化情況，來確定是否需要有針對性的調整目標 Pod 的副本數量。 HPA 有以下兩種方式作為 Pod 負載的度量指標：

  • CPUUtilizationPercenta
  • 應用程式自定義的度量指標，比如服務在每秒內的請求數（TPS 或 QPS)

StatefulSet

在 Kubernetes 系統中，Pod 的管理對象 RC、Deployment、DaemonSet 和 Job 都面向無狀態的服務。 StatefulSet 從本質上來說，可以看作 Deployment/RC 的一個特殊變種，它有如下特性：

  • StatefulSet 里的每個 Pod 都有穩定、唯一的網路標識，可以用來發現集群內的其他成員
  • StatefulSet 控制的 Pod 副本啟停順序是受控的，操作第 n 個 Pod 時，前 n-1 個 Pod 已經是運行且準備好的狀態
  • StatefulSet 里的 Pod 採用穩定的持久化存儲卷，通過 PV 或 PVC 來實現，刪除 Pod 時默認不會刪除與 StatefulSet 相關的存儲卷。

Service

Kubernetes 的 Service 定義了一個服務的訪問入口地址，每個 Service 都有唯一的 Cluster IP 及唯一的名稱。 Kubernetes 里的 3 種 IP:

  • Node IP: Node 的 IP 地址
  • Pod IP: Pod 的 IP 地址
  • Cluster IP: Service 的 IP 地址

Job

Job 控制一組 Pod 容器，Job 也是一種特殊的 Pod 副本自動控制器。Job 控制 Pod 副本與 RC 等控制器的工作機制有以下區別：

  1. Job 所控制的 Pod 副本是短暫運行的，可以將其視為一組 Docker 容器，其中每個 Docker 容器都僅運行一次。當 Job 控制的所有 Pod 副本都運行結束時，對應的 Job 也就結束了。Job 在實現方式上與 RC 等副本控制器不同，Job 生成的 Pod 副本是不能自動重啟的，對應 Pod 副本的 RestartPolicy 都被設置為 Never.
  2. Job 所控制的 Pod 副本的工作模式能夠多實例並行計算。

Volume

Volume 是 Pod 中能夠被多個容器訪問的共享目錄。 Kubernetes 提供了以下的 Volume 類型：

  1. emptyDir 一個 emptyDir Volume 是在 Pod 分配到 Node 的時創建的。他的初始內容為空，並且無需指定宿主機上對應的目錄文件。Kubernetes 自動分配一個目錄，當 Pod 從 Node 上面移除時， emptyDir 中的數據也會被永久刪除。emptyDir 的一些用途如下：
  • 臨時空間，例如某些程式運行時所需的臨時目錄
  • 長時間任務的中間過程 CheckPoint 的臨時保存目錄
  • 一個容器需要從另一個容器中獲取數據的目錄（多容器共享目錄）
  1. hostPath hostPath 為在 Pod 上掛載宿主機上的文件或目錄，通常用於以下幾個方面：
  • 容器應用程式生成的日誌文件需要永久保存時，可以使用宿主機的高速文件系統進行存儲
  • 需要訪問宿主機上 Docker 引擎內部數據結構的容器應用時，可以通過定義 hostPath 為宿主機 /var/lib/docker 目錄，使容器內部應用可以直接訪問 Docker 的文件系統 在使用 hostpath 時，需要注意以下幾點：
  • 在不同的 Node 上具有相同配置的 Pod，可能會因為宿主機上的目錄和文件不同而導致 Volume 上目錄和文件的訪問結果不一致
  • 如果使用了資源配額管理，則 Kubernetes 無法將 hostPath 在宿主機上使用的資源納入管理
  1. gcePersistentDisk 使用Google雲提供永久磁碟，當 Pod 被刪除時，PD 只是被卸載，不會被刪除。需要在Google雲環境中使用。
  2. awsElasticBlockStore 使用 AWS 提供的 EBS Volume 存儲數據，需要在 AWS 環境中使用。
  3. NFS 使用 NFS 網路文件系統提供共享目錄存儲數據。
  4. 其他類型的 Volume
  • iscsi: 使用 iSCSI 存儲設備上的目錄掛載到 Pod 中
  • flocker: 使用 Flocker 管理存儲卷
  • glusterfs: 使用開源 GlusterFS 網路文件系統的目錄掛載到 Pod 中
  • rbd: 使用 Ceph 塊設備共享存儲掛載到 Pod 中
  • gitRepo: 通過掛載一個空目錄，並從 Git 庫 clone 一個git repository 供 Pod 使用
  • secret: 一個 Secret Volume 用於為 Pod 提供加密的資訊，可以將定義在 Kubernetes 中的 Secret 直接掛載為文件讓 Pod 訪問。

Persistent Volume

PV 可以被理解成 Kubernetes 集群中的某個網路存儲對應的一塊存儲，它與 Volume 類似，但有以下區別。

  • PV 只能是網路存儲，不屬於任何 Node,但可以在每個 Node 上訪問
  • Pv 並不是定義在 Pod 上，而是獨立於 Pod 之外定義的
  • PV 目前支援的類型包括: gcePersistentDisk、awsElasticBlockStore、AzureFile、AzureDisk、FC、Flocker、NFC、iSCSI、RBD、CephFS、Cinder、GlusterFS、VsphereVolume、Quobyte Volumes、VMware Photon、Portworx Volumes、ScaleIO Volumes 和 hostPath（僅供單機測試）

PV 的 accessModes 屬性：

  • ReadWriteOnce: 讀寫許可權，並且只能被單個 Node 掛載
  • ReadOnlyMany: 只讀許可權，允許被多個 Node 掛載
  • ReadWriteMany: 讀寫許可權，允許被多個 Node 掛載

PV 的狀態：

  • Available：空閑狀態
  • Bound: 已經綁定到某個 PVC 上面
  • Released: 對應的 PVC 已經被刪除，但是資源還沒有被集群回收
  • Failed: PV 自動回收失敗

Namespace

Namespace 在很多情況下用於實現多租戶的資源隔離，可以給每個租戶創建一個 Namespace 來實現多租戶的資源隔離。

Annotation

Annotation 與 Label 類似，也使用 key/value 鍵值對的形式進行定義。不同的是 Label 就有嚴格的命名規則，它定義的是 Kubernetes 對象的元數據，並且用於 Label Selector。Annotation 則是用戶任意定義的附加資訊，以便於外部工具查找。Kubernetes 的模組自身會通過 Annotation 標記資源對象的一些特殊資訊。 通常來說，用 Annotation 來記錄的資訊如下：

  • build 資訊、release 資訊、Docker 鏡像資訊等，例如書簡戳、release id 號、PR 號、鏡像 Hash 值、Docker registry 地址等
  • 日誌庫、監控庫、分析庫等資源庫的資訊
  • 程式調試工具資訊，例如工具名稱、版本號等
  • 團隊的聯繫資訊，例如電話號碼、負責人名稱、網址等

ConfigMap

首先，把所有的配置項都當作 key-value 字元串，這些配置項可以作為 Map 表中的一個項，整個 Map 的數據可以被持久化存儲在 Kubernetes 的 Etcd 資料庫中，然後提供 API 以方便 Kubernetes 相關組件或客戶應用 CRUD 操作這些數據，上述專門用於保存配置參數的 Map 就是 Kubernetes ConfigMap 資源對象。 接下來，Kubernetes 提供了一種內建機制，將存儲在 etcd 中的 ConfigMap 通過 Volume 映射的方式變成目標 Pod 內的配置文件，不管 Pod 被調度到哪台伺服器上，都會完成自動映射。進一步地，如果 ConfigMap 中的 key-value 數據被修改，則映射到 Pod 中的「配置文件」也會隨之更新。

附錄

整理自 《Kubernetes 權威指南（第4版）》

VirMach 便宜 VPS

QNews

QNews