在 Kubernetes 中，我們可以用兩種方法來實現藍綠髮布，通過單個 Service 對象或者 Ingress 控制器來實現藍綠髮布，實際操作都是類似的，都是通過 label 標籤去控制。

實現藍綠髮布的關鍵點就在於 Service 對象中 label selector 標籤的匹配方法，比如我們重新定義版本1 的資源清單文件 app-v1-single-svc.yaml，文件內容如下：

apiVersion: v1
kind: Service
metadata:
name: my-app
labels:
app: my-app
spec:
type: NodePort
ports:
- name: http
port: 80
targetPort: http
# 注意這裡我們匹配 app 和 version 標籤，當要切換流量的時候，我們更新 version 標籤的值，比如：v2.0.0
selector:
app: my-app
version: v1.0.0
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app-v1
labels:
app: my-app
spec:
replicas: 3
selector:
matchLabels:
app: my-app
version: v1.0.0
template:
metadata:
labels:
app: my-app
version: v1.0.0
annotations:
prometheus.io/scrape: "true"
prometheus.io/port: "9101"
spec:
containers:
- name: my-app
image: containersol/k8s-deployment-strategies
ports:
- name: http
containerPort: 8080
- name: probe
containerPort: 8086
env:
- name: VERSION
value: v1.0.0
livenessProbe:
httpGet:
path: /live
port: probe
initialDelaySeconds: 5
periodSeconds: 5
readinessProbe:
httpGet:
path: /ready
port: probe
periodSeconds: 5


上面定義的資源對象中，最重要的就是 Service 中 label selector 的定義：

selector:
app: my-app
version: v1.0.0


版本2 的應用定義和以前一樣，新建文件 app-v2-single-svc.yaml，文件內容如下：

apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app-v2
labels:
app: my-app
spec:
replicas: 3
selector:
matchLabels:
app: my-app
version: v2.0.0
template:
metadata:
labels:
app: my-app
version: v2.0.0
annotations:
prometheus.io/scrape: "true"
prometheus.io/port: "9101"
spec:
containers:
- name: my-app
image: containersol/k8s-deployment-strategies
ports:
- name: http
containerPort: 8080
- name: probe
containerPort: 8086
env:
- name: VERSION
value: v2.0.0
livenessProbe:
httpGet:
path: /live
port: probe
initialDelaySeconds: 5
periodSeconds: 5
readinessProbe:
httpGet:
path: /ready
port: probe
periodSeconds: 5


然後按照下面的步驟來驗證使用單個 Service 對象實現藍/綠部署的策略：

1. 版本1 應用提供服務
2. 部署版本2 應用
3. 等到版本2 應用全部部署完成
4. 切換入口流量從版本1 到版本2
5. 關閉版本1 應用

首先，部署版本1 應用：

$ kubectl apply -f app-v1-single-svc.yaml
service "my-app" created
deployment.apps "my-app-v1" created


測試版本1 應用是否部署成功：

$ kubectl get pods -l app=my-app
NAME READY STATUS RESTARTS AGE
my-app-v1-7b4874cd75-7xh6s 1/1 Running 0 41s
my-app-v1-7b4874cd75-dmq8f 1/1 Running 0 41s
my-app-v1-7b4874cd75-t64z7 1/1 Running 0 41s
$ kubectl get svc -l app=my-app
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
my-app NodePort 10.106.184.144 <none> 80:31539/TCP 50s
$ curl http://127.0.0.1:31539
Host: my-app-v1-7b4874cd75-7xh6s, Version: v1.0.0


同樣，新開一個終端，執行如下命令觀察 Pod 變化：

$ watch kubectl get pod -l app=my-app


然後部署版本2 應用：

$ kubectl apply -f app-v2-single-svc.yaml
deployment.apps "my-app-v2" created


然後在上面 watch 終端中可以看到會多3個my-app-v2開頭的 Pod，待這些 Pod 部署成功後，我們再去訪問當前的應用：

$ while sleep 0.1; do curl http://127.0.0.1:31539; done
Host: my-app-v1-7b4874cd75-dmq8f, Version: v1.0.0
Host: my-app-v1-7b4874cd75-dmq8f, Version: v1.0.0
......


我們會發現訪問到的都是版本1 的應用，和我們剛剛部署的版本2 沒有任何關係，這是因為我們 Service 對象中通過 label selector 匹配的是version=v1.0.0這個標籤，我們可以通過修改 Service 對象的匹配標籤，將流量路由到標籤version=v2.0.0的 Pod 去：

$ kubectl patch service my-app -p {"spec":{"selector":{"version":"v2.0.0"}}}
service "my-app" patched


然後再去訪問應用，可以發現現在都是版本2 的信息了：

$ while sleep 0.1; do curl http://127.0.0.1:31539; done
Host: my-app-v2-f885c8d45-r5m6z, Version: v2.0.0
Host: my-app-v2-f885c8d45-r5m6z, Version: v2.0.0
......


如果你需要回滾到版本1，同樣只需要更改 Service 的匹配標籤即可：

$ kubectl patch service my-app -p {"spec":{"selector":{"version":"v1.0.0"}}}


如果新版本已經完全符合我們的需求了，就可以刪除版本1 的應用了：

$ kubectl delete deploy my-app-v1


最後，同樣，執行如下命令清理上述資源對象：

$ kubectl delete all -l app=my-app


結論：

• 實時部署/回滾
• 避免版本問題，因為一次更改是整個應用的改變
• 需要兩倍的資源
• 在發布到生產之前，應該對整個應用進行適當的測試

金絲雀(Canary) - 讓部分用戶參與測試

金絲雀部署是讓部分用戶訪問到新版本應用，在 Kubernetes 中，可以使用兩個具有相同 Pod 標籤的 Deployment 來實現金絲雀部署。新版本的副本和舊版本的一起發布。在一段時間後如果沒有檢測到錯誤，則可以擴展新版本的副本數量並刪除舊版本的應用。

如果需要按照具體的百分比來進行金絲雀發布，需要儘可能的啟動多的 Pod 副本，這樣計算流量百分比的時候才方便，比如，如果你想將 1% 的流量發送到版本 B，那麼我們就需要有一個運行版本 B 的 Pod 和 99 個運行版本 A 的 Pod，當然如果你對具體的控制策略不在意的話也就無所謂了，如果你需要更精確的控制策略，建議使用服務網格（如 Istio），它們可以更好地控制流量。

在下面的例子中，我們使用 Kubernetes 原生特性來實現一個窮人版的金絲雀發布，如果你想要對流量進行更加細粒度的控制，請使用豪華版本的 Istio。下面是金絲雀發布的應用請求示意圖：

接下來我們按照下面的步驟來驗證金絲雀策略：

1. 10個副本的版本1 應用提供服務
2. 版本2 應用部署1個副本（意味著小於10%的流量）
3. 等待足夠的時間來確認版本2 應用足夠穩定沒有任何錯誤信息
4. 將版本2 應用擴容到10個副本
5. 等待所有實例完成
6. 關閉版本1 應用

首先，創建版本1 的應用資源清單，app-v1-canary.yaml，內容如下：

apiVersion: v1
kind: Service
metadata:
name: my-app
labels:
app: my-app
spec:
type: NodePort
ports:
- name: http
port: 80
targetPort: http
selector:
app: my-app
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app-v1
labels:
app: my-app
spec:
replicas: 10
selector:
matchLabels:
app: my-app
version: v1.0.0
template:
metadata:
labels:
app: my-app
version: v1.0.0
annotations:
prometheus.io/scrape: "true"
prometheus.io/port: "9101"
spec:
containers:
- name: my-app
image: containersol/k8s-deployment-strategies
ports:
- name: http
containerPort: 8080
- name: probe
containerPort: 8086
env:
- name: VERSION
value: v1.0.0
livenessProbe:
httpGet:
path: /live
port: probe
initialDelaySeconds: 5
periodSeconds: 5
readinessProbe:
httpGet:
path: /ready
port: probe
periodSeconds: 5


其中核心的部分也是 Service 對象中的 label selector 標籤，不在具有版本相關的標籤了，然後定義版本2 的資源清單文件，app-v2-canary.yaml，文件內容如下：

apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app-v2
labels:
app: my-app
spec:
replicas: 1
selector:
matchLabels:
app: my-app
version: v2.0.0
template:
metadata:
labels:
app: my-app
version: v2.0.0
annotations:
prometheus.io/scrape: "true"
prometheus.io/port: "9101"
spec:
containers:
- name: my-app
image: containersol/k8s-deployment-strategies
ports:
- name: http
containerPort: 8080
- name: probe
containerPort: 8086
env:
- name: VERSION
value: v2.0.0
livenessProbe:
httpGet:
path: /live
port: probe
initialDelaySeconds: 5
periodSeconds: 5
readinessProbe:
httpGet:
path: /ready
port: probe
periodSeconds: 5


版本1 和版本2 的 Pod 都具有一個共同的標籤app=my-app，所以對應的 Service 會匹配兩個版本的 Pod。

首先，部署版本1 應用：

$ kubectl apply -f app-v1-canary.yaml
service "my-app" created
deployment.apps "my-app-v1" created


然後測試版本1 應用是否正確部署了：

$ kubectl get svc -l app=my-app
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
my-app NodePort 10.105.133.213 <none> 80:30760/TCP 47s
$ curl http://127.0.0.1:30760
Host: my-app-v1-7b4874cd75-tsh2s, Version: v1.0.0


同樣，新開一個終端，查看 Pod 的變化：

$ watch kubectl get po


然後部署版本2 應用：

$ kubectl apply -f app-v2-canary.yaml
deployment.apps "my-app-v2" created


然後在 watch 終端頁面可以看到多了一個 Pod，現在一共 11 個 Pod，其中只有1 個 Pod 運行新版本應用，然後同樣可以循環訪問該應用，查看是否會有版本2 的應用信息：

$ while sleep 0.1; do curl http://127.0.0.1:30760; done
Host: my-app-v1-7b4874cd75-bhxbp, Version: v1.0.0
Host: my-app-v1-7b4874cd75-wmcqc, Version: v1.0.0
Host: my-app-v1-7b4874cd75-tsh2s, Version: v1.0.0
Host: my-app-v1-7b4874cd75-ml58j, Version: v1.0.0
Host: my-app-v1-7b4874cd75-spsdv, Version: v1.0.0
Host: my-app-v2-f885c8d45-mc2fx, Version: v2.0.0
......


正常情況下可以看到大部分都是返回的版本1 的應用信息，偶爾會出現版本2 的應用信息，這就證明我們的金絲雀發布成功了，待確認了版本2 的這個應用沒有任何問題後，可以將版本2 應用擴容到10 個副本：

$ kubectl scale --replicas=10 deploy my-app-v2
deployment.extensions "my-app-v2" scaled


其實這個時候訪問應用的話新版本和舊版本的流量分配是1:1了，確認了版本2 正常後，就可以刪除版本1 的應用了：

$ kubectl delete deploy my-app-v1
deployment.extensions "my-app-v1" deleted


最終留下的是 10 個新版本的 Pod 了，到這裡我們的整個金絲雀發布就完成了。

同樣，最後，執行下面的命令刪除上面的資源對象：

$ kubectl delete all -l app=my-app


結論：

• 部分用戶獲取新版本
• 方便錯誤和性能監控
• 快速回滾
• 發布較慢
• 流量精準控制很浪費（99％A / 1％B = 99 Pod A，1 Pod B）

如果你對新功能的發布沒有信心，建議使用金絲雀發布的策略。

A/B測試(A/B testing) - 最適合部分用戶的功能測試

A/B 測試實際上是一種基於統計信息而非部署策略來制定業務決策的技術，與業務結合非常緊密。但是它們也是相關的，也可以使用金絲雀發布來實現。

除了基於權重在版本之間進行流量控制之外，A/B 測試還可以基於一些其他參數（比如 Cookie、User Agent、地區等等）來精確定位給定的用戶群，該技術廣泛用於測試一些功能特性的效果，然後按照效果來進行確定。

我們經常可以在今日頭條的客戶端中就會發現有大量的 A/B 測試，同一個地區的用戶看到的客戶端有很大不同。

要使用這些細粒度的控制，仍然還是建議使用 Istio，可以根據權重或 HTTP 頭等來動態請求路由控制流量轉發。

下面是使用 Istio 進行規則設置的示例，因為 Istio 還不太穩定，以下示例規則將來可能會更改：

route:
- tags:
version: v1.0.0
weight: 90
- tags:
version: v2.0.0
weight: 10


關於在 Istio 中具體如何做 A/B 測試，我們這裡就不再詳細介紹了，我們在istio-book文檔中有相關的介紹。

結論：

• 幾個版本並行運行
• 完全控制流量分配
• 特定的一個訪問錯誤難以排查，需要分散式跟蹤
• Kubernetes 沒有直接的支持，需要其他額外的工具

總結

發布應用有許多種方法，當發布到開發/測試環境的時候，重建或者滾動更新通常是一個不錯的選擇。在生產環境，滾動更新或者藍綠髮布比較合適，但是新版本的提前測試是非常有必要的。如果你對新版本的應用不是很有信心的話，那應該使用金絲雀發布，將用戶的影響降到最低。最後，如果你的公司需要在特定的用戶群體中進行新功能的測試，例如，移動端用戶請求路由到版本 A，桌面端用戶請求路由到版本 B，那麼你就看使用A/B 測試，通過使用 Kubernetes 服務網關的配置，可以根據某些請求參數來確定用戶應路由的服務。

如果您有任何問題或反饋，請隨時在下面留言。

本文主要參考鏈接：https://container-solutions.com/kubernetes-deployment-strategies/

推薦

最後打個廣告，給大家推薦一個本人精心打造的一個精品課程，現在限時優惠中：從 Docker 到 Kubernetes 進階

微信搜索k8s技術圈關注我們的微信公眾帳號，在微信公眾帳號中回復 加群 即可加入到我們的 kubernetes 討論群裡面共同學習。

推薦閱讀：