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

看過很多關于云原生的文章，要么云山霧罩，要么曲高和寡。 所以筆者就有了寫《大話云原生》系列文章的想法，期望用最通俗、簡單的語言、方便記憶的場景來說明：云原生生態系統內的組成及應用關系。

文章目錄

一、Kubernetes的Pod概念解析

二、Pod標簽與Service服務

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

一、Kubernetes的Pod概念解析

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

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

一般來說一個Pod提供一種服務(微服務)，“哎？之前說容器技術的時候你也是這么說的”。是的，容器是提供服務的最小單元，那么Pod是什么概念？這是因為我們現在討論的是k8s，Pod是k8s服務調度的最小單元。

“為什么引入Pod的概念？”，因為有的時候你會發現：一個服務通常包含輔助它的服務。比如這個車上，一個導游長得漂亮口才好作為主導游提供核心講解服務，還有一個輔助她的導游負責發帽子、統計人數、統計消費等。同理回到架構技術角度舉個例子：一個nginx提供web服務容器作為核心服務容器，負責收集nginx日志的服務容器作為輔助服務和它部署在一個Pod，這樣方便日志收集與網絡連接。

一個Pod存在一個基礎容器Infra，基礎容器Infra提供了網絡共享的能力，就像主導游和輔助導游必須在一輛車（基礎容器Infra）上，或者基于這輛車組成了一個組合，否則他們之間無法對話及資源共享。

一個Pod下的容器共享網絡及數據卷，所以將容器服務間具有相當強的捆綁關系的服務容器放到一個Pod里面，通常一個容器提供核心服務，其他的容器提供輔助服務，如：日志收集、監控告警等。

二、Pod標簽與Service服務

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

對于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進行定義并執行。

Kubernetes 云原生

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。