場景一: 將新版本灰度給部分用戶
假設線上運行了一套對外提供 7 層服務的 Service A 服務，後來開發了個新版本 Service A’ 想要上線，但又不想直接替換掉原來的 Service A，希望先灰度一小部分用戶，等運行一段時間足夠穩定了再逐漸全量上線新版本，最後平滑下線舊版本。這個時候就可以利用 Nginx Ingress 基於 Header或 Cookie 進行流量切分的策略來發布，業務使用 Header 或 Cookie 來標識不同類型的用戶，我們通過配置 Ingress 來實現讓帶有指定 Header 或 Cookie 的請求被轉發到新版本，其它的仍然轉發到舊版本，從而實現將新版本灰度給部分用戶。
場景二: 切一定比例的流量給新版本
假設線上運行了一套對外提供 7 層服務的 Service B 服務，後來修復了一些問題，需要灰度上線一個新版本 Service B’，但又不想直接替換掉原來的 Service B，而是讓先切 10% 的流量到新版本，等觀察一段時間穩定後再逐漸加大新版本的流量比例直至完全替換舊版本，最後再滑下線舊版本，從而實現切一定比例的流量給新版本:
Ingress-Nginx 是一個 K8S ingress 工具，支持配置 Ingress Annotations 來實現不同場景下的灰度發佈和測試。 Nginx Annotations 支持以下幾種 Canary 規則：
假設我們現在部署了兩個版本的服務，老版本和 canary 版本（金絲雀版本）
nginx.ingress.kubernetes.io/canary-by-header：基於 Request Header 的流量切分，適用於灰度發佈以及 A/B 測試。當 Request Header 設置爲 always 時，請求將會被一直髮送到 Canary 版本；當 Request Header 設置爲 never 時，請求不會被髮送到 Canary 入口。
nginx.ingress.kubernetes.io/canary-by-header-value：要匹配的 Request Header 的值，用於通知 Ingress 將請求路由到 Canary Ingress 中指定的服務。當 Request Header 設置爲此值時，它將被路由到 Canary 入口。
nginx.ingress.kubernetes.io/canary-weight：基於服務權重的流量切分，適用於藍綠部署，權重範圍 0 - 100 按百分比將請求路由到 Canary Ingress 中指定的服務。權重爲 0 意味着該金絲雀規則不會向 Canary 入口的服務發送任何請求。權重爲 60 意味着 60%流量轉到 canary。權重爲 100 意味着所有請求都將被髮送到 Canary 入口。
nginx.ingress.kubernetes.io/canary-by-cookie：基於 Cookie 的流量切分，適用於灰度發佈與 A/B 測試。用於通知 Ingress 將請求路由到 Canary Ingress 中指定的服務的 cookie。當cookie 值設置爲 always 時，它將被路由到 Canary 入口；當 cookie 值設置爲 never 時，請求不會被髮送到 Canary 入口。