共計 4770 個字符，預計需要花費 12 分鐘才能閱讀完成。
今天就跟大家聊聊有關怎樣體會 Kubernetes 內容器的高可用性和彈性伸縮，可能很多人都不太了解，為了讓大家更加了解，丸趣 TV 小編給大家總結了以下內容，希望大家根據這篇文章可以有所收獲。
丸趣 TV 小編將會介紹如何在 Kubernetes 里運行這個 docker 鏡像。
在 Kubernetes 上運行我們的應用，有什么收益？根據 Jerry 這十多天有限的時間里對 Kubernetes 的學習，我的理解是，Kubernetes 可以幫助應用開發人員確保其開發出的應用程序以一種高可用的、可伸縮和容錯的方式進行部署和運行，應用開發人員無需花費大量時間和精力去學習 Kubernetes 底層細節。
換句話說，Kubernetes 環境的搭建，系統的配置，可以全部交給 Kubernetes 的管理員，而應用開發人員作為 Kubernetes 的消費者，只需要記住幾個簡單的 kubectl 命令，就能夠輕松完成應用程序到 Kubernetes 上的部署，幾乎不需付出額外的代價就能享受到 Kubernetes 作為一個平臺給應用程序帶來的上述非功能性的提升。
我們繼續用前一篇文章使用到的 UI5 應用進行講解。
Jerry 很窮，沒有錢購買額外的服務器自己搭建 Kubernetes 集群環境。幸運的是，Kubernetes 并沒有拋棄我們這些貧窮的程序員，我們還可以選擇 Kubernetes Clusters as a Service 這種解決方案。
我在 SAP 內部的 Gardener 上創建一個基于 Google Cloud Platform 的 Kubernetes 集群，取名 jerry1204：
可以看到這個創建好的集群上的 Kubernetes 版本還是比較新的, 1.12.3 僅僅低于 12 月 3 日剛剛發布的 1.13 版。
點擊上圖 Access 標簽頁里的 Dashboard(控制臺)超鏈接，即可對這個 Kubernetes 集群進行操作。當然像 SAP 上海研究院 Kubernetes 培訓課程上講課的那些老司機們更喜歡用命令行。
因為是免費的集群，只分配了一個工作節點：
控制臺里看到的 Kubernetes 集群工作節點信息和命令行 kubectl get node -o wide 看到的一致：
Kubernetes 里的兩個重要概念：pod 和 deployment
下面我們使用命令行來消費我們前一篇文章上傳到 Docker Hub 上的鏡像 i042416/ui5-nginx:
kubectl run jerry-ui5 –image=i042416/ui5-nginx
這個命令行背后發生了很多事情。
首先，運行在 Kubernetes 上的應用程序，其高可用性，可伸縮性和容錯性到底是通過 Kubernetes 什么機制保證的？
答案是 pod。請單擊上面 Kubernetes 的架構圖，然后放大，能看到 node(節點)里包含了多個 pod，每個 pod 里又包含了多個容器。像它的中文含義 (豆莢，飛機，航天器或船只上可與主體分離的分離倉) 暗示的一樣，pod 就是應用程序運行的載體，是 Kubernetes 的基本操作單元。整套 Kubernetes 系統的設計都是圍繞著 pod 展開，例如 pod 的部署和運行，如何保證處于運行狀態的 pod 總數量等于一個恒定值，如何將 pod 里應用提供的服務暴露給外部訪問等等。
回到我們之前的命令行，我們試著執行另一個命令 kubectl get pod，果然發現了一個 pod 被創建出來，誕生已經 40 秒了(Age = 40s)。
用 describe 命令查看這個 pod 的明細：
kubectl describe pod jerry-ui5-6ffd46bb95-6bgpg
下圖 Container ID 后面的 docker:// 說明這是一個 docker 容器，當然并不意味著 Kubernetes 只支持 Docker 這一種容器技術，比如 Kubernetes 還支持 CoreOS 的 Rocket。
describe 命名輸出的 Events 區域揭示了一個 pod 從誕生到開始服役的生命周期狀態跳轉：
Scheduled- Pulling- Pulled- Created- Started
image.gif
從每個狀態的 from 字段也能看出很多信息。
Scheduled 狀態的 from: default-scheduler。Scheduler 是 Kubernetes 的組件之一，負責調度 pod 到合適的節點上。具體什么樣的節點算合適，取決于 Kubernetes Scheduler 調度算法的實現，Jerry 沒有研究過。如果把 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：
除了 pod 之外，Kubernetes 第二個重要的概念就是 deployment。
執行另一個命令 kubectl get deploy，發現 kubectl run 命令除了生成一個 pod 外，還生成了一個 deployment。從這個命令輸出的 Desired, Current 和 Up-to-Date, Available 下面的數字，結合前面提到的 Kubernetes 里幾乎所有的設計都是圍繞著 pod 來展開這一指導思想，我們不難猜測出，這個生成的 deployment 也是為 pod 服務的。
實際上，Kubernetes 的初學者可以把 deployment 的主要職責理解成是保證 pod 的數量和健康。
在前面的文章里，我們已經知道了怎樣使用 docker run 啟動一個 docker 鏡像。然而在 Kubernetes 的世界里，我們不會直接和運行在 pod 里的 docker 容器打交道，而是通過 Kubernetes service 將 pod 里的應用提供的服務暴露給外界消費。
到目前為止，Kubernetes 集群上還沒有任何和應用程序相關的 service 生成。命令 kubectl get svc 只返回了一個 Kubernetes 的標準服務。
因此我們使用命令 kubectl expose 基于剛剛使用 kubectl run 生成的 deployment 創建一個 service：
kubectl expose deployment jerry-ui5 –type=LoadBalancer –port=80 –target-port=80
image.gif
一旦 expose 命令執行后，get svc 命令這次就返回了一個和 deployment 同名的 service，暴露給外界訪問的 IP 地址為 35.205.230.209:
于是，使用 url 35.205.230.209/webapp 就能訪問運行在 Kubernetes pod 里的 SAP UI5 了：
Kubernetes 保證應用程序高可用性和伸縮性的一些體驗
到目前為止我們的 SAP UI5 應用僅僅運行在 Kubernetes 集群上的一個工作節點的單個 pod 里，還沒有感受到這個應用運行時的表現和之前運行在 Docker 容器里有什么差異。
我們現在就來嘗試下 Kubernetes deployment 的水平擴展功能。在 Kubernetes 操作臺里選中 deployment，從菜單里執行 Scale 命令，
設定新的 pod 的數量：下面截圖的 3，意思是告訴這個 deployment，在命令執行完畢后，它必須要努力保證，在任何時候由它控制和監控的 pod 個數必須等于 3。
當然這個控制臺上的圖形菜單在命令行里也存在對應的命令，我們后面會用到。
上圖 OK 按鈕點擊后，再次執行 kubectl get pod, 能觀察到水平擴展執行之后，生成了兩個新的 deployment，所以這次 get pod 命令總共返回了 3 個 pod，其中后兩個 pod 從 Age 能看出是水平擴展執行之后剛剛創建的。
使用 kubectl describe 命令查看 deployment 的明細，在 Replicas 這個字段里看到這個 deployment 控制的 pod 的運行時明細：
3 desired | 3 updated | 3 total | 3 available | 0 unavailable
我們現在故意用 kubectl delete 刪除一個 pod，再次查看，發生一個新的 pod 瞬間就自動生成了，處于運行狀態的 pod 總數仍然為 3。
Kubernetes 滾動升級 (Rolling Update) 特性體驗
滾動升級是 Kubernetes 一大特色，顧名思義，這是一種平滑過渡的升級方式，通過逐個容器替代升級的方式，來實現無中斷的服務升級。下圖 deployment 的 describe 命令的輸出，其中字段 StrategyType 字段表明 kubectl run 創建的 deployment 默認的升級方式就是滾動升級。
我設計了這樣一個簡單的升級場景：我的 SAP UI5 應用 1.0 版本同時運行在一個 Kubernetes 節點的 10 個 pod 上。在整個應用不中斷的前提下，通過滾動升級的方式升級到 2.0 版本。
由于上一篇文章我上傳到 Docker Hub 上的鏡像的標簽為默認的 latest，所以我需要在 Docker Hub 上分別制造兩個標簽為 v1.0 和 v2.0 的鏡像。
下面的命令行推送一個標簽為 v1.0 的鏡像到 Docker Hub：
修改 UI5 應用明細頁面的標題，在文字后加上一個(v2.0), 用來表示這一版的應用為 2.0 版本：
同樣將這個 2.0 版本的鏡像推送到 Docker Hub 上：
Docker Hub 上兩個版本的鏡像都就緒了：
首先使用 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
上圖看出 kubectl get pod 返回 10 個處于運行狀態的 pod。
使用下面的命令觸發滾動升級，把名為 jerry-ui5 的 deployent 基于的鏡像從 v1.0 升級到 v2.0:
kubectl set image deployment/jerry-ui5 i042416/ui5-nginx=i042416/ui5-nginx:v2.0
使用 kubectl rollout status deployment/jerry-ui5 查看滾動升級的實時進展情況。上圖顯示的日志表明，在某個時間點，有多少個舊版本的 pod 正等待被終止，有多少個新版本的 pod 已經處于可用狀態。
X old replicas are pending termination
X of Y updated replicas are available
任意點開一個 pod 查看明細，發現其使用的 docker 鏡像已經是 v2.0 版本了：
最后在瀏覽器里看到訂單明細頁面的標題，后面已經出現(v2.0), 再次確認了滾動升級已經成功結束了。
本文介紹的只是 Kubernetes 特性的冰山一角，更多細節，有待我們去學習，畢竟 SAP 云平臺即將支持 Kubernetes 環境了。感謝閱讀。
看完上述內容，你們對怎樣體會 Kubernetes 內容器的高可用性和彈性伸縮有進一步的了解嗎？如果還想了解更多知識或者相關內容，請關注丸趣 TV 行業資訊頻道，感謝大家的支持。
