本系列前三部分：

- [適合 Kubernetes 初學者的一些實戰練習 (一)](https://xie.infoq.cn/article/27f5f6250a3033ea09c337989)

- [適合 Kubernetes 初學者的一些實戰練習 (二)](https://xie.infoq.cn/article/580956ea7a92f6a75c9e8c1d6)

- [適合 Kubernetes 初學者的一些實戰練習 (三)](https://xie.infoq.cn/article/30adca0a20cf419e8768b6b98)

# 練習1 - Kubernetes pod 的自動 scale (水平自動伸縮）

`kubectl scale` 命令用於程式在負載加重或縮小時進行 pod 擴容或縮小，本練習我們透過一個實際例子來觀察 `scale`命令到底能達到什麼效果。

命令列建立一個 `deployment`：

> kubectl run jerry-nginx --image=nginx:1.12.2

![](https://img-blog.csdnimg.cn/img_convert/8a1f1a3816a76d8f1adc7d43f44005b4.png)

`kubectl get deploy` 檢視剛剛建立的 deployment：

![](https://img-blog.csdnimg.cn/img_convert/3f296b22bff3aba3c41042d5226e1d04.png)

自動被 deployment 建立的 pod：
kubectl get pod:

![](https://img-blog.csdnimg.cn/img_convert/3278ffe2d7b505a7ecd2001977c45629.png)

使用下列命令檢視生成的 deployment 明細：
> kubectl get deployment jerry-nginx -o yaml

![](https://img-blog.csdnimg.cn/img_convert/584b5aabfe8c9e4b6c491d9838e2e171.png)
![](https://img-blog.csdnimg.cn/img_convert/8d865ba492877444bcfb366d83b78838.png)

另一個有用的命令：
> kubectl describe deployment jerry-nginx

![](https://img-blog.csdnimg.cn/img_convert/e5b3bcdce4fcd3fdee9c836eaa78faef.png)

現在我們使用下面的命令對 deployment 進行水平擴充套件：
> kubectl scale deployment jerry-nginx --replicas=3

![](https://img-blog.csdnimg.cn/img_convert/989fb2a2ce5f2944b9a29829bc691d07.png)

> kubectl get pods -l run=jerry-nginx

下圖這個 Age 為 15 分鐘之前的是第一次建立 deployment 時生成的，其他兩個 Age 為 1 分鐘之前的是執行了 scale 命令後自動建立的。

![](https://img-blog.csdnimg.cn/img_convert/29b23679af209703e6d29daa35459b0b.png)

選中一個才建立的 pod，檢視其事件記錄：

> kubectl describe pod jerry-nginx-69fd9f6c4-8dpvb

![](https://img-blog.csdnimg.cn/img_convert/8ddef227d8188618de1f8af598cf2395.png)

> kubectl get replicaset

得到自動建立的 replication set：

![](https://img-blog.csdnimg.cn/img_convert/438cec50e93a982860df4b3773cb4152.png)

desired = 3 意思就是我們水平擴充套件時指定的引數 3.

即使手動刪除一個 pod例項，replication set 又會很快自動建立一個新的：

![](https://img-blog.csdnimg.cn/img_convert/40d9a8efe6c4f17957694eb68f8a56f1.png)

自動建立的新 pod：

![](https://img-blog.csdnimg.cn/img_convert/ed3990c798b44973b45dbd0dd7719e8c.png)

# 練習2 - Kubernetes 滾動升級(rolling update)特性體驗

在 Kubernetes 上執行我們的應用，有什麼收益？Kubernetes 可以幫助應用開發人員確保其開發出的應用程式以一種高可用的、可伸縮和容錯的方式進行部署和執行。

換句話說，Kubernetes 環境的搭建，系統的配置，可以全部交給 Kubernetes 的管理員，而應用開發人員作為 Kubernetes 的消費者，只需要記住幾個簡單的 kubectl 命令，就能夠輕鬆完成應用程式到 Kubernetes 上的部署，幾乎不需付出額外的代價就能享受到 Kubernetes 作為一個平臺給應用程式帶來的上述非功能性的提升。

在本系列第三篇文章[適合 Kubernetes 初學者的一些實戰練習 (三)](https://xie.infoq.cn/article/30adca0a20cf419e8768b6b98) 我們已經接觸了 [Gardener](https://github.com/gardener), 一個開源的建立 Kubernetes 叢集的解決方案：

![](https://img-blog.csdnimg.cn/img_convert/dfbcc0bcc7447356a2fbcb442755f874.png)

我在 Gardener 上建立一個基於 Google Cloud Platform 的 Kubernetes 叢集，取名jerry1204：

![](https://img-blog.csdnimg.cn/img_convert/56a311901a5e85fc9e41ba356494c33a.png)

![](https://img-blog.csdnimg.cn/img_convert/2b109b180c1ddde7fd1c283875f30dd6.png)

點選上圖 Access 標籤頁裡的 Dashboard(控制檯)超連結，即可對這個 Kubernetes 叢集進行操作。

![](https://img-blog.csdnimg.cn/img_convert/8afac3787bece79c20ae91036b1eb068.png)

控制檯裡看到的 Kubernetes 叢集工作節點資訊和命令列 `kubectl get node -o wide` 看到的一致：

![](https://img-blog.csdnimg.cn/img_convert/3c0fbd06c8dabf1d8d0378dfe2325168.png)

使用命令列來執行 Docker Hub 上的一個映象 i042416/ui5-nginx:
> kubectl run jerry-ui5 --image=i042416/ui5-nginx

![](https://img-blog.csdnimg.cn/img_convert/7a6460956151078828fbbe7906c0d364.png)

這個命令列背後發生了很多事情。
首先，執行在 Kubernetes 上的應用程式，其高可用性，可伸縮性和容錯性到底是透過 Kubernetes 什麼機制保證的？

![](https://img-blog.csdnimg.cn/img_convert/d82d2eefe14fbc5e9c80877f3b897a99.png)

答案是 pod。請單擊上面 Kubernetes 的架構圖，然後放大，能看到 node(節點)裡包含了多個 pod，每個 pod 裡又包含了多個容器。像它的中文含義(豆莢，飛機，航天器或船隻上可與主體分離的分離倉)暗示的一樣，pod 就是應用程式執行的載體，是 Kubernetes 的基本操作單元。整套 Kubernetes 系統的設計都是圍繞著 pod 展開，例如 pod 的部署和執行，如何保證處於執行狀態的 pod 總數量等於一個恆定值，如何將 pod 裡應用提供的服務暴露給外部訪問等等。

![](https://img-blog.csdnimg.cn/img_convert/00efe35a551379c602ac9d34feb1b468.png)

回到我們之前的命令列，我們試著執行另一個命令 kubectl get pod，果然發現了一個 pod 被建立出來，誕生已經40秒了(Age = 40s)。

![](https://img-blog.csdnimg.cn/img_convert/3a001b78b97c6a7bcf15864926169123.png)

用 describe 命令檢視這個 pod 的明細：

> kubectl describe pod jerry-ui5-6ffd46bb95-6bgpg

下圖 Container ID 後面的 docker://說明這是一個 docker 容器，當然並不意味著 Kubernetes 只支援 Docker 這一種容器技術，比如 Kubernetes 還支援 CoreOS 的 Rocket。

![](https://img-blog.csdnimg.cn/img_convert/835ce04bd3e4d7f50b6bc751672fe6e0.png)

describe 命名輸出的 Events 區域揭示了一個 pod 從誕生到開始服役的生命週期狀態跳轉：

> Scheduled->Pulling->Pulled->Created->Started

從每個狀態的 from 欄位也能看出很多資訊。

- Scheduled 狀態的 from: default-scheduler.

Scheduler 是 Kubernetes 的元件之一，負責排程 pod 到合適的節點上。具體什麼樣的節點算合適，取決於 Kubernetes Scheduler 排程演算法的實現。如果把Scheduler看成一個黑匣子，那麼它的輸入是 pod 和由多個節點組成的列表，輸出是 Pod 和一個匹配節點的繫結。這個狀態 message 顯示的內容 `Successfully assigned XXX to shoot--jerrytest-jerry1204-worker-yamer-z1-XXX` 後面這個 shoot--jerrytest 開頭的字串就是 pod 被分配到的節點的名稱。

後面幾個狀態的 from 欄位都是 `kubelet,shoot--jerrytest-jerry1204-worker-yamer-z1-XXX`，其中 kubelet 是 Kubernetes 節點上一個重要的模組，負責維護和管理執行於該節點上的所有容器，確保 pod 的執行狀態與使用者期望一致。

在 Kubernetes web 控制檯裡也一樣能看到這個處於執行狀態的 pod：

![](https://img-blog.csdnimg.cn/img_convert/0a99f37078fdb9107b1a0ef2531d943a.png)

除了 pod 之外，Kubernetes 第二個重要的概念就是 deployment.

執行另一個命令 `kubectl get deploy`，發現 kubectl run 命令除了生成一個 pod 外，還生成了一個 deployment.

從這個命令輸出的 Desired, Current 和 Up-to-Date, Available 下面的數字，結合前面提到的 Kubernetes 裡幾乎所有的設計都是圍繞著 pod 來展開這一指導思想，我們不難猜測出，這個生成的 deployment 也是為 pod 服務的。

![](https://img-blog.csdnimg.cn/img_convert/a938e2275adf159bcd7255499b486af4.png)

實際上，Kubernetes 的初學者可以把 deployment 的主要職責理解成是保證 pod 的數量和健康。

在 Kubernetes 的世界裡，我們不會直接和執行在 pod 裡的 docker 容器打交道，而是透過 Kubernetes service 將 pod 裡的應用提供的服務暴露給外界消費。

到目前為止，Kubernetes 叢集上還沒有任何和應用程式相關的 service 生成。命令 kubectl get svc 只返回了一個 Kubernetes 的標準服務。

![](https://img-blog.csdnimg.cn/img_convert/1eab66fc6f09e257000b38bc3464ab2c.png)

因此我們使用命令 kubectl expose 基於剛剛使用 kubectl run 生成的 deployment 建立一個service：

> kubectl expose deployment jerry-ui5 --type=LoadBalancer --port=80 --target-port=80
一旦 expose 命令執行後，get svc 命令這次就返回了一個和 deployment 同名的 service，暴露給外界訪問的 IP 地址為 35.205.230.209:

![](https://img-blog.csdnimg.cn/img_convert/8eb19aa83121a96b5921d610788ae308.png)
![](https://img-blog.csdnimg.cn/img_convert/7bdf6f69e400a1f9e5817f50345620fa.png)

於是，使用 url `35.205.230.209/webapp` 就能訪問執行在 Kubernetes pod 裡的 SAP UI5 應用了：
![](https://img-blog.csdnimg.cn/img_convert/3f8ec83ec6f2c1d136ba3a591fd6b72b.png)

到目前為止我們的 SAP UI5 應用僅僅執行在 Kubernetes 叢集上的一個工作節點的單個 pod 裡，還沒有感受到這個應用執行時的表現和之前執行在 Docker 容器裡有什麼差異。

我們現在就來嘗試下 Kubernetes deployment 的水平擴充套件功能。在 Kubernetes 操作檯裡選中 deployment，從選單裡執行 Scale 命令，

![](https://img-blog.csdnimg.cn/img_convert/b09f9062b6153e1c582562ceb43f68fa.png)

設定新的 pod 的數量：下面截圖的 3，意思是告訴這個 deployment，在命令執行完畢後，它必須要努力保證，在任何時候由它控制和監控的 pod 個數必須等於 3。

![](https://img-blog.csdnimg.cn/img_convert/6f56000786f979793b943077c6fa5578.png)

當然這個控制檯上的圖形選單在命令列裡也存在對應的命令，我們後面會用到。

上圖 OK 按鈕點選後，再次執行 `kubectl get pod`, 能觀察到水平擴充套件執行之後，生成了兩個新的 deployment，所以這次 get pod 命令總共返回了 3 個 pod，其中後兩個 pod 從 Age 能看出是水平擴充套件執行之後剛剛建立的。

![](https://img-blog.csdnimg.cn/img_convert/d391be2cdfe7f2d7c09faa932521d18c.png)

使用 kubectl describe 命令檢視 deployment 的明細，在 Replicas 這個欄位裡看到這個 deployment 控制的 pod 的執行時明細：

3 desired | 3 updated | 3 total | 3 available | 0 unavailable

![](https://img-blog.csdnimg.cn/img_convert/09e6dfe35bbed740b4cc96bea2544d25.png)

我們現在故意用 `kubectl delete` 刪除一個 pod，再次檢視，發生一個新的 pod 瞬間就自動生成了，處於執行狀態的 pod 總數仍然為 3.

## Kubernetes滾動升級(Rolling Update)特性體驗

滾動升級是 Kubernetes 一大特色，顧名思義，這是一種平滑過渡的升級方式，透過逐個容器替代升級的方式，來實現無中斷的服務升級。下圖 deployment 的 describe 命令的輸出，其中欄位 StrategyType 欄位表明 kubectl run 建立的 deployment 預設的升級方式就是滾動升級。

![](https://img-blog.csdnimg.cn/img_convert/a3431c42e98ce0ae5596650922e7a417.png)

我設計了這樣一個簡單的升級場景：我的 SAP UI5 應用 `1.0` 版本同時執行在一個 Kubernetes 節點的 10 個 pod 上。在整個應用不中斷的前提下，透過滾動升級的方式升級到 `2.0` 版本。

下面的命令列推送一個標籤為 `v1.0` 的映象到 Docker Hub：

![](https://img-blog.csdnimg.cn/img_convert/346d8ea8e2172436a2c0bafb0b32cf5d.png)
![](https://img-blog.csdnimg.cn/img_convert/50852469cbf3d2d680937f71523d5573.png)

修改 UI5 應用明細頁面的標題，在文字後加上一個(v2.0), 用來表示這一版的應用為 2.0 版本：

![](https://img-blog.csdnimg.cn/img_convert/e12d8d8aa71e3ab3e21ee81daf89e478.png)

同樣將這個 `2.0` 版本的映象推送到 Docker Hub 上：

![](https://img-blog.csdnimg.cn/img_convert/d4283d66d4ca66006b8ef843c13566f6.png)

Docker Hub 上兩個版本的映象都就緒了：

![](https://img-blog.csdnimg.cn/img_convert/458619c4fe5fae78dab1fd8d2bbe1dd7.png)

首先使用 `1.0` 版本的映象，啟動單個 pod 去執行 SAP UI5 應用：

> kubectl run jerry-ui5 --image=i042416/ui5-nginx:v1.0
使用 scale 命令將單個 pod 水平擴充套件到 10 個 pod：
> kubectl scale --replicas=10 deployment/jerry-ui5

![](https://img-blog.csdnimg.cn/img_convert/997cb84413b9ab710c05919624765216.png)

上圖看出 kubectl get pod 返回 10 個處於執行狀態的 pod.

使用下面的命令觸發滾動升級，把名為 jerry-ui5 的 deployment 基於的映象從 `v1.0` 升級到`v2.0`:

> kubectl set image deployment/jerry-ui5 i042416/ui5-nginx=i042416/ui5-nginx:v2.0

![](https://img-blog.csdnimg.cn/img_convert/1915de6854aeaceb3121721379b66b0c.png)

使用 `kubectl rollout status deployment/jerry-ui5` 檢視滾動升級的實時進展情況。上圖顯示的日誌表明，在某個時間點，有多少箇舊版本的 pod 正等待被終止，有多少個新版本的 pod 已經處於可用狀態。
任意點開一個 pod 檢視明細，發現其使用的 docker 映象已經是 `v2.0`版本了：

![](https://img-blog.csdnimg.cn/img_convert/a28245419c652cf4c64bbf956eff7a08.png)

最後在瀏覽器裡看到訂單明細頁面的標題，後面已經出現(v2.0), 再次確認了滾動升級已經成功結束了。

![](https://img-blog.csdnimg.cn/img_convert/0db466eda594a8c96600ec03f67f11a8.png)

# 總結

Kubernetes Pod 水平自動伸縮和滾動升級，是實際專案中兩個重要且常用的操作，也是能夠體現 Kubernetes 優越性的亮點所在。本文作為 Kubernetes 初學者實戰練習系列的第四部分，透過兩個實際的例子，詳細介紹了 Kubernetes 水平自動伸縮和滾動升級的命令列操作步驟，以及這些命令列執行後背後的實現細節，希望對初學者有所幫助。

適合 Kubernetes 初學者的一些實戰練習 (四)

相關文章