久久综合给合久久狠狠狠974色|亚洲成熟丰满熟妇高潮xxxxx|国产又黄又黄又大又粗又爽的视频|日韩久久久精品无码一区二区三区|中文字幕无码乱人伦一区二区三区|国产成人无码区免费内射一片色欲|亚洲av无码久久精品一区二区三区

edx-LFS158x Kubernetes學(xué)習筆記(第八章)

2020-03-28 07:47:29  閱讀:-  來(lái)源:

Chapter 8. Kubernetes Building Blocks

Introduction and Learning Objectives

在本章中,我們將探討Kubernetes對象模型,并討論它的一些基本構建塊,如Pods、ReplicaSets、Deployments、Namespaces等。我們還將討論Labels和Selectors在微服務(wù)驅動(dòng)的體系結構中扮演的重要角色,因為它們將分離的對象組合在一起。

Kubernetes Building Blocks

Kubernetes Object Model

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

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

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

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

下面是YAML格式的部署對象配置示例:

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

Pods

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

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


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


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

下面是YAML格式的Pod對象配置示例:

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

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

Labels

Label是附加到Kubernetes對象(例如Pods、ReplicaSets)的鍵值對。標簽用于根據現有需求組織和選擇對象的子集。許多對象可以具有相同的標簽。標簽不能為對象提供唯一性??刂破魇褂脴撕瀸⒎蛛x的對象邏輯地組合在一起,而不是使用對象的名稱(chēng)或id。


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

Label Selectors

Controllers使用標簽選擇器選擇對象的子集。Kubernetes支持兩種類(lèi)型的選擇器:

  • 基于等式的選擇器基于相等的選擇器允許基于標簽鍵和值篩選對象。使用=,(等于,可替換使用)或!=(不等于)運算符實(shí)現匹配。例如,對于envdev或env=dev,我們選擇env Label鍵設置為value dev的對象。
  • 基于集合的選擇器基于集合的選擇器允許基于一組值篩選對象。我們可以使用In,NOTIN操作符中篩選標簽Value,以及用exist/not exist操作符篩選標簽的Key。例如,使用env in(dev,qa),我們選擇env標簽設置為dev或qa的對象; !app選擇沒(méi)有標簽app的對象應用程序。


ReplicationControllers

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

ReplicaSets I

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


ReplicaSets II

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


ReplicaSets III

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


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

Deployments I

Deployment對象為pod和ReplicaSet提供聲明性更新。DeploymentController是master node的控制器管理器的一部分,它確保當前狀態(tài)始終與所需狀態(tài)匹配。它允許通過(guò)rollouts和rollbacks無(wú)縫地更新和降級應用程序,并直接管理其ReplicaSet以進(jìn)行應用程序擴展。在下面的示例中,一個(gè)新的Deployment創(chuàng )建了ReplicaSet A,然后它創(chuàng )建了3個(gè)Pod,每個(gè)Pod模板配置為運行一個(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

現在,在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之間的無(wú)縫轉換是Deployment滾動(dòng)更新,從帶有3個(gè)Pods版本1.7.9的ReplicaSet A到帶有3個(gè)Pods版本1.9.1的新ReplicaSet B,或者說(shuō)從修訂版1到修訂版2。當我們?yōu)镈eployment更新Pods Template時(shí),會(huì )觸發(fā)滾動(dòng)更新。scaling或labeling等操作不會(huì )觸發(fā)滾動(dòng)更新,因此不會(huì )更改修訂號。一旦滾動(dòng)更新完成,Deployment將同時(shí)顯示ReplicaSets A和B,其中A被縮放為0 pod,B被縮放為3 pod。這就是Deployment如何將其先前的狀態(tài)配置設置記錄為修訂版的方式。


Deployments III

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


Namespaces

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

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

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

Deployment Rolling Update and Rollback (Demo)

丽水市| 阿拉善右旗| 瓦房店市| 华坪县| 内乡县| 丰镇市| 句容市| 太白县| 龙里县| 嘉义市| 秦安县| 集安市| 奉贤区| 富锦市| 巩义市| 祥云县| 浦城县| 河北省| 屏东市| 山阳县| 江孜县| 葵青区| 清镇市| 肃宁县| 疏勒县| 大石桥市| 保定市| 杭州市| 玛曲县| 汉寿县| 乌审旗| 定结县| 城口县| 万山特区| 屯门区| 抚州市| 伊春市| 临泽县| 将乐县| 凤凰县| 青龙|