溫馨提示×
您好，登錄后才能下訂單哦！
點(diǎn)擊 登錄注冊(cè) 即表示同意《億速云用戶服務(wù)條款》
您好，登錄后才能下訂單哦！
作者| 阿里巴巴資深技術(shù)專家、CNCF 9個(gè) TCO 之一 李響
Kubernetes，從官方網(wǎng)站上可以看到，它是一個(gè)工業(yè)級(jí)的容器編排平臺(tái)。Kubernetes 這個(gè)單詞是希臘語(yǔ)，它的中文翻譯是“舵手”或者“飛行員”。在一些常見的資料中也會(huì)看到“ks”這個(gè)詞，也就是“K8s”，它是通過將 8 個(gè)字母“ubernete ”替換為“8”而導(dǎo)致的一個(gè)縮寫。
Kubernetes 為什么要用“舵手”來(lái)命名呢？大家可以看一下這張圖：
這是一艘載著一堆集裝箱的輪船，輪船在大海上運(yùn)著集裝箱奔波，把集裝箱送到它們?cè)撊サ牡胤?。我們之前其?shí)介紹過一個(gè)概念叫做 container，container 這個(gè)英文單詞也有另外的一個(gè)意思就是“集裝箱”。Kubernetes 也就借著這個(gè)寓意，希望成為運(yùn)送集裝箱的一個(gè)輪船，來(lái)幫助我們管理這些集裝箱，也就是管理這些容器。
這個(gè)就是為什么會(huì)選用 Kubernetes 這個(gè)詞來(lái)代表這個(gè)項(xiàng)目的原因。更具體一點(diǎn)地來(lái)說(shuō)：Kubernetes 是一個(gè)自動(dòng)化的容器編排平臺(tái)，它負(fù)責(zé)應(yīng)用的部署、應(yīng)用的彈性以及應(yīng)用的管理，這些都是基于容器的。
下面，我們希望以三個(gè)例子跟大家更切實(shí)地介紹一下 Kubernetes 的能力。
Kubernetes 可以把用戶提交的容器放到 Kubernetes 管理的集群的某一臺(tái)節(jié)點(diǎn)上去。Kubernetes 的調(diào)度器是執(zhí)行這項(xiàng)能力的組件，它會(huì)觀察正在被調(diào)度的這個(gè)容器的大小、規(guī)格。
比如說(shuō)它所需要的 CPU以及它所需要的 memory，然后在集群中找一臺(tái)相對(duì)比較空閑的機(jī)器來(lái)進(jìn)行一次 placement，也就是一次放置的操作。在這個(gè)例子中，它可能會(huì)把紅顏色的這個(gè)容器放置到第二個(gè)空閑的機(jī)器上，來(lái)完成一次調(diào)度的工作。
Kubernetes 有一個(gè)節(jié)點(diǎn)健康檢查的功能，它會(huì)監(jiān)測(cè)這個(gè)集群中所有的宿主機(jī)，當(dāng)宿主機(jī)本身出現(xiàn)故障，或者軟件出現(xiàn)故障的時(shí)候，這個(gè)節(jié)點(diǎn)健康檢查會(huì)自動(dòng)對(duì)它進(jìn)行發(fā)現(xiàn)。
下面 Kubernetes 會(huì)把運(yùn)行在這些失敗節(jié)點(diǎn)上的容器進(jìn)行自動(dòng)遷移，遷移到一個(gè)正在健康運(yùn)行的宿主機(jī)上，來(lái)完成集群內(nèi)容器的一個(gè)自動(dòng)恢復(fù)。
Kubernetes 有業(yè)務(wù)負(fù)載檢查的能力，它會(huì)監(jiān)測(cè)業(yè)務(wù)上所承擔(dān)的負(fù)載，如果這個(gè)業(yè)務(wù)本身的 CPU 利用率過高，或者響應(yīng)時(shí)間過長(zhǎng)，它可以對(duì)這個(gè)業(yè)務(wù)進(jìn)行一次擴(kuò)容。
比如說(shuō)在下面的例子中，黃顏色的過度忙碌，Kubernetes 就可以把黃顏色負(fù)載從一份變?yōu)槿?。接下?lái)，它就可以通過負(fù)載均衡把原來(lái)打到第一個(gè)黃顏色上的負(fù)載平均分到三個(gè)黃顏色的負(fù)載上去，以此來(lái)提高響應(yīng)的時(shí)間。
以上就是 Kubernetes 三個(gè)核心能力的簡(jiǎn)單介紹。
Kubernetes 架構(gòu)是一個(gè)比較典型的二層架構(gòu)和 server-client 架構(gòu)。Master 作為中央的管控節(jié)點(diǎn)，會(huì)去與 Node 進(jìn)行一個(gè)連接。
所有 UI 的、clients、這些 user 側(cè)的組件，只會(huì)和 Master 進(jìn)行連接，把希望的狀態(tài)或者想執(zhí)行的命令下發(fā)給 Master，Master 會(huì)把這些命令或者狀態(tài)下發(fā)給相應(yīng)的節(jié)點(diǎn)，進(jìn)行最終的執(zhí)行。
Kubernetes 的 Master 包含四個(gè)主要的組件：API Server、Controller、Scheduler 以及 etcd。如下圖所示：
我們剛剛提到的 API Server，它本身在部署結(jié)構(gòu)上是一個(gè)可以水平擴(kuò)展的一個(gè)部署組件；Controller 是一個(gè)可以進(jìn)行熱備的一個(gè)部署組件，它只有一個(gè) active，它的調(diào)度器也是相應(yīng)的，雖然只有一個(gè) active，但是可以進(jìn)行熱備。
Kubernetes 的 Node 是真正運(yùn)行業(yè)務(wù)負(fù)載的，每個(gè)業(yè)務(wù)負(fù)載會(huì)以 Pod 的形式運(yùn)行。等一下我會(huì)介紹一下 Pod 的概念。一個(gè) Pod 中運(yùn)行的一個(gè)或者多個(gè)容器，真正去運(yùn)行這些 Pod 的組件的是叫做?kubelet，也就是 Node 上最為關(guān)鍵的組件，它通過 API Server 接收到所需要 Pod 運(yùn)行的狀態(tài)，然后提交到我們下面畫的這個(gè) Container Runtime 組件中。
在 OS 上去創(chuàng)建容器所需要運(yùn)行的環(huán)境，最終把容器或者 Pod 運(yùn)行起來(lái)，也需要對(duì)存儲(chǔ)跟網(wǎng)絡(luò)進(jìn)行管理。Kubernetes 并不會(huì)直接進(jìn)行網(wǎng)絡(luò)存儲(chǔ)的操作，他們會(huì)靠 Storage Plugin 或者是網(wǎng)絡(luò)的 Plugin 來(lái)進(jìn)行操作。用戶自己或者云廠商都會(huì)去寫相應(yīng)的?Storage Plugin?或者?Network Plugin，去完成存儲(chǔ)操作或網(wǎng)絡(luò)操作。
在 Kubernetes 自己的環(huán)境中，也會(huì)有 Kubernetes 的 Network，它是為了提供 Service network 來(lái)進(jìn)行搭網(wǎng)組網(wǎng)的。（等一下我們也會(huì)去介紹“service”這個(gè)概念。）真正完成 service 組網(wǎng)的組件的是?Kube-proxy，它是利用了 iptable 的能力來(lái)進(jìn)行組建 Kubernetes 的 Network，就是 cluster network，以上就是 Node 上面的四個(gè)組件。
Kubernetes 的 Node 并不會(huì)直接和 user 進(jìn)行 interaction，它的 interaction 只會(huì)通過 Master。而 User 是通過 Master 向節(jié)點(diǎn)下發(fā)這些信息的。Kubernetes 每個(gè) Node 上，都會(huì)運(yùn)行我們剛才提到的這幾個(gè)組件。
下面我們以一個(gè)例子再去看一下 Kubernetes 架構(gòu)中的這些組件，是如何互相進(jìn)行 interaction 的。
用戶可以通過 UI 或者 CLI 提交一個(gè) Pod 給 Kubernetes 進(jìn)行部署，這個(gè) Pod 請(qǐng)求首先會(huì)通過 CLI 或者 UI 提交給 Kubernetes API Server，下一步 API Server 會(huì)把這個(gè)信息寫入到它的存儲(chǔ)系統(tǒng) etcd，之后 Scheduler 會(huì)通過 API Server 的 watch 或者叫做 notification 機(jī)制得到這個(gè)信息：有一個(gè) Pod 需要被調(diào)度。
這個(gè)時(shí)候 Scheduler 會(huì)根據(jù)它的內(nèi)存狀態(tài)進(jìn)行一次調(diào)度決策，在完成這次調(diào)度之后，它會(huì)向 API Server report 說(shuō)：“OK！這個(gè) Pod 需要被調(diào)度到某一個(gè)節(jié)點(diǎn)上?！?/p>
這個(gè)時(shí)候 API Server 接收到這次操作之后，會(huì)把這次的結(jié)果再次寫到 etcd 中，然后 API Server 會(huì)通知相應(yīng)的節(jié)點(diǎn)進(jìn)行這次 Pod 真正的執(zhí)行啟動(dòng)。相應(yīng)節(jié)點(diǎn)的 kubelet 會(huì)得到這個(gè)通知，kubelet 就會(huì)去調(diào) Container runtime 來(lái)真正去啟動(dòng)配置這個(gè)容器和這個(gè)容器的運(yùn)行環(huán)境，去調(diào)度 Storage Plugin 來(lái)去配置存儲(chǔ)，network Plugin 去配置網(wǎng)絡(luò)。
這個(gè)例子我們可以看到：這些組件之間是如何相互溝通相互通信，協(xié)調(diào)來(lái)完成一次Pod的調(diào)度執(zhí)行操作的。
Pod 是 Kubernetes 的一個(gè)最小調(diào)度以及資源單元。用戶可以通過 Kubernetes 的 Pod API 生產(chǎn)一個(gè) Pod，讓 Kubernetes 對(duì)這個(gè) Pod 進(jìn)行調(diào)度，也就是把它放在某一個(gè) Kubernetes 管理的節(jié)點(diǎn)上運(yùn)行起來(lái)。一個(gè) Pod 簡(jiǎn)單來(lái)說(shuō)是對(duì)一組容器的抽象，它里面會(huì)包含一個(gè)或多個(gè)容器。
比如像下面的這幅圖里面，它包含了兩個(gè)容器，每個(gè)容器可以指定它所需要資源大小。比如說(shuō)，一個(gè)核一個(gè) G，或者說(shuō) 0.5 個(gè)核，0.5 個(gè) G。
當(dāng)然在這個(gè) Pod 中也可以包含一些其他所需要的資源：比如說(shuō)我們所看到的 Volume 卷這個(gè)存儲(chǔ)資源；比如說(shuō)我們需要 100 個(gè) GB 的存儲(chǔ)或者 20GB 的另外一個(gè)存儲(chǔ)。
在 Pod 里面，我們也可以去定義容器所需要運(yùn)行的方式。比如說(shuō)運(yùn)行容器的 Command，以及運(yùn)行容器的環(huán)境變量等等。Pod 這個(gè)抽象也給這些容器提供了一個(gè)共享的運(yùn)行環(huán)境，它們會(huì)共享同一個(gè)網(wǎng)絡(luò)環(huán)境，這些容器可以用 localhost 來(lái)進(jìn)行直接的連接。而 Pod 與 Pod 之間，是互相有 isolation 隔離的。
Volume 就是卷的概念，它是用來(lái)管理 Kubernetes 存儲(chǔ)的，是用來(lái)聲明在 Pod 中的容器可以訪問文件目錄的，一個(gè)卷可以被掛載在 Pod 中一個(gè)或者多個(gè)容器的指定路徑下面。
而 Volume 本身是一個(gè)抽象的概念，一個(gè) Volume 可以去支持多種的后端的存儲(chǔ)。比如說(shuō) Kubernetes 的 Volume 就支持了很多存儲(chǔ)插件，它可以支持本地的存儲(chǔ)，可以支持分布式的存儲(chǔ)，比如說(shuō)像 ceph，GlusterFS ；它也可以支持云存儲(chǔ)，比如說(shuō)阿里云上的云盤、AWS 上的云盤、Google 上的云盤等等。
Deployment 是在 Pod 這個(gè)抽象上更為上層的一個(gè)抽象，它可以定義一組 Pod 的副本數(shù)目、以及這個(gè) Pod 的版本。一般大家用 Deployment 這個(gè)抽象來(lái)做應(yīng)用的真正的管理，而 Pod 是組成 Deployment 最小的單元。
Kubernetes 是通過 Controller，也就是我們剛才提到的控制器去維護(hù) Deployment 中 Pod 的數(shù)目，它也會(huì)去幫助 Deployment 自動(dòng)恢復(fù)失敗的 Pod。
比如說(shuō)我可以定義一個(gè) Deployment，這個(gè) Deployment 里面需要兩個(gè) Pod，當(dāng)一個(gè) Pod 失敗的時(shí)候，控制器就會(huì)監(jiān)測(cè)到，它重新把 Deployment 中的 Pod 數(shù)目從一個(gè)恢復(fù)到兩個(gè)，通過再去新生成一個(gè) Pod。通過控制器，我們也會(huì)幫助完成發(fā)布的策略。比如說(shuō)進(jìn)行滾動(dòng)升級(jí)，進(jìn)行重新生成的升級(jí)，或者進(jìn)行版本的回滾。
Service 提供了一個(gè)或者多個(gè) Pod 實(shí)例的穩(wěn)定訪問地址。
比如在上面的例子中，我們看到：一個(gè) Deployment 可能有兩個(gè)甚至更多個(gè)完全相同的 Pod。對(duì)于一個(gè)外部的用戶來(lái)講，訪問哪個(gè) Pod 其實(shí)都是一樣的，所以它希望做一次負(fù)載均衡，在做負(fù)載均衡的同時(shí)，我只想訪問某一個(gè)固定的 VIP，也就是 Virtual IP 地址，而不希望得知每一個(gè)具體的 Pod 的 IP 地址。
我們剛才提到，這個(gè) pod 本身可能 terminal go（終止），如果一個(gè) Pod 失敗了，可能會(huì)換成另外一個(gè)新的。
對(duì)一個(gè)外部用戶來(lái)講，提供了多個(gè)具體的 Pod 地址，這個(gè)用戶要不停地去更新 Pod 地址，當(dāng)這個(gè) Pod 再失敗重啟之后，我們希望有一個(gè)抽象，把所有 Pod 的訪問能力抽象成一個(gè)第三方的一個(gè) IP 地址，實(shí)現(xiàn)這個(gè)的 Kubernetes 的抽象就叫 Service。
實(shí)現(xiàn) Service 有多種方式，Kubernetes 支持 Cluster IP，上面我們講過的 kuber-proxy 的組網(wǎng)，它也支持 nodePort、 LoadBalancer 等其他的一些訪問的能力。
Namespace 是用來(lái)做一個(gè)集群內(nèi)部的邏輯隔離的，它包括鑒權(quán)、資源管理等。Kubernetes 的每個(gè)資源，比如剛才講的 Pod、Deployment、Service 都屬于一個(gè) Namespace，同一個(gè) Namespace 中的資源需要命名的唯一性，不同的 Namespace 中的資源可以重名。
Namespace 一個(gè)用例，比如像在阿里巴巴，我們內(nèi)部會(huì)有很多個(gè) business units，在每一個(gè) business units 之間，希望有一個(gè)視圖上的隔離，并且在鑒權(quán)上也不一樣，在 cuda 上面也不一樣，我們就會(huì)用 Namespace 來(lái)去給每一個(gè) BU 提供一個(gè)他所看到的這么一個(gè)看到的隔離的機(jī)制。
下面我們介紹一下 Kubernetes 的 API 的基礎(chǔ)知識(shí)。從 high-level 上看，Kubernetes API 是由?HTTP+JSON?組成的：用戶訪問的方式是 HTTP，訪問的 API 中 content 的內(nèi)容是 JSON 格式的。
Kubernetes 的 kubectl 也就是 command tool，Kubernetes UI，或者有時(shí)候用 curl，直接與 Kubernetes 進(jìn)行溝通，都是使用 HTTP + JSON 這種形式。
下面有個(gè)例子：比如說(shuō)，對(duì)于這個(gè) Pod 類型的資源，它的 HTTP 訪問的路徑，就是 API，然后是 apiVesion: V1, 之后是相應(yīng)的 Namespaces，以及 Pods 資源，最終是 Podname，也就是 Pod 的名字。
如果我們?nèi)ヌ峤灰粋€(gè) Pod，或者 get 一個(gè) Pod 的時(shí)候，它的 content 內(nèi)容都是用 JSON 或者是 YAML 表達(dá)的。上圖中有個(gè) yaml 的例子，在這個(gè) yaml file 中，對(duì) Pod 資源的描述也分為幾個(gè)部分。
第一個(gè)部分，一般來(lái)講會(huì)是 API 的?version。比如在這個(gè)例子中是 V1，它也會(huì)描述我在操作哪個(gè)資源；比如說(shuō)我的?kind?如果是 pod，在 Metadata 中，就寫上這個(gè) Pod 的名字；比如說(shuō) nginx，我們也會(huì)給它打一些?label，我們等下會(huì)講到 label 的概念。在 Metadata 中，有時(shí)候也會(huì)去寫?annotation，也就是對(duì)資源的額外的一些用戶層次的描述。
比較重要的一個(gè)部分叫做?Spec，Spec 也就是我們希望 Pod 達(dá)到的一個(gè)預(yù)期的狀態(tài)。比如說(shuō)它內(nèi)部需要有哪些 container 被運(yùn)行；比如說(shuō)這里面有一個(gè) nginx 的 container，它的 image 是什么？它暴露的 port 是什么？
當(dāng)我們從 Kubernetes API 中去獲取這個(gè)資源的時(shí)候，一般來(lái)講在 Spec 下面會(huì)有一個(gè)項(xiàng)目叫?status，它表達(dá)了這個(gè)資源當(dāng)前的狀態(tài)；比如說(shuō)一個(gè) Pod 的狀態(tài)可能是正在被調(diào)度、或者是已經(jīng) running、或者是已經(jīng)被 terminates，就是被執(zhí)行完畢了。
剛剛在 API 之中，我們講了一個(gè)比較有意思的 metadata 叫做“label”，這個(gè) label 可以是一組 KeyValuePair。
比如下圖的第一個(gè) pod 中，label 就可能是一個(gè) color 等于 red，即它的顏色是紅顏色。當(dāng)然你也可以加其他 label，比如說(shuō) size: big 就是大小，定義為大的，它可以是一組 label。
這些 label 是可以被 selector，也就是選擇器所查詢的。這個(gè)能力實(shí)際上跟我們的 sql 類型的 select 語(yǔ)句是非常相似的，比如下圖中的三個(gè) Pod 資源中，我們就可以進(jìn)行 select。name color 等于 red，就是它的顏色是紅色的，我們也可以看到，只有兩個(gè)被選中了，因?yàn)橹挥兴麄兊?label 是紅色的，另外一個(gè) label 中寫的 color 等于 yellow，因?yàn)樗念伾皇羌t色，是不會(huì)被選中的。
通過 label，kubernetes 的 API 層就可以對(duì)這些資源進(jìn)行一個(gè)篩選，那這些篩選也是 kubernetes 對(duì)資源的集合所表達(dá)默認(rèn)的一種方式。
例如說(shuō)，我們剛剛介紹的 Deployment，它可能是代表一組的 Pod，它是一組 Pod 的抽象，一組 Pod 就是通過 label selector 來(lái)表達(dá)的。當(dāng)然我們剛才講到說(shuō) service 對(duì)應(yīng)的一組 Pod，就是一個(gè) service 要對(duì)應(yīng)一個(gè)或者多個(gè)的 Pod，來(lái)對(duì)它們進(jìn)行統(tǒng)一的訪問，這個(gè)描述也是通過 label selector 來(lái)進(jìn)行 select 選取的一組 Pod。
所以可以看到 label 是一個(gè)非常核心的 kubernetes API 的概念，我們?cè)诮酉聛?lái)的課程中也會(huì)著重地去講解和介紹 label 這個(gè)概念，以及如何更好地去使用它。
最后一部分，我想以一個(gè)例子來(lái)結(jié)束，讓大家跟我一起來(lái)嘗試一個(gè) kubernetes，在嘗試 Kubernetes 之前，我希望大家能在本機(jī)上安裝一下 Kubernetes，安裝一個(gè) Kubernetes 沙箱環(huán)境。
安裝這個(gè)沙箱環(huán)境，主要有三個(gè)步驟：
安裝 VirtualBox： https://www.virtualbox.org/wiki/Downloads
minikube 我們推薦使用下面寫到的阿里云的版本，它和官方 minikube 的主要區(qū)別就是把 minikube 中所需要的 Google 上的依賴換成國(guó)內(nèi)訪問比較快的一些鏡像，這樣就方便了大家的安裝工作；
安裝 MiniKube（中國(guó)版）: https://yq.aliyun.com/articles/221687
啟動(dòng)命令：minikube start —vm-driver virtualbox
如果大家不是 Mac 系統(tǒng)，其他操作系統(tǒng)請(qǐng)?jiān)L問下面這個(gè)鏈接，查看其它操作系統(tǒng)如何安裝 minikube 沙箱環(huán)境。
https://kubernetes.io/docs/tasks/tools/install-minikube/
當(dāng)大家安裝好之后，我會(huì)跟大家一起做一個(gè)例子，來(lái)做三件事情：
kubectl apply ?-f ?https://k8s.io/examples/application/deployment.yaml
kubectl apply -f ?https://k8s.io/examples/application/deployment-update.yaml
kubectl apply -f ?https://k8s.io/examples/application/deployment-update.yaml
第一步，我們提交一個(gè) nginx 的 Deployment，然后對(duì)這個(gè) Deployment 進(jìn)行一次版本升級(jí)，也就是改變它中間 Pod 的版本。最后我們也會(huì)嘗試對(duì) nginx 進(jìn)行一次擴(kuò)容，進(jìn)行一次水平的伸縮，下面就讓大家一起跟我來(lái)嘗試這三個(gè)操作吧。
首先，我們先看一下 minikube 的 status，可以看到 kubelet master 和 kubectl 都是配置好的。
下一步我們利用 kubectl 來(lái)看一下這個(gè)集群中節(jié)選的狀態(tài)，可以看到這個(gè)master 的節(jié)點(diǎn)已經(jīng)是running狀態(tài)：
我們就以這個(gè)為節(jié)點(diǎn)，下面我們嘗試去看一下現(xiàn)在集群中 Deployment 這個(gè)資源：
可以看到集群中沒有任何的 Deployment，我們可以利用 watch 這個(gè)語(yǔ)義去看集群中 Deployment 這個(gè)資源的變化情況。
下面我們?nèi)プ鰟偛畔胍娜齻€(gè)操作：第一個(gè)操作是去創(chuàng)建一個(gè) Deployment?？梢钥吹较旅娴谝粋€(gè)圖，這是一個(gè) API 的 content，它的 kind 是 Deployment，name 是 nginx-deployment, 有圖中它的 replicas 數(shù)目是2，它的鏡像版本是 1.7.9。
我們下面還是回到 kubectl 這個(gè) commnd 來(lái)執(zhí)行這次 Deployment 的真正的操作。我們可以看到一個(gè)簡(jiǎn)單的操作，就會(huì)去讓 Deployment 不停地生成副本。
Deployment 副本數(shù)目是 2 個(gè)，下面也可以 describe 一下現(xiàn)在的 Deployment 的狀態(tài)。我們知道之前是沒有這個(gè) Deployment 的，現(xiàn)在我們?nèi)?describe 這個(gè) nginx-deployment。
下圖中可以看到：有一個(gè) nginx-deployment 已經(jīng)被生成了，它的 replicas 數(shù)目也是我們想要的、selector 也是我們想要的、它的 image 的版本也是 1.7.9。還可以看到，里面的 deployment-controller 這種版本控制器也是在管理它的生成。
下面我們?nèi)ド?jí)這個(gè) Deployment 版本，首先下載另外一個(gè) yaml 文件 deployment-update.yaml，可以看到這里面的 image 本身的版本號(hào)從 1.7.9 升級(jí)到 1.8。
接下來(lái)我們重新 apply 新的 deployment-update 這個(gè) yaml 文件。
可以看到，在另一邊的屏幕上顯示出了這個(gè) Deployment 升級(jí)的一些操作，最終它的 up-to-date 值從 0 變成了 2，也就是說(shuō)所有的容器都是最新版本的，所有的 Pod 都是最新版本的。我們也可以 discribe 具體去看一下是不是所有 Pod 的版本都被更新了，可以看到這個(gè) image 的版本由 1.7.9 真正更新到了 1.8。
最后，我們也可以看到? controller 又執(zhí)行了幾次新的操作，這個(gè)控制器維護(hù)了整個(gè) Deployment 和 Pod 狀態(tài)。
最后我們演示一下給 Deployment 做水平擴(kuò)張，下載另一個(gè) yaml 文件 deployment-scale.yaml，這里面的 replicas 數(shù)目已經(jīng)從 2 改成了 4。
回到最開始的窗口，用 kubectl 去 apply 這個(gè)新的 deployment-scale.yaml 文件，在另外一個(gè)窗口上可以看到，當(dāng)我們執(zhí)行了 deployment-scale 操作之后，它的容器 Pod 數(shù)目從 2 變成了 4。我們可以再一次 describ 一下當(dāng)前集群中的 deployment 的情況，可以看到它的 replicas 的數(shù)目從 2 變到了 4，同時(shí)也可以看到 controller 又做了幾次新的操作，這個(gè) scale up 成功了。
最后，讓我們利用 delete 操作把我們剛才生成的 Deployment 給刪除掉。kubectl delete deployment，也是剛才我們本身的 deployment name，當(dāng)我們把它刪除掉之后，我們今天所有的操作就完成了。
我們?cè)偃ブ匦?get 這個(gè) Deployment，也會(huì)顯示這個(gè)資源不再存在，這個(gè)集群又回到了最開始干凈的狀態(tài)。
本文我們關(guān)注了 Kubernetes 的核心概念以及 Kubernetes 的架構(gòu)設(shè)計(jì)，主要有以下內(nèi)容：
“ 阿里巴巴云原生微信公眾號(hào)（ID：Alicloudnative）關(guān)注微服務(wù)、Serverless、容器、Service Mesh 等技術(shù)領(lǐng)域、聚焦云原生流行技術(shù)趨勢(shì)、云原生大規(guī)模的落地實(shí)踐，做最懂云原生開發(fā)者的技術(shù)公眾號(hào)?！?/strong>
免責(zé)聲明：本站發(fā)布的內(nèi)容（圖片、視頻和文字）以原創(chuàng)、轉(zhuǎn)載和分享為主，文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如果涉及侵權(quán)請(qǐng)聯(lián)系站長(zhǎng)郵箱：is@yisu.com進(jìn)行舉報(bào)，并提供相關(guān)證據(jù)，一經(jīng)查實(shí)，將立刻刪除涉嫌侵權(quán)內(nèi)容。
億速云公眾號(hào)
手機(jī)網(wǎng)站二維碼