漫畫 | 小黃人學 Kubernetes 物件

Kubernetes中是有很多積木（Building Blocks），比如object model，pod，rs，deployment，namespace之類，這些都是Kubernetes中很重要的東西，學習Kubernetes，這些基礎必須要掌握理解。

Kubernetes叢集可以透過這個物件模型來表現出不同的持久化的整體，比如：

• 我們是在哪個node上執行哪個容器化的應用程式？

• 應用程式資源消耗

• 應用程式不同的策略

對於每個物件，我們用spec這個field宣告我們期望的狀態，Kubernetes會透過status這個field記錄物件實際的狀態並加以管理。隨後，Kubernetes的controller manager會想辦法讓這個物件實際的狀態和我們宣告期望的狀態相同。

我們一般用yaml格式檔案來宣告建立一個物件。

在建立一個物件時，我們需要把spec這個field提供給API Server，這個field會描述我們期望的狀態以及一些基礎的資訊，比如名稱。

建立物件的API請求必須有spec這個field以及其它詳細資訊，並且需要是JSON的格式。當我們用yaml格式提供一個物件的宣告後，kubectl會把這個宣告轉換成JSON格式，然後傳給API Server。

piVersion: apps/v1beta1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
    replicas: 3
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
             - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80

以上就是配置檔案宣告的Deployment物件：

apiVersion指定了我們呼叫的api的endpoint；

透過kind field，我們指定了我們要建立的物件的型別；

透過metadata，我們給物件附加上了最基本的資訊，比如名字；

你可能發現這裡面有兩個spec的field（spec和spec.template.spec），透過 spec，我們定義了我們對deployment的期望狀態，在我們的例子中，我們想要確認，在任何時候，都有至少3個pod在執行。我們再在spec.template.spec裡面定義我們要執行的每個pod都應該是什麼狀態，所以這就是為啥這裡會有兩個spec的原因。

一旦這個物件被建立了，kubernetes會直接給物件新增一個status的field，如下：

為什麼先介紹Pod呢，因為Pod是Kubernetes中最小的一個物件，你要執行的應用程式（web app等）都要被包含在Pod中才能執行，其中一個Pod是一個或者多個容器的邏輯上的集合，通俗來講，應用被製作成image映象，映象要執行在容器中，比如Docker容器，Pod中可以包涵多個執行的容器，所以在Kubernetes上沒有Pod，應用程式就沒有家。

在Pod中的容器擁有以下的特性：

• 在同一個host上一起進行排程

• 共享同一個network namespace

• 掛載同樣的external storage（volumes）

Pod並非一個持久化的東西，很有可能突然掛了，並且沒有能力自我修複，這就是為啥我們把它們和controller一起用，這樣可以來控制pod的replica，容錯，自我修複等等。比較有名的例子比如Deployments，ReplicaSets等。我們透過把Pod的定義（specification，也就是spec）附加到別的物件（也就是之前用的template.spec）來完成。

由於Docker容器之間通訊受到Docker網路機制限制，例如，一個應用需要多個容器組成，每個容器之間只需要Localhost通訊，這時如果這些容器都在一個Pod中，Localhost通訊就很方便實現了。這也是微服務流行起來原因了。

透過給物件打labels可以實現快速查詢某個物件，例如，有了label你可以確定這個Pod就是MySql，或者這組全是小黃人呀。

Labels都是由鍵值對錶示。

"labels": {
  "key1" : "value1",
  "key2" : "value2"
}

建立一個物件（如Pod）時可以直接給label，也可以在後期隨時修改，所以Labels一般被用來組織和選擇一些符合條件的物件。label不提供唯一性。

透過這個圖片，我們可以看到我們用了兩個label：app和env。基於我們的需求，我們可以給我們的pod不同的值。

當然是透過Label Selectors呢，透過Label Selectors，我們可以選擇一系列的物件，Kubernetes支援兩種Selector型別：

第一種：Equality-Based Selectors

顧名思義，這種selector透過 == 或者 != 來進行選擇，比如我們選擇一個 env==dev 的物件，就會找出所有有env label，並且值為dev的。

第二種：Set-Based Selectors

這種selector支援透過一系列的值來進行過濾，比如透過in, notin和exist。

舉例：env in (dev, qa)

效率瞬間提高呢，在管理Pod物件上，還有其他高效方法嗎？

當產品促銷，業務處於高峰或低峰時，我們經常需要擴容或縮容，為了實現自動化，Kubernetes增加相應處理物件。

像早期版本中的 ReplicationController，（RC）是master node上Controller Manager的一部分，主要作用是保證每個pod的replica都達到了預期值。不然的話會透過殺死或者新建pod的辦法來達到。不過現在已經被ReplicaSet(RS)取代了。

Replica Set 是下一代的Replication Controller，好處在於同時支援equality 和 set based selector（rc只支援equality-based）。目前這是唯一的區別。

ReplicaSets可以獨立使用，但它主要被 Deployments用作pod 機制的建立、刪除和更新。當使用Deployment時，你不必擔心建立pod的ReplicaSets，因為可以透過Deployment實現管理ReplicaSets。

Deployment提供了對於pod和rs的陳述性更新。DeploymentController是master node上Controller Manager的一部分，作用和Controller manager別的一樣——確保當前的狀態和期望的狀態相同。

在下麵這個例子中，我們的Deployment建立了一個 rs A，然後rs A又建立了3個pod，並且在每個pod中，都有一個跑了nginx:1.7.9映象的容器。

接下來，在下一個Deployment中，我們修改了pod的template，把nginx從1.7.9升級到了1.9.1。因為我們升級了期望的狀態，所以Deployment會建立一個新的RS B，這個過程被稱為Deployment rollout：

當RS B建立完畢的時候，Deployment開始指向它：

在RS之上，Deployment提供了很多特性比如recording，透過這個特性，如果說更新出錯，或者更新後的應用出了bug，我們可以rollback到原先的狀態。

試想下如果我們有許多個使用者，我們想把這些使用者組織到不同的team或者project，該怎麼辦？

這時我們可以透過Kubernetes中的Namespace，它能把kubernetes叢集分成好多個小叢集。所有在Namespace中建立的resources/objects都是唯一的，不會跨名稱空間，這樣是不是很方便呢。

一般來說，Kubernetes會有兩個預設Namespace：kube-system和default。kube-system一般會用來放一些Kubernetes系統的元件，default會用來放一些屬於其它Namespace的物件。我們預設情況下是會連線到default名稱空間。kube-public是一個特殊的namespace，可以被所有的使用者讀，一般用於特殊情況比如初始化一個叢集。

我們可以透過使用資源配額（Resource Quotas）來限制每個Namespace的資源。

今天我們介紹了Kubernetes物件模型，以及pod labels Deployment這幾個主要物件再Kubernetes中的用途、使用場景，後續咱們學習更多內容。

本文轉載自公眾號：K8S中文社群，點選檢視原文。

Kubernetes 實戰培訓

本次培訓內容包括：Docker容器的原理與基本操作；容器網路與儲存解析；Kubernetes的架構與設計理念詳解；Kubernetes的資源物件使用說明；Kubernetes 中的開放介面CRI、CNI、CSI解析；Kubernetes監控、網路、日誌管理；容器應用的開發流程詳解等，點選識別下方二維碼加微信好友瞭解具體培訓內容。

3月23日開始上課，點選閱讀原文連結即可報名。