Chapter 8. Kubernetes Building Blocks
Introduction and Learning Objectives
在本章中，我們將探討Kubernetes對象模型，並討論它的一些基本構建塊，如Pods、ReplicaSets、Deployments、Namespaces等。我們還將討論Labels和Selectors在微服務驅動的體系結構中扮演的重要角色，因為它們將分離的對象組合在一起。
Kubernetes Building Blocks
Kubernetes Object Model
Kubernetes有一個非常豐富的對象模型，表示Kubernetes集群中不同的持久實體。這些實體描述：
- 我們在哪個節點上運行哪些容器化應用程序
- 應用程序資源消耗情況
- 附加到應用程序的不同策略，如重新啟動/升級策略、容錯等。對於每個對象，我們在spec部分聲明我們的意圖或期望的狀態。Kubernetes系統管理對象的status部分，其中記錄了對象的實際狀態。在任何給定的時間點上，Kubernetes控制平臺都會嘗試將對象的實際狀態與對象的期望狀態相匹配。
Kubernetes對象有Pods、ReplicaSets、Deployments、Namespaces等，我們將在下一步對它們進行探討。
創建對象時，必須將spec字段下面對象的配置數據部分提交給Kubernetes API Server。spec部分描述了目標狀態以及一些基本信息，比如對象的名稱。創建對象的API請求必須包含spec部分以及其他詳細信息。儘管API服務器接受JSON格式的對象定義文件，但我們通常以YAML格式提供這些文件，kubectl將這些文件轉成JSON並將其發送到API服務器。
下面是YAML格式的部署對象配置示例：
<code>apiVersion: apps/v1kind: Deploymentmetadata: name: nginx-deployment labels: app: nginxspec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.15.11 ports: - containerPort: 80/<code>
apiVersion是第一個必填字段，它指定API服務器上的我們想要連接到的API端點，它必須與已定義的對象類型的現有版本匹配。第二個必需字段是kind，指定對象類型——在我們的示例中是Deployment，但它可以是Pod、Replicaset、Namespace、Service等。第三個必需字段metadata保存對象的基本信息，如name, labels, namespace等。我們的示例顯示了兩個spec字段（spec和spec.template.spec）。第四個必需的字段spec標記定義部署對象所需狀態的塊的開始。在我們的例子中，我們希望在任何給定的時間確保運行3個pod。Pods是使用spec.Template中定義的Pods模板創建的。嵌套的對象（如作為部署一部分的Pod）將保留其metadata和spec，但去掉apiVersion和kind——兩者都將被template替換。在spec.template.spec中，我們定義了Pod的期望狀態。我們的Pod創建了一個運行來自Docker Hub的nginx:1.15.11鏡像的容器。一旦創建了部署對象，Kubernetes系統就會將status字段附加到該對象；我們稍後將對其進行研究。接下來，我們將更深入地研究一些Kubernetes對象以及其他組成部分。
Pods
Pod是最小最簡單的Kubernetes對象。它是Kubernetes中的部署單元，表示應用程序的單個實例。Pod是一個或多個容器的邏輯集合，容器有如下特點：
- 一個/多個Container與Pod編排在同一主機上
- 共享相同的網絡命名空間
- 訪問相同的外部存儲（卷）。
Pods是一個或多個容器的集合
事實上Pod是短暫的，它們沒有自我恢復能力。這就是為什麼它們需要與處理Pod的複製、容錯、恢復等的控制器一起使用。控制器有Deployments, ReplicaSets, ReplicationControllers等。我們使用Pod模板將嵌套Pod的spec附加到控制器對象，如前一節所示。
下面是YAML格式的Pod對象配置示例：
<code>apiVersion: v1kind: Podmetadata: name: nginx-pod labels: app: nginxspec: containers: - name: nginx image: nginx:1.15.11 ports: - containerPort: 80/<code>
apiVersion字段為Pod對象定義指定"v1"。第二個必需字段是指定Pod對象類型的kind。第三個必需的字段元數據包含對象的名稱和標籤。第四個必需的字段spec定義Pod對象所需狀態，也稱為Pod spec。我們的Pod創建了一個運行來自Docker Hub的nginx:1.15.11 鏡像的容器。
Labels
Label是附加到Kubernetes對象（例如Pods、ReplicaSets）的鍵值對。標籤用於根據現有需求組織和選擇對象的子集。許多對象可以具有相同的標籤。標籤不能為對象提供唯一性。控制器使用標籤將分離的對象邏輯地組合在一起，而不是使用對象的名稱或id。
在上圖中，我們使用了兩個Label的Key：app和env。根據我們的要求，我們給了四個吊艙不同的價值。Label env=dev在邏輯上選擇並分組前兩個pod，而Lable app=frontend在邏輯上選擇並分組左兩個pod。我們可以從左下角的四個pod中選擇一個，方法是使用兩個標籤：app=frontend和env=qa。
Label Selectors
Controllers使用標籤選擇器選擇對象的子集。Kubernetes支持兩種類型的選擇器：
- 基於等式的選擇器基於相等的選擇器允許基於標籤鍵和值篩選對象。使用=，（等於，可替換使用）或！=（不等於）運算符實現匹配。例如，對於envdev或env=dev，我們選擇env Label鍵設置為value dev的對象。
- 基於集合的選擇器基於集合的選擇器允許基於一組值篩選對象。我們可以使用In，NOTIN操作符中篩選標籤Value，以及用exist/not exist操作符篩選標籤的Key。例如，使用env in（dev，qa），我們選擇env標籤設置為dev或qa的對象; !app選擇沒有標籤app的對象應用程序。
ReplicationControllers
雖然不再推薦，但ReplicationController是一種控制器，它可以用於確保在任何給定時間運行指定數量的Pod副本。如果pod多於所需數量，則ReplicationController將終止額外的pod；如果pod較少，則複製控制器將創建更多的pod以匹配所需數量。通常，我們不會獨立部署Pod，因為如果因為錯誤終止，它將無法自己重新啟動。推薦的方法是使用某種類型的ReplicationController來創建和管理pod。默認控制器是一個Deployment ，它將配置ReplicaSet 為管理Pods的生命週期。
ReplicaSets I
ReplicaSet是下一代複製控制器。replicationset支持基於等式和集合的選擇器，而replicationcontroller只支持基於等式的選擇器。目前，這是唯一的區別。在ReplicaSet的幫助下，我們可以擴展運行特定容器應用程序映像的pod的數量。縮放可以手動完成，也可以通過使用autoscaler完成。接下來，您可以看到一個replicaSet的圖形表示，我們將Pod的replicas count設置為3。
ReplicaSets II
現在，讓我們繼續同一個示例，假設其中一個pod被強制終止（由於資源不足、超時等），並且當前狀態不再與所需狀態匹配。
ReplicaSets III
ReplicaSet將檢測到當前狀態不再與所需狀態匹配。ReplicaSet將創建一個額外的Pod，從而確保當前狀態與所需狀態匹配。
ReplicaSet可以獨立用作Pod控制器，但它們只提供有限的一組功能。Deployment提供了一組補充功能，這是pod編排的推薦控制器。Deployment管理pod的創建、刪除和更新。Deployment會自動創建一個ReplicaSet，然後創建一個Pod。不需要單獨管理ReplicaSet和pod，Deployment將代表我們管理它們。下一步我們將更仔細地研究Deployment。
Deployments I
Deployment對象為pod和ReplicaSet提供聲明性更新。DeploymentController是master node的控制器管理器的一部分，它確保當前狀態始終與所需狀態匹配。它允許通過rollouts和rollbacks無縫地更新和降級應用程序，並直接管理其ReplicaSet以進行應用程序擴展。在下面的示例中，一個新的Deployment創建了ReplicaSet A，然後它創建了3個Pod，每個Pod模板配置為運行一個nginx:1.7.9容器映像。在本例中，ReplicaSetA與nginx:1.7.9相關聯，nginx:1.7.9表示部署的狀態。此特定狀態記錄為修訂版1。
Deployments II
現在，在Deployment中，我們更改了Pods的Template，並將容器映像從nginx:1.7.9更新為nginx:1.9.1。部署為1.9.1版本的新容器映像觸發新的ReplicaSet B，此關聯表示部署的新記錄狀態，版本2。這兩個ReplicaSet之間的無縫轉換是Deployment滾動更新，從帶有3個Pods版本1.7.9的ReplicaSet A到帶有3個Pods版本1.9.1的新ReplicaSet B，或者說從修訂版1到修訂版2。當我們為Deployment更新Pods Template時，會觸發滾動更新。scaling或labeling等操作不會觸發滾動更新，因此不會更改修訂號。一旦滾動更新完成，Deployment將同時顯示ReplicaSets A和B，其中A被縮放為0 pod，B被縮放為3 pod。這就是Deployment如何將其先前的狀態配置設置記錄為修訂版的方式。
Deployments III
一旦ReplicaSet B及其版本為1.9.1的3個Pods準備就緒，Deployments就開始積極地管理它們。但是，Deployment將其先前的配置狀態保存為歷史修訂版，修訂版在Deployment的回滾功能中起著關鍵作用—返回到先前已知的配置狀態。在我們的示例中，如果新nginx:1.9.1的性能不令人滿意，則可以將部署回滾到以前的版本，在本例中，從版本2回滾到運行nginx:1.7.9的版本1。
Namespaces
如果多個用戶和團隊使用同一個Kubernetes集群，我們可以使用名稱空間將集群劃分為虛擬子集群。在命名空間中創建的資源/對象的名稱是唯一的，但在群集中的命名空間中不是唯一的。要列出所有命名空間，可以運行以下命令：
<code>$ kubectl get namespacesNAME STATUS AGEdefault Active 11hkube-node-lease Active 11hkube-public Active 11hkube-system Active 11h/<code>
通常，Kubernetes創建四個默認名稱空間：kube system、kube public、kube node lease和default。kube system名稱空間包含由Kubernetes系統創建的對象，主要是控制平面代理。default命名空間包含管理員和開發人員創建的對象和資源。默認情況下，我們連接到default命名空間。kube public是一個特殊的名稱空間，任何人都可以對其進行安全和可讀，用於特殊目的，例如公開集群的公共（非敏感）信息。最新的名稱空間是kube node lease，它保存用於節點心跳數據的節點租約對象。然而，好的做法是創建更多的名稱空間來為用戶和開發團隊虛擬化集群。通過Resource Quotas，我們可以在名稱空間內劃分集群資源。我們將在未來的一章中簡要介紹Resource Quotas。
Deployment Rolling Update and Rollback (Demo)
閱讀更多 一直溫柔 的文章
