Chapter 8. Kubernetes Building Blocks

Introduction and Learning Objectives

在本章中，我們將探討Kubernetes對(duì)象模型，并討論它的一些基本構(gòu)建塊，如Pods、ReplicaSets、Deployments、Namespaces等。我們還將討論Labels和Selectors在微服務(wù)驅(qū)動(dòng)的體系結(jié)構(gòu)中扮演的重要角色，因?yàn)樗鼈儗⒎蛛x的對(duì)象組合在一起。

Kubernetes Building Blocks

Kubernetes Object Model

Kubernetes有一個(gè)非常豐富的對(duì)象模型，表示Kubernetes集群中不同的持久實(shí)體。這些實(shí)體描述：

• 我們?cè)谀膫€(gè)節(jié)點(diǎn)上運(yùn)行哪些容器化應(yīng)用程序
• 應(yīng)用程序資源消耗情況
• 附加到應(yīng)用程序的不同策略，如重新啟動(dòng)/升級(jí)策略、容錯(cuò)等。對(duì)于每個(gè)對(duì)象，我們?cè)趕pec部分聲明我們的意圖或期望的狀態(tài)。Kubernetes系統(tǒng)管理對(duì)象的status部分，其中記錄了對(duì)象的實(shí)際狀態(tài)。在任何給定的時(shí)間點(diǎn)上，Kubernetes控制平臺(tái)都會(huì)嘗試將對(duì)象的實(shí)際狀態(tài)與對(duì)象的期望狀態(tài)相匹配。

Kubernetes對(duì)象有Pods、ReplicaSets、Deployments、Namespaces等，我們將在下一步對(duì)它們進(jìn)行探討。

創(chuàng)建對(duì)象時(shí)，必須將spec字段下面對(duì)象的配置數(shù)據(jù)部分提交給Kubernetes API Server。spec部分描述了目標(biāo)狀態(tài)以及一些基本信息，比如對(duì)象的名稱。創(chuàng)建對(duì)象的API請(qǐng)求必須包含spec部分以及其他詳細(xì)信息。盡管API服務(wù)器接受JSON格式的對(duì)象定義文件，但我們通常以YAML格式提供這些文件，kubectl將這些文件轉(zhuǎn)成JSON并將其發(fā)送到API服務(wù)器。

下面是YAML格式的部署對(duì)象配置示例：

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

apiVersion是第一個(gè)必填字段，它指定API服務(wù)器上的我們想要連接到的API端點(diǎn)，它必須與已定義的對(duì)象類型的現(xiàn)有版本匹配。第二個(gè)必需字段是kind，指定對(duì)象類型——在我們的示例中是Deployment，但它可以是Pod、Replicaset、Namespace、Service等。第三個(gè)必需字段metadata保存對(duì)象的基本信息，如name, labels, namespace等。我們的示例顯示了兩個(gè)spec字段（spec和spec.template.spec）。第四個(gè)必需的字段spec標(biāo)記定義部署對(duì)象所需狀態(tài)的塊的開始。在我們的例子中，我們希望在任何給定的時(shí)間確保運(yùn)行3個(gè)pod。Pods是使用spec.Template中定義的Pods模板創(chuàng)建的。嵌套的對(duì)象（如作為部署一部分的Pod）將保留其metadata和spec，但去掉apiVersion和kind——兩者都將被template替換。在spec.template.spec中，我們定義了Pod的期望狀態(tài)。我們的Pod創(chuàng)建了一個(gè)運(yùn)行來自Docker Hub的nginx:1.15.11鏡像的容器。一旦創(chuàng)建了部署對(duì)象，Kubernetes系統(tǒng)就會(huì)將status字段附加到該對(duì)象；我們稍后將對(duì)其進(jìn)行研究。接下來，我們將更深入地研究一些Kubernetes對(duì)象以及其他組成部分。

Pods

Pod是最小最簡(jiǎn)單的Kubernetes對(duì)象。它是Kubernetes中的部署單元，表示應(yīng)用程序的單個(gè)實(shí)例。Pod是一個(gè)或多個(gè)容器的邏輯集合，容器有如下特點(diǎn)：

• 一個(gè)/多個(gè)Container與Pod編排在同一主機(jī)上
• 共享相同的網(wǎng)絡(luò)命名空間
• 訪問相同的外部存儲(chǔ)（卷）。

Pods是一個(gè)或多個(gè)容器的集合

事實(shí)上Pod是短暫的，它們沒有自我恢復(fù)能力。這就是為什么它們需要與處理Pod的復(fù)制、容錯(cuò)、恢復(fù)等的控制器一起使用?？刂破饔蠨eployments, ReplicaSets, ReplicationControllers等。我們使用Pod模板將嵌套Pod的spec附加到控制器對(duì)象，如前一節(jié)所示。

下面是YAML格式的Pod對(duì)象配置示例：

apiVersion: v1kind: Podmetadata:  name: nginx-pod  labels:    app: nginxspec:  containers:  - name: nginx    image: nginx:1.15.11    ports:    - containerPort: 80

apiVersion字段為Pod對(duì)象定義指定"v1"。第二個(gè)必需字段是指定Pod對(duì)象類型的kind。第三個(gè)必需的字段元數(shù)據(jù)包含對(duì)象的名稱和標(biāo)簽。第四個(gè)必需的字段spec定義Pod對(duì)象所需狀態(tài)，也稱為Pod spec。我們的Pod創(chuàng)建了一個(gè)運(yùn)行來自Docker Hub的nginx:1.15.11 鏡像的容器。

Labels

Label是附加到Kubernetes對(duì)象（例如Pods、ReplicaSets）的鍵值對(duì)。標(biāo)簽用于根據(jù)現(xiàn)有需求組織和選擇對(duì)象的子集。許多對(duì)象可以具有相同的標(biāo)簽。標(biāo)簽不能為對(duì)象提供唯一性。控制器使用標(biāo)簽將分離的對(duì)象邏輯地組合在一起，而不是使用對(duì)象的名稱或id。

在上圖中，我們使用了兩個(gè)Label的Key：app和env。根據(jù)我們的要求，我們給了四個(gè)吊艙不同的價(jià)值。Label env=dev在邏輯上選擇并分組前兩個(gè)pod，而Lable app=frontend在邏輯上選擇并分組左兩個(gè)pod。我們可以從左下角的四個(gè)pod中選擇一個(gè)，方法是使用兩個(gè)標(biāo)簽：app=frontend和env=qa。

Label Selectors

Controllers使用標(biāo)簽選擇器選擇對(duì)象的子集。Kubernetes支持兩種類型的選擇器：

• 基于等式的選擇器基于相等的選擇器允許基于標(biāo)簽鍵和值篩選對(duì)象。使用=，（等于，可替換使用）或！=（不等于）運(yùn)算符實(shí)現(xiàn)匹配。例如，對(duì)于envdev或env=dev，我們選擇env Label鍵設(shè)置為value dev的對(duì)象。
• 基于集合的選擇器基于集合的選擇器允許基于一組值篩選對(duì)象。我們可以使用In，NOTIN操作符中篩選標(biāo)簽Value，以及用exist/not exist操作符篩選標(biāo)簽的Key。例如，使用env in（dev，qa），我們選擇env標(biāo)簽設(shè)置為dev或qa的對(duì)象; !app選擇沒有標(biāo)簽app的對(duì)象應(yīng)用程序。

ReplicationControllers

雖然不再推薦，但ReplicationController是一種控制器，它可以用于確保在任何給定時(shí)間運(yùn)行指定數(shù)量的Pod副本。如果pod多于所需數(shù)量，則ReplicationController將終止額外的pod；如果pod較少，則復(fù)制控制器將創(chuàng)建更多的pod以匹配所需數(shù)量。通常，我們不會(huì)獨(dú)立部署Pod，因?yàn)槿绻驗(yàn)殄e(cuò)誤終止，它將無法自己重新啟動(dòng)。推薦的方法是使用某種類型的ReplicationController來創(chuàng)建和管理pod。默認(rèn)控制器是一個(gè)Deployment ，它將配置ReplicaSet 為管理Pods的生命周期。

ReplicaSets I

ReplicaSet是下一代復(fù)制控制器。replicationset支持基于等式和集合的選擇器，而replicationcontroller只支持基于等式的選擇器。目前，這是唯一的區(qū)別。在ReplicaSet的幫助下，我們可以擴(kuò)展運(yùn)行特定容器應(yīng)用程序映像的pod的數(shù)量。縮放可以手動(dòng)完成，也可以通過使用autoscaler完成。接下來，您可以看到一個(gè)replicaSet的圖形表示，我們將Pod的replicas count設(shè)置為3。

ReplicaSets II

現(xiàn)在，讓我們繼續(xù)同一個(gè)示例，假設(shè)其中一個(gè)pod被強(qiáng)制終止（由于資源不足、超時(shí)等），并且當(dāng)前狀態(tài)不再與所需狀態(tài)匹配。

ReplicaSets III

ReplicaSet將檢測(cè)到當(dāng)前狀態(tài)不再與所需狀態(tài)匹配。ReplicaSet將創(chuàng)建一個(gè)額外的Pod，從而確保當(dāng)前狀態(tài)與所需狀態(tài)匹配。

ReplicaSet可以獨(dú)立用作Pod控制器，但它們只提供有限的一組功能。Deployment提供了一組補(bǔ)充功能，這是pod編排的推薦控制器。Deployment管理pod的創(chuàng)建、刪除和更新。Deployment會(huì)自動(dòng)創(chuàng)建一個(gè)ReplicaSet，然后創(chuàng)建一個(gè)Pod。不需要單獨(dú)管理ReplicaSet和pod，Deployment將代表我們管理它們。下一步我們將更仔細(xì)地研究Deployment。

Deployments I

Deployment對(duì)象為pod和ReplicaSet提供聲明性更新。DeploymentController是master node的控制器管理器的一部分，它確保當(dāng)前狀態(tài)始終與所需狀態(tài)匹配。它允許通過rollouts和rollbacks無縫地更新和降級(jí)應(yīng)用程序，并直接管理其ReplicaSet以進(jìn)行應(yīng)用程序擴(kuò)展。在下面的示例中，一個(gè)新的Deployment創(chuàng)建了ReplicaSet A，然后它創(chuàng)建了3個(gè)Pod，每個(gè)Pod模板配置為運(yùn)行一個(gè)nginx:1.7.9容器映像。在本例中，ReplicaSetA與nginx:1.7.9相關(guān)聯(lián)，nginx:1.7.9表示部署的狀態(tài)。此特定狀態(tài)記錄為修訂版1。

Deployments II

現(xiàn)在，在Deployment中，我們更改了Pods的Template，并將容器映像從nginx:1.7.9更新為nginx:1.9.1。部署為1.9.1版本的新容器映像觸發(fā)新的ReplicaSet B，此關(guān)聯(lián)表示部署的新記錄狀態(tài)，版本2。這兩個(gè)ReplicaSet之間的無縫轉(zhuǎn)換是Deployment滾動(dòng)更新，從帶有3個(gè)Pods版本1.7.9的ReplicaSet A到帶有3個(gè)Pods版本1.9.1的新ReplicaSet B，或者說從修訂版1到修訂版2。當(dāng)我們?yōu)镈eployment更新Pods Template時(shí)，會(huì)觸發(fā)滾動(dòng)更新。scaling或labeling等操作不會(huì)觸發(fā)滾動(dòng)更新，因此不會(huì)更改修訂號(hào)。一旦滾動(dòng)更新完成，Deployment將同時(shí)顯示ReplicaSets A和B，其中A被縮放為0 pod，B被縮放為3 pod。這就是Deployment如何將其先前的狀態(tài)配置設(shè)置記錄為修訂版的方式。

Deployments III

一旦ReplicaSet B及其版本為1.9.1的3個(gè)Pods準(zhǔn)備就緒，Deployments就開始積極地管理它們。但是，Deployment將其先前的配置狀態(tài)保存為歷史修訂版，修訂版在Deployment的回滾功能中起著關(guān)鍵作用—返回到先前已知的配置狀態(tài)。在我們的示例中，如果新nginx:1.9.1的性能不令人滿意，則可以將部署回滾到以前的版本，在本例中，從版本2回滾到運(yùn)行nginx:1.7.9的版本1。

Namespaces

如果多個(gè)用戶和團(tuán)隊(duì)使用同一個(gè)Kubernetes集群，我們可以使用名稱空間將集群劃分為虛擬子集群。在命名空間中創(chuàng)建的資源/對(duì)象的名稱是唯一的，但在群集中的命名空間中不是唯一的。要列出所有命名空間，可以運(yùn)行以下命令：

$ kubectl get namespacesNAME              STATUS       AGEdefault           Active       11hkube-node-lease   Active       11hkube-public       Active       11hkube-system       Active       11h

通常，Kubernetes創(chuàng)建四個(gè)默認(rèn)名稱空間：kube system、kube public、kube node lease和default。kube system名稱空間包含由Kubernetes系統(tǒng)創(chuàng)建的對(duì)象，主要是控制平面代理。default命名空間包含管理員和開發(fā)人員創(chuàng)建的對(duì)象和資源。默認(rèn)情況下，我們連接到default命名空間。kube public是一個(gè)特殊的名稱空間，任何人都可以對(duì)其進(jìn)行安全和可讀，用于特殊目的，例如公開集群的公共（非敏感）信息。最新的名稱空間是kube node lease，它保存用于節(jié)點(diǎn)心跳數(shù)據(jù)的節(jié)點(diǎn)租約對(duì)象。然而，好的做法是創(chuàng)建更多的名稱空間來為用戶和開發(fā)團(tuán)隊(duì)虛擬化集群。通過Resource Quotas，我們可以在名稱空間內(nèi)劃分集群資源。我們將在未來的一章中簡(jiǎn)要介紹Resource Quotas。

Deployment Rolling Update and Rollback (Demo)