在項目迭代的過程中，不可避免需要上線進行部署。

目前項目部署的方式有很多種：像重新部署，藍綠部署，金絲雀部署(灰度部署)，滾動更新。本文簡單介紹下這些常見的部署方案以及使用k8s怎么進行對應部署

重新部署

定義:先停止舊服務，然后啟動新服務，這是最簡單的一種部署方式

缺點:在整個過程中會出現一段時間的服務不可用

先準備兩個自己的鏡像，訪問接口為/dockerfile,返回的數據不一樣:
registry.cn-shenzhen.aliyuncs.com/chenpp/springboot-image:v2.0? 返回hello,docker
registry.cn-shenzhen.aliyuncs.com/chenpp/springboot-image:v3.0? 返回hello,k8s <br/>

詳細步驟參考這篇docker學習筆記(二)創建自己的鏡像

#recreate.yaml apiVersion: apps/v1 kind: Deployment metadata:name: recreate spec:strategy:type: Recreateselector:matchLabels:app: recreatereplicas: 4template:metadata:labels:app: recreatespec:containers:- name: recreateimage: registry.cn-shenzhen.aliyuncs.com/chenpp/springboot-image:v2.0ports:- containerPort: 8080livenessProbe:tcpSocket:port: 8080

修改yaml里的鏡像版本為v3.0，再次執行apply -f?

通過對pod狀態的持續觀察可以發現k8s是先停止舊的，然后再創建新的pod

藍綠部署

定義:藍綠部署就是不停止舊版本，直接部署新版本然后進行測試，測試驗證OK后，將流量全部切換到新版本，同時將舊版本也升級到新版本(或者可以將舊版本直接停掉)

優點: 無需停機，風險較小

缺點: 切換是全量的，如果版本2有問題，則對用戶體驗有直接影響,?需要雙倍機器資源。

部署過程：

部署v1的應用（初始狀態） ? ?所有外部請求的流量都會打到這個版本上

部署版本2的應用 ? ?版本2的代碼與版本1不同

如果版本2測試正常，就可以將流量切換到版本2

穩定運行一段時間，沒問題就刪除版本1正在使用的資源（例如實例），從此正式使用版本2

#bluegreem.yaml apiVersion: apps/v1 kind: Deployment metadata:name: blue spec:strategy:rollingUpdate:maxSurge: 25%maxUnavailable: 25%type: RollingUpdateselector:matchLabels:app: bluegreenreplicas: 4template:metadata:labels:app: bluegreenversion: v2.0spec:containers:- name: bluegreenimage: registry.cn-shenzhen.aliyuncs.com/chenpp/springboot-image:v2.0ports:- containerPort: 8080 apiVersion: v1 kind: Service metadata:name: bluegreen spec:ports:- port: 80protocol: TCPtargetPort: 8080selector:app: bluegreenversion: v2.0type: ClusterIP

修改bluegreen.yaml
deployment-name: blue ???---> ?? green
image: v2.0---> ??v3.0
version: v2.0 ???---> ?? v3.0

查看Pod可以發現兩個一開始green,blue 兩種pod共存(一共有八個pod)，訪問之前的ClusterIP地址，返回結果沒有變化

修改service的內容(把流量切到3.0的版本中)
version: v2.0? --->? v3.0

訪問之前的地址?發現流量已經完全切到了v3.0的版本上

金絲雀部署(灰度部署)

定義 :?灰度發布是指在黑與白之間，能夠平滑過渡的一種發布方式。
AB Test就是一種灰度發布方式，讓部分用戶繼續使用A版本，一部分用戶開始用B版本，如果用戶對新版本沒有什么意見反饋，那么逐步擴大范圍，把所有用戶都遷移到新版本上面來(A/B Test主要是用來測試應用功能表現,例如可用性、受歡迎程度、可見性等)。
灰度發布可以保證整體系統的穩定，在初始灰度的時候就可以發現、調整問題，以保證其影響度，而我們平常所說的金絲雀部署就是灰度發布的一種方式。

部署過程:

準備好部署各個階段的工件

從負載均衡列表中移除掉“金絲雀”服務器。

升級“金絲雀”應用（排掉原有流量并進行部署）。

對應用進行自動化測試。

將“金絲雀”服務器重新添加到負載均衡列表中（連通性和健康檢查）。

如果“金絲雀”在線使用測試成功，升級剩余的其他服務器。（否則就回滾）

優點: 用戶體驗影響小，灰度發布過程出現問題只影響部分用戶。

具體步驟跟上述差不多，只不過上面的service在切換的時候直接根據版本來切換，所以流量會全部切換過去，想要實現灰度部署的結果只需要把service的selector里的version標簽去掉就好(兩個版本的app標簽都是一樣的，鏡像不一樣，但是不影響service篩選需要負載的pod)
可以按照各自版本的設置不同的replicas，流量會按照比例進行分配

持續訪問service,可以看到請求被分發到不同的版本(如果不想增加pod數量，可以修改下每個版本pod的replicas數目)

滾動更新

定義:一般是取出一個或者多個服務器停止服務，更新版本后重新將其投入使用。周而復始，直到集群中所有的實例都更新成新版本。

這種部署方式相對于藍綠部署，更加節約資源——它不需要運行兩個集群、兩倍的實例數。我們可以部分部署，例如每次只取出集群的25%進行升級。

apiVersion: apps/v1 kind: Deployment metadata:name: rollingupdate spec:strategy:rollingUpdate:maxSurge: 25% #滾動升級時先啟動的pod數量maxUnavailable: 25% #滾動升級時允許的最大unavailable的pod數量type: RollingUpdateselector:matchLabels:app: rollingupdatereplicas: 4template:metadata:labels:app: rollingupdatespec:containers:- name: rollingupdateimage: registry.cn-shenzhen.aliyuncs.com/chenpp/springboot-image:v2.0ports:- containerPort: 8080 --- apiVersion: v1 kind: Service metadata:name: rollingupdate spec:ports:- port: 80protocol: TCPtargetPort: 8080selector:app: rollingupdatetype: ClusterIP

在worder1上，不斷地訪問觀察輸出結果
while sleep 0.2;do curl 10.102.115.66/dockerfile;echo "";done
在master上，監控pod kubectl get pods -w?

修改yaml中image的版本為v3.0,滾動更新
整個部署過程中Service不會停止，但是會有新舊pod并存的情況。

?

參考文章:https://www.v2ex.com/t/344341
?

總結

以上是生活随笔為你收集整理的kubernetes(七)项目部署方式：蓝绿部署,灰度发布/金丝雀发布,滚动更新的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。