在雲原生應用迭代過程中，金絲雀發佈（Canary Release）是保障發佈穩定性的關鍵策略——通過將少量流量引流至新版本服務，驗證無異常後再逐步擴大流量佔比，可有效降低新版本上線風險。傳統 Kubernetes Ingress 需依賴廠商自定義註解實現金絲雀發佈，存在兼容性差、配置複雜等問題。
而 Kubernetes 官方 Gateway API 憑藉標準化的 HTTPRoute 資源與權重分發能力，原生支持金絲雀發佈場景，且配置更直觀、權限更可控。本文將基於 Gateway API 官方 HTTP 路由指南，結合 Azure Kubernetes Service (AKS) 環境，帶大家從零實現企業級金絲雀發佈方案。
核心原理：Gateway API 如何支撐金絲雀發佈？
Gateway API 通過 HTTPRoute 資源的backendRefs 字段實現流量權重分配，核心邏輯如下：
- 多後端關聯：在同一條HTTPRoute 規則中，同時關聯“穩定版服務”和“金絲雀版服務”兩個後端；
- 權重精準配置：通過 weight 字段為每個後端分配流量佔比（權重總和建議為100，便於直觀管控）；
- 標準化兼容：權重配置為 Gateway API 標準字段，無需依賴廠商註解，適配 NGINX、Traefik 等主流網關控制器；
- 角色分離管控：運維團隊負責 Gateway 網關實例部署，開發團隊僅需通過 HTTPRoute 配置流量規則，符合企業級多團隊協作規範。
本文將基於 NGINX Gateway Fabric 控制器（AKS 環境適配性最優的開源網關控制器之一），實現“90%流量到穩定版v1，10%流量到金絲雀版v2”的基礎場景，再擴展至全量灰度迭代流程。
前置準備：已部署 Gateway API 基礎環境
實現金絲雀發佈前，需確保 AKS 集羣已完成 Gateway API 基礎環境部署（若已部署可跳過，未部署可參考前文），關鍵檢查項如下：
- AKS 集羣版本 ≥ 1.24（Gateway API Beta 版本最低要求），已啓用 RBAC；
- 已安裝 Gateway API CRDs（gatewayclasses、gateways、httproutes 等）；
- 已部署 NGINX Gateway Fabric 控制器，；
- 已創建 Gateway 資源，網關狀態為 Ready。
驗證基礎環境狀態：
# 驗證 Gateway API CRDs
kubectl get crds | grep gateway.networking.k8s.io
# 驗證 NGINX 控制器狀態
kubectl get pods -n nginx-gateway
# 驗證 Gateway 狀態
kubectl get gateways.gateway.networking.k8s.io -n nginx-gateway實戰步驟：實現金絲雀發佈全流程
步驟 1：部署穩定版（v1）和金絲雀版（v2）服務
創建兩個服務，一個Nginx（穩定版，返回 nginx頁面），一個httpd（金絲雀版，返回tomcat頁面）
創建 canary-services.yaml 文件：
# 穩定版 v1 - Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 2
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.2
ports:
- containerPort: 80
---
# 穩定版 v1 - Service
apiVersion: v1
kind: Service
metadata:
name: nginx-service
spec:
selector:
app: nginx
type: ClusterIP
ports:
- protocol: TCP
port: 80
targetPort: 80
---
# 金絲雀版 v2 - Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
name: httpd-deployment
spec:
replicas: 1
selector:
matchLabels:
app: httpd
template:
metadata:
labels:
app: httpd
spec:
containers:
- name: httpd
image: httpd
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
name: httpd-service
spec:
type: ClusterIP
selector:
app: httpd
ports:
- protocol: TCP
port: 80
targetPort: 80
應用配置並驗證：
kubectl apply -f canary-services.yaml
# 驗證兩個版本的 Pod 和 Service 狀態
kubectl get pods -n nginx-gateway
kubectl get svc -n nginx-gateway輸出應顯示 Nginx 有 2 個 Running Pod，Httpd 有 1 個 Running Pod，兩個 Service 均正常暴露 80 端口。
步驟 2：創建 HTTPRoute 配置金絲雀流量規則
創建 canary-httproute.yaml 文件，通過匹配標頭“env=canary”將流量路由到金絲雀版本的服務。
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: web-service-canary-route
spec:
# 關聯已創建的 Gateway
parentRefs:
- name: example-gateway
# 路由規則：匹配根路徑（/）的所有 HTTP 請求
rules:
- matches:
- path:
type: PathPrefix
value: /
hostnames:
- "canary.aiorg.ltd"
- backendRefs:
- matches:
- headers:
- type: Exact
name: env
value: canary
backendRefs:
- name: httpd-service
port: 80
- backendRefs:
- name: nginx-service
port: 80應用配置並驗證：
kubectl apply -f canary-httproute.yaml
kubectl apply -f canary-httproute.yaml
# 驗證 HTTPRoute 狀態（STATUS 為 Accepted 表示規則已被網關接納）
kubectl get httproutes.gateway.networking.k8s.io -n default
kubectl describe httproutes.gateway.networking.k8s.io echo-service-canary-route -n default通過kubectl describe 查看事件，若顯示“Route accepted”，説明流量規則已成功應用到網關。
步驟 3：驗證金絲雀發佈效果
92 Echo Service v1 (Stable)
8 Echo Service v2 (Canary)驗證訪問穩定版-Nginx頁面，直接curl canary.aiorg.ltd，可以看到成功返回Nginx頁面：
訪問金絲雀版-Httpd，使用curl -H命令 curl -H "env:canary" http://canary.aiorg.ltd ，返回Httpd頁面：
對於 Azure 架構師而言，Gateway API 不僅是流量管理的升級方案，更是 AKS 集羣雲原生治理的重要組成部分。結合 Azure Monitor、Key Vault 等原生服務，可構建更穩定、安全、可觀測的企業級金絲雀發佈體系。
