我們在系列文章 k8s 應用管理之道 - 公升級篇（一） 中介紹了不同部署形式下應用的公升級方法，同時展示了如何配置停機發布、滾動發布這兩類 k8s 原生支援的部署公升級策略。本文將介紹如何通過二次開發或使用一些第三方工具在 k8s 中實現應用的藍綠發布、金絲雀發布和 a/b 測試。
如果新老版本的應用無法共存，但又希望實現零中斷公升級，在系統資源充足的前提下，可以選用藍綠發布。通過 k8s 的 label-selector 機制可以輕鬆實現藍綠發布。如下圖所示，您需要做的僅僅是為不同版本的應用打上對應的標籤，然後通過更改 service 的 selector 實現流量切換。
這裡和藍綠發布相關的配置如下（完整配置參見 blue-green）。
[...]
kind: service
spec:
selector:
# 通過更改 version 的取值實現流量切換，例如 v2.0.0
version: v1.0.0
[...]
kind: deployment
metadata:
name: spring-boot-probes-v1
spec:
selector:
matchlabels:
version: v1.0.0
template:
metadata:
labels:
# pod 的 version 標籤
version: v1.0.0
[...]
kind: deployment
metadata:
name: spring-boot-probes-v2
spec:
selector:
matchlabels:
version: v2.0.0
template:
metadata:
labels:
# pod 的 version 標籤
version: v2.0.0
[...]
當一切準備就緒後，可以執行命令kubectl patch service spring-boot-probes-svc -p '}}'更改 service 的 selector，讓其指向 v2 版本的 pod。這時流量會全部發往 v2。
如果 v2 版本的應用執行一段時間後出現了問題，可以通過命令kubectl patch service spring-boot-probes-svc -p '}}'進行回滾，將流量再次切回到 v1 上來。
如果 v2 版本應用的行為符合預期，可以執行命令kubectl delete deploy spring-boot-probes-v1刪掉 v1 版本的 deployment 以節省資源。
金絲雀發布通過逐步切換流量的方式大大降低了公升級和變更可能帶來的風險，因此被廣泛使用。相較於其他發布方式，其最大特點在於對流量的靈活控制。回到 k8s 的場景，實現金絲雀發布最推薦的方式是使用 istio。利用 istio 強大的流量管理功能，使用者可以靈活地控制發往不同版本的流量，不論該版本部署了多少個 pod 例項。而在沒有 istio 的 k8s 環境中，發往新老版本的流量和它們的 pod 例項數成正比。
下圖展示了基於 istio 的金絲雀發布的關鍵元件，使用者可以通過調節 virtualservice 的 weight 字段指定將 10% 的流量發往金絲雀版本。
以下配置指定將 90% 的流量發往服務 spring-boot-probes-svc-v1，將 10% 的流量發往服務 spring-boot-probes-svc-v2。而服務 spring-boot-probes-svc-v1 繫結了當前版本的 pod，服務 spring-boot-probes-svc-v2 繫結了金絲雀版本的 pod（完整配置參見 canary）。
完成上述配置後，可以通過以下步驟實現金絲雀發布：
如果 v2 版本在執行過程**現了問題，可以更改 virtualservice 的路由規則將流量重新切回到 v1 上來。
待全部流量都落在 v2 上後，執行命令kubectl delete -f ./spring-boot-probes-v1刪除 v1 版應用的資源。
如果您**的 ui 作了改版，但並不確定新版本是否會獲得使用者青睞，這時可以通過 a/b 測試收集使用者意見，並根據實際效果確定最佳方案。a/b 測試實施的關鍵在於根據不同條件將訪問流量分發到不同的版本。實際使用中，往往會根據具體情況選用不同的條件。常用的條件包括使用者位置資訊、user-agent、自定義 header、請求引數、語言等。得益於強大的流量管理功能，istio 是 k8s 場景下實現 a/b 測試的最佳方案。下圖展示了如何根據 user-agent 分發訪問流量。
以下配置指定將來自 andriod 的訪問流量發往服務 spring-boot-probes-svc-v1，將來自 iphone 的訪問流量發往服務 spring-boot-probes-svc-v2。而 spring-boot-probes-svc-v1 和 spring-boot-probes-svc-v2 分別繫結了不同版本的 pod
（完整配置參見 ab-testing）。
完成上述配置後，可以通過以下步驟實施 a/b 測試：
讓兩個版本的應用同時執行一段時間並不斷收集使用者反饋。
如果發現使用 user-agent 作為條件並不能達到很好的測試效果，可以更改 virtualservice 的路由規則，根據其他條件進行測試。
經綜合分析後，如果發現 v1 更受青睞，則更改 virtualservice 的路由規則，讓流量只發往 v1，然後刪除 v2 版應用的資源。反之亦然。
本文帶您探索了在 k8s 中進行藍綠發布、金絲雀發布和 a/b 測試的最佳實踐。可以看到，運用好 istio 強大的流量管理功能可以簡化複雜發布的實施流程，大大降低實現成本。
K8s 應用管理之道 公升級篇（二）
我們在系列文章 k8s 應用管理之道 公升級篇 一 中介紹了不同部署形式下應用的公升級方法，同時展示了如何配置停機發布 滾動發布這兩類 k8s 原生支援的部署公升級策略。本文將介紹如何通過二次開發或使用一些第三方工具在 k8s 中實現應用的藍綠發布 金絲雀發布和 a b 測試。如果新老版本的應用無法...
k8s公升級要點筆記
看了這麼k8s公升級的相關文件，沒有一篇讓自己滿意的，有copy別人的，有雞肋的。看的不想看，咱們也不敢說，咱們也不敢問。廢話不多說，直接上要點 本人原版本v1.13.1 公升級到v1.15.0 新版本公升級k8s的同時，證書目錄下的證書也同時公升級 比以前的好多了 公升級過程記得備份虛機，公升級過...
k8s 執行應用
kubect建立deployment deployment 建立replicaset 根據replicaset 建立pod 命名方式 relicaset 的命名方式 deployment名稱 隨機數 pod命名方式 relicaset 隨機數 1 通過kubetcl 建立 kubectl run n...