持續部署入門：基於 Kubernetes 實現藍綠髮布

騰訊雲原生發表於2020-09-08

前言

軟體世界比以往任何時候都更快。為了保持競爭力，需要儘快推出新的軟體版本，而不會中斷活躍使用者訪問，影響使用者體驗。越來越多企業已將其應用遷移到 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 功能，推薦使用哦~

參考文章

TrafficManagement

RolloutStrategies

CODING 持續部署

【騰訊雲原生】雲說新品、雲研新術、雲遊新活、雲賞資訊，掃碼關注同名公眾號，及時獲取更多幹貨！！

相關文章