前言
軟件世界比以往任何時候都更快。為了保持競爭力，需要盡快推出新的軟件版本，而不會中斷活躍用戶訪問，影響用戶體驗。越來越多企業已將其應用遷移到 Kubernetes。
在 Kubernetes 中有幾種不同的方式發布應用，所以為了讓應用在升級期間依然平穩提供服務，選擇一個正確的發布策略就非常重要了，本篇文章將講解在 Kubernetes 使用藍綠更新的方式更新鏡像。
原理
藍綠發布是版本 1 與版本 2 會同時存在，通過控制 Service 來決定使用具體哪一個版本，也稱為紅黑部署。藍綠發布與滾動更新不同，版本 2 （綠） 與版本 1（藍）一起部署，在測試新版本滿足要求后，然后更新 Service 對象，通過替換 label selector 中的版本標簽來將流量發送到新版本，更新過程如下圖所示
實踐
使用 Kubernetes 原生方式升級應用
准備
image
bebullish/demo:v1
bebullish/demo:v2
deployment-v1
apiVersion: apps/v1
kind: Deployment
metadata:
name: demo-dp-v1
spec:
selector:
matchLabels:
app: demo
version: v1
replicas: 3
template:
metadata:
labels:
app: demo
version: v1
spec:
containers:
- name: demo
image: bebullish/demo:v1
ports:
- containerPort: 8080
deployment-v2
apiVersion: apps/v1
kind: Deployment
metadata:
name: demo-dp-v2
spec:
selector:
matchLabels:
app: demo
version: v2
replicas: 3
template:
metadata:
labels:
app: demo
version: v2
spec:
containers:
- name: demo
image: bebullish/demo:v2
ports:
- containerPort: 8080
service
apiVersion: v1
kind: Service
metadata:
name: demo-service
spec:
selector:
app: demo
version: v1 # 通過更改 version 來控制流量走向
type: LoadBalancer
ports:
- port: 80
targetPort: 8080
protocol: TCP
將上述 deployment-v1 以及 service 保存為 yaml 文件，使用 kubectl apply -f 命令創建 yaml 資源，等待創建成功后，使用 kubectl get svc 獲取 EXTERNAL-IP。
測試
如果使用瀏覽器測試的話，你會發現每次調用都會返回同一個 pod 的名字，那是因為瀏覽器發出的請求包含 keepAlive，所以需要使用 curl 來保證每次發出的請求都是重新創建的。
curl -X GET http://${EXTERNAL-IP}
升級
將上述 deployment-v2 保存為 yaml 文件，使用 kubectl apply -f 命令創建 yaml 資源，切換流量之前先執行命令，以便查看鏡像更新過程
while true; do curl -X GET http://${EXTERNAL-IP} ; done
等待 deployment-v2 創建成功后，通過將 service 的 version 值改為 v2 來切換流量
kubectl edit service demo-service
查看日志
請求流量
結論
首先可以發現在更新過程中，程序保持一直可用的狀態，v2 版本部署成功之后，所有請求還是 v1 版本，當流量切換后，立刻出現 v2 版本的日志，並且不會出現 v1 版本的日志，說明流量是一次性切換的，如果需要回滾只需要將流量切回 v1 版本即可。
使用 CODING CD 方式升級應用
創建服務
service
apiVersion: v1
kind: Service
metadata:
name: demo-service
spec:
selector:
createBy: demo-service # 這里填寫的標簽，會被添加到對應的 ReplicaSet 中
type: LoadBalancer
ports:
- port: 80
targetPort: 8080
protocol: TCP
這里注意，service 創建之后應不會匹配到任何資源，即 endpoint 為空，而在后面執行部署流程時會為 ReplicaSet 添加 label createBy: demo-service ，從而決定流量走向。
部署成功之后可以看到 demo-service
配置制品
使用 docker 官方鏡像需要以 docker.io 開頭
配置 yaml 及綁定制品
replicaSet
apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: demo-rs
spec:
replicas: 3
selector:
matchLabels:
app: demo
template:
metadata:
labels:
app: demo
spec:
containers:
- image: docker.io/bebullish/demo
name: demo
ports:
- containerPort: 8080
階段中選擇 部署（Manifest） ，輸入上述 yaml 文件（目前發布策略選項僅支持 ReplicaSet），這里需要把鏡像的版本刪除掉，在需要綁定的制品選擇之前配置的制品。這樣配置之后，每次執行的時候版本是動態傳入的。
藍綠（紅黑）發布配置
在下方勾選讓 CODING 部署控制台管理入口流量，然后選擇 demo-service 所在的命名空間（我這里是在 marlon 這個命名空間下），然后選擇 demo-service ，策略選擇 Red/Black（Blue/Green），保存即可。
發布制品
選擇應用和部署流程，輸入版本 v1。
查看結果
等待一小段時間后，就可以在部署控制台中看到發布的資源了。
更新鏡像版本
再次執行發布，版本輸入 v2。
更新原理
基於 CODING CD 的藍綠發布和一般的藍綠發布略有不同，一旦 v2 版本的 pod 處於就緒狀態后，他就會立即獲得流量，而當所有的 v2 版本的 pod 處於就緒狀態后，會禁用 v1 版本的 pod，此時所有流量會打到 v2 版本上，從而完成更新。
注意：基於 CODING CD 的藍綠發布會出現 v1 版本和 v2 版本同時獲得流量的情況，具體取決於 pod 的就緒探針，v2 版本的 pod 一旦就緒，那么它就會獲得流量，所以需要合理設計就緒探針，盡量減少 v1 版本和 v2 版本同時存在的時間差。
總結
使用 Kubernetes 原生方式實現藍綠更新步驟較多，但也容易出錯，推薦使用 coding.net 提供的 CD 功能，配置一次，永久使用。不僅降低了人工成本，提高容錯率，還提供了非常豐富的 CD 功能，推薦使用哦~
參考文章
【騰訊雲原生】雲說新品、雲研新術、雲游新活、雲賞資訊，掃碼關注同名公眾號，及時獲取更多干貨！！
