recreate(重建)模式
一次性終止所有的舊版本后並一次性發布新版本
定義的部署將終止所有正在運行的實例,然后使用較新的版本重新創建它們 最適合開發環境的發布
優點:
應用狀態完全更新
缺點:
停機時間取決於應用程序的關閉和啟動持續時間
ramped(滾動)模式
以滾動更新的方式發布新版本,成功創建一個新pod后再終止一個舊版本的Pod
漸變部署以滾動更新方式更新 pod,使用應用程序的新版本創建輔助ReplicaSet,然后減少舊版本的副本數,並增加新版本,直到達到正確的副本數
優點：
版本會在實例之間緩慢發布
對於可以處理數據重新平衡的有狀態應用程序很方便
缺點：
推出/回滾可能需要一些時間
支持多個API很難
無法控制流量
重建模式和滾動模式的區別
Deployment控制器支持兩種更新策略： 滾動更新（rolling update）和 重新創建（recreate），默認為滾動更新。重新創建更新類似於前文中 ReplicaSet的第一種更新方式，即首先刪除現有的Pod對象,而后由 控制器基於新模板重新創建出新版本資源對象.通常,只應該在應用的新舊版本不兼容（ 如依賴的后端數據庫的schema不同且無法兼容）時運行時才會使用recreate策略,因為它會導致應用替換期間暫時不可用,好處在於它不存在中間狀態,用戶訪問到的要么是應用的 新版本,要么是舊版本
滾動升級是默認的更新策略,它在刪除一部分舊版本Pod資源的同時,補充創建一部分 新版本的Pod對象進行應用升級,其優勢是升級期間,容器中應用提供的服務不會中斷，但要求應用程序能夠應對新舊版本同時工作的情形,例如新舊版本兼容同一個 數據庫方案等.不過更新操作期間,不同客戶端得到的響應內容可能會來自不同版本的 應用
Deployment控制器的滾動更新操作並非在同一個ReplicaSet控制器對象下刪除並 創建Pod資源,而是將它們分置於兩個不同的控制器之下：舊控制器的Pod對象數量 不斷減少的同時,新控制器的Pod對象數量不斷增加,直到舊控制器不再擁有Pod對象
blue/green(藍色/綠色)模式
與舊版本一起發布新版本,然后切換流量
藍色/綠色部署與漸變部署不同,因為應用程序的“綠色”版本與“藍色”版本同時部署.在測試新版本滿足要求之后,我們更新Kubernetes Service對象
該對象扮演負載平衡器的角色,通過替換選擇器字段中的版本標簽將流量發送到新版本.
優點:
即時部署/回滾
避免版本問題,一次性更改整個群集狀態
缺點：
需要兩倍的資源
在正式發布之前,應該對整個平台進行適當的測試
處理有狀態的應用程序可能很困難
canary(金絲雀)模式
向一部分用戶發布新版本,然后進行全面部署
金絲雀部署將用戶的子集路由到新功能.在k8s中,可以使用兩個具有通用Pod標簽的部署來完成金絲雀部署.新版本的一個副本與舊版本一起發布
在一段時間后,如果未檢測到錯誤,請按比例增加新版本的副本數量並刪除舊的部署
優點：
為部分用戶發布的版本
方便出錯率和性能監控
快速回滾
缺點：
緩慢推出
精細調整的流量分配可能會很昂貴(99％A / 1％B = 99個Pod A，1個Pod B)
a/b testing(a/b測試)模式
A/B測試實際上是一種基於統計信息而不是部署策略制定業務決策的技術.但是,它是相關的,可以使用canary部署來實現
以精確的方式(HTTP標頭,cookie,權重等)向一部分用戶發布新版本.A / B測試實際上是一種基於統計信息做出業務決策的技術
除了根據權重在各個版本之間分配流量外,還可以基於一些參數(cookie,用戶代理等)精確定位給定的用戶群.此技術被廣泛用於測試給定功能的轉換
並且僅推出轉換最多的版本,最適合部分用戶的功能測試
優點:
需要智能負載均衡器
多個版本並行運行
完全控制流量分配
缺點:
難以解決給定會話的錯誤,因此必須進行分布式跟蹤
不簡單,您需要設置其他工具
shadow(影子部署)模式
和舊版本一起發布新的版本 把舊版本接收到的所有流量全部鏡像到新版本用來測試新版本的穩定性 但是新版本並不會對流量進行任何響應
Deployment實現應用部署
實現水平擴展/收縮
水平擴展/收縮非常容易實現,Deployment Controller只需要修改它所控制的ReplicaSet的Pod副本個數就可以了
把值從3改成4那么Deployment所對應的ReplicaSet,就會根據修改后的值自動創建一個新的 Pod.這就是“水平擴展”了.“水平收縮”則反之
kubectl scale deployment nginx-deployment --replicas=4
實現滾動更新
READY 表示當前處於Running狀態的Pod個數,但容器的鏡像版本不一定是最新的
UP-TO-DATE 表示當前處於最新版本的Pod的個數 最新版本指的是Pod的Spec字段和Deployment里Pod模板中定義的完全一致
AVAILABLE 表示當前已經可用的Pod的個數 即是Running狀態又是最新版本並且容器已經Ready狀態的Pod個數,描述的是用戶期望的最終狀態的個數
滾動更新流程:
1.當修改了Deployment里的Pod定義之后,Deployment Controller會使用這個修改后的Pod模板創建一個新的ReplicaSet.這個新的 ReplicaSet 的初始Pod副本數是0
2.然后Deployment Controller 開始將這個新的ReplicaSet 所控制的Pod副本數從0個變成1個.即:“水平擴展”出一個副本
3.Deployment Controller又將舊的ReplicaSet所控制的舊Pod 副本數減少一個.即:“水平收縮”成兩個副本
4.如此交替進行,新ReplicaSet管理的Pod副本數,從0個變成1個,再變成 2個,最后變成 3個.而舊的ReplicaSet管理的Pod副本數則從3個變成 2個,再變成 1個,最后變成 0個.這樣就完成了這一組 Pod 的版本升級過程
將一個集群中正在運行的多個Pod版本 交替地逐一升級的過程,就是“滾動更新”
在升級剛開始的時候,集群里只有1個新版本的 Pod.如果這時新版本Pod有問題啟動不起來,那么“滾動更新”就會停止.而在這個過程中,由於應用本身還有兩個舊版本的Pod在線,所以服務並不會受到太大的影響
Deployment Controller還會確保在任何時間窗口內,只有指定比例的Pod處於離線狀態.同時它也會確保,在任何時間窗口內只有指定比例的新Pod被創建出來.這兩個比例的值都是可以配置的默認都是DESIRED值的25%
在RollingUpdateStrategy 的配置中:
maxSurge=1指定的是除了DESIRED數量之外在一次“滾動”中,Deployment 控制器還可以創建多少個新Pod
maxSurge=50%指的是我們最多可以一次創建 “50%*DESIRED 數量” 個新版本 Pod
maxUnavailable=1指的是在一次“滾動”中,Deployment控制器可以刪除多少個舊Pod
maxUnavailable=50%指的是我們最多可以一次刪除 “50%*DESIRED 數量” 個舊版本 Pod
1. Deployment 的控制器實際上控制的是ReplicaSet 的數目以及每個ReplicaSet的屬性
2. 一個應用的版本對應的正是一個ReplicaSet這個版本應用的Pod數量.則由ReplicaSet通過它自己的控制器(ReplicaSet Controller)來保證
3.這樣的多個ReplicaSet對象Kubernetes項目就實現了對多個“應用版本”的描述
4.應用版本和ReplicaSet是 一一對應的關系
我們對 Deployment 進行的每一次更新操作,默認都會生成一個新的ReplicaSet對象 相當於創建一個程序的版本
Kubernetes 項目還提供了一個指令,使得我們對Deployment的多次更新操作最后只生成一個ReplicaSet 相當於多次更新操作的集合作為一個程序版本
在更新Deployment 前你要先執行一條 kubectl rollout pause 指令
由於此時 Deployment 正處於“暫停”狀態所以我們對 Deployment 的所有修改,都不會觸發新的“滾動更新”也不會創建新的ReplicaSet
等到我們對 Deployment 修改操作都完成之后,只需要再執行一條 kubectl rollout resume 指令就可以把這個Deployment“恢復”回來
而在這個kubectl rollout resume指令執行之前,在kubectl rollout pause 指令之后的這段時間里我們對 Deployment 進行的所有修改最后只會觸發一次“滾動更新相當於只會創建一個ReplicaSet(表示一個程序版本)