雲計算虛擬化：一篇文章爲你圖解Kubernetes對象模型

摘要：舉個例子來說，比如我們要部署應用在8s集羣內，首先要我們的應用需要轉換爲K8s所能管理的實體對象如Pod。K8s對象模型概述-我們爲什麼要了解對象模型 K8s常見對象模型介紹-哪些對象模型可以爲我們所用 K8s對象模型的組織形式及yaml創建方法-我們該如何使用對象總結。

Kubernetes(以下簡寫爲K8s)的對象模型是K8s又一精巧的設計。我們知道，K8s所建立的容器化生態是複雜且多變的，而對象模型就是將一系列的資源實體抽象成K8s中所能識別的對象。爲了方便大家更全面的瞭解K8s的設計思想，本文對K8s的對象模型進行了梳理，同時在文章末尾增加了常見面試題問題彙總，章節內容分配如下：

K8s對象模型概述-我們爲什麼要了解對象模型 K8s常見對象模型介紹-哪些對象模型可以爲我們所用 K8s對象模型的組織形式及yaml創建方法-我們該如何使用對象總結

K8s對象模型概述-我們爲什麼要了解對象模型

這問題還用想?存在即合理唄。那咱們就先來看看他爲什麼存在。

在官方文檔中，對K8s的對象模型有這樣的定義：

“在 Kubernetes 系統中，Kubernetes 對象是持久化的實體。Kubernetes 使用這些實體去表示整個集羣的狀態。特別地，它們描述瞭如下信息：

哪些容器化應用在運行(以及在哪個 Node 上) 可以被應用使用的資源關於應用運行時表現的策略，比如重啓策略、升級策略，以及容錯策略”

簡單說來，對象模型主要有兩點目標：

1.服務於K8s集羣

對象模型一個功能是用以抽象化描述K8s集羣狀態，實體及實體間關聯。此類的代表就是Label，它建立集羣對象之間的靈活、松耦合的多維關聯關係，我們可以用通過lable selector 查詢和篩選建立對象間的關係的。

2.服務於用戶。

K8s提供多種抽象對象便於用戶部署自己的應用到集羣中，這些抽象對象爲用戶屏蔽了複雜的底層邏輯，讓用戶更專注於如何去使用。此類的例子就比較多，比如Pod，Node，Deployment等。舉個例子來說，比如我們要部署應用在8s集羣內，首先要我們的應用需要轉換爲K8s所能管理的實體對象如Pod;對於多副本應用，我們需要考慮進行統一的管理，可以考慮如Deployment;進一步考慮副本間的負載均衡和服務發現，我們又可以考慮採用Service來實現，用戶無需關注其內部實現，從而更專注於自身的應用。

K8s常見對象模型-哪些對象模型可以爲我們所用

既然把K8s對象模型吹得這麼神，那得看看他是不是真有這麼神。下面來一起看看K8s常見的對象。

這裏再用一幅圖來更形象地介紹各個對象在K8s中的所處位置。

可以看到Deployment對象的Spec和Status描述結構。

再說yaml，對於不同的對象而言，yaml配置的內容有所不同，但以下幾項是必選：

apiVersion # 創建該對象所使用的 Kubernetes API 的版本 kind # 想要創建的對象的類型 metadata # 識別對象唯一性的數據，包括一個 name 字符串、UID 和可選的 namespace

https://kubernetes.io/docs/api/)。下面我們對各資源的創建方式進行舉例：

Workload類對象

Pod類資源我們使用經典案例——busybox的創建模板進行簡述：

這則模板中首先指定了yaml的三要素，apiVersion、kind、metadata。在Pod特有的spec中指定了所需的鏡像busybox，並簡單設置了鏡像拉取和容器重啓的策略。在使用過程中我們會發現，簡單的配置後，因鏡像拉取或容器重啓帶來的異常管理問題，K8s都會幫你自動完成，也就是之前提到的對象的實際狀態以與我們所期望的狀態相匹配。

再舉一個例子，經典的nginx模板用例：

Deployment用以描述一類Pod集合，因此這裏指定了副本數，並設置了selector來簡歷Pod與Deployment的關係。

Discovery&Loadbalance類對象

這一類資源代表具備網絡特性的對象，其中的代表對象就是Service，這裏我們也列舉一個Service的經典用例加以說明。

Service對象的yaml模板裏，我們可以指定一個或一組Pod的通信端口及通信協議，並制定服務的暴露方式。

Config&Storage類對象

Configmap作爲非持久化存儲的代表，我們先舉一個例子來說明：

Configmap的部署用例沒有spec域，直接指定了數據的內容。除了以上使用yaml方式創建外，當我們將 ConfigMap 或者 Secret 包裝成卷並掛載到某個目錄時，我們其實是在創建 Volume，這些 Volume 並不是 Kubernetes 中的對象，它們只存在於當前 Pod 中，隨着 Pod 的刪除而刪除，但是需要注意的是這些臨時的Volume的刪除並不會導致相關 ConfigMap 或者 Secret 對象的刪除。

我們再舉持久化存儲的例子。

持久化存儲的創建用例和Pod對象有些類似，需要制定存儲的預期狀態，這裏設置了一個容量爲1G，以可讀可寫方式掛載到多個節點，並使用nfs掛載的PV存儲。這樣在創建完成後，就可以使用PVC在Pod進行存儲綁定了。

Cluster類對象

Cluster類對象多數屬於集羣集羣資源對象，默認可不需要用戶自己使用yaml創建，比如namespace就可以直接使用命令 kubectl create ns **** 來創建。這裏我們舉一個ClusterRole的yaml例子。

在這個例子中，我們定義了一個ClusterRole的對象，它可以授予對secrets資源對象的get,watch,list權限。接來下我們就是用ClusterRoleBinding來使用它。ClusterRoleBinding可以將角色中定義的權限授予用戶或用戶組，ClusterRoleBinding包含一組權限列表(subjects)，權限列表中包含有不同形式的待授予權限資源類型(如USER，GROUP，SERVICEACCOUNT)，ClusterRoleBinding適用於集羣範圍內的授權，與之相對應的RoleBinding適用於某個命名空間內授權。舉例說明：