【大話雲原生】kubernetes灰度發佈篇-從步行到坐纜車的自動化服務升級

此文系【大話雲原生】系列第四篇，該系列文章期望用最通俗、簡單的語言說明白雲原生生態系統內的組成、架構以及應用關係。從這篇開始我們要開始針對Kubernetes進行介紹了，本文內容如下：

一、Kubernetes的Pod概念解析

前文說到老婆過生日了我們一起出去旅游，上了團體服務班車，小娜同學(老婆)閑聊到：“這服務還不錯哈，2個跟車導游，1個司機”。三句不離老本行，我無聊的說到：“他們三個人就是一個Pod，提供一天的旅游服務內容，有主有次不可分割"。

小娜同學又上套了：“什麼是Pod啊？英文單詞豌豆莢？”，讓老婆增加對老公崇拜感的機會不可多得，那就開講，反正坐車也是閑著。

• 一般來說一個Pod提供一種服務(微服務)，“哎？之前說容器的時候你也是這麼說的”。是的，容器是提供服務的最小單元，那麼Pod是什麼概念？這是因為我們現在討論的是k8s，Pod是k8s服務調度的最小單元。
• “為什麼引入Pod的概念？”，因為有的時候你會發現：一個服務通常包含輔助它的服務。比如這個車上，一個導游長得漂亮口才好作為主導游提供核心講解服務，還有一個輔助她的導游負責發帽子、統計人數、統計消費等。同理回到架構技術角度，一個nginx提供web服務容器作為核心服務容器，負責收集nginx日誌的服務容器作為輔助服務和它部署在一起，這樣方便日誌收集與連接。
• 一個Pod存在一個基礎容器Infra，基礎容器Infra提供了網路共用的能力，就像主導游和輔助導游必須在一輛車（基礎容器Infra）上，或者基於這輛車組成了一個組合，否則他們之間無法對話及資源共用。
• 一個Pod下的容器共用網路及數據捲，所以將容器服務間具有相當強的捆綁關係的服務容器放到一個Pod裡面，通常一個容器提供核心服務，其他的容器提供輔助服務，如：日誌收集、監控告警等。

二、Pod標簽與Service服務

聊著聊著很快車就到了旅游目的地，一下車發現X公司的團隊還真不少。導游都統一都帶上了深紅色的帽子（游客帶上藍色遮陽帽），浩浩蕩蕩出發。深紅色的帽子為導游打上了標簽，他們面向游客（用戶）提供了統一的一種服務叫做：“導游服務”。

對於K8s中的服務架構也是一樣的：

• 一個Pod通常提供一種服務，如nginx web訪問服務
• 多個提供同樣服務的Pod通常打上一樣的標簽
• 創建Service：具備同一種標簽的Pod組成一個Service，對外提供服務。

三、自動化服務升級-灰度發佈

我們今天的項目是爬山，提供了兩種方式：一是直接爬(即步行)，二是坐纜車，當然如果你中途爬不動了也可以在纜車換乘站上纜車。

• 步行到纜車可以理解為一次服務升級（1.0版本服務升級為2.0版本服務）。從技術角度，服務升級等同於新版本服務的部署被稱為Deployment。K8s同樣使用Deployment這個術語代表服務升級部署。
• ReplicaSet代表一個版本的Pod服務組合，1.0步行版本的Pod服務組合，2.0為纜車版本的Pod服務組合，這樣理解是不是容易多了呢？
• 在服務容器部署Deployment的過程中，不希望服務中斷(即：不希望對步行1.0的用戶的服務出現中斷情況)，所以停掉一個1.0的Pod，再啟動一個2.0的Pod2.0，這個過程被稱為灰度發佈。整個過程高度依賴Kubernetes提供的自動化運維能力。

上面的圖每個RS只有2個Pod，還不能那麼直觀的理解灰度發佈，看下麵這張圖

• 圓形代表Pod，分為v1版本和v2版本，虛線標識的Pod表示即將下線的Pod
• v1版本的Pod減一，v2版本的pod加一
• 逐漸ReplicaSet：v1的Pod全部銷毀，ReplicaSet：v2的Pod逐漸被創建並啟動提供服務
• 整個的灰度發佈過程，在k8s種通過一個Deployment進行定義。

此專欄《大話雲原生》的前三篇文章如下

• 《【大話雲原生】煮餃子與docker、kubernetes之間的關係》
• 《【大話雲原生】負載均衡篇-小飯館的流量變大了》
• 《【大話雲原生】微服務篇-五星級酒店的服務方式》

如果您讀完了覺得有收穫，期待您能轉發分享，您的支持是我不竭的創作動力！

歡迎關註我的博客，更多精品知識合集

本文轉載註明出處（必須帶連接，不能只轉文字）：字母哥博客 - zimug.com

覺得對您有幫助的話，幫我點贊、分享！您的支持是我不竭的創作動力！。另外，筆者最近一段時間輸出瞭如下的精品內容，期待您的關註。

• 《kafka修煉之道》
• 《手摸手教你學Spring Boot2.0》
• 《Spring Security-JWT-OAuth2一本通》
• 《實戰前後端分離RBAC許可權管理系統》
• 《實戰SpringCloud微服務從青銅到王者》