透過 Higress 閘道實現 Kubernetes 金絲雀與藍綠發布實戰

在微服務架構盛行的今天，應用數量暴增、發布頻率加快，已經是常態。如果每次更新都直接全量上線，一旦踩到雷，影響範圍就是全部使用者，回滾的壓力也不小。所以我們通常會透過金絲雀發布（灰度發布）或藍綠發布這類策略，把風險控制在最小範圍內。這篇文章我會用 Higress 這套雲原生閘道，搭配實際操作範例，帶大家走一遍完整的流程。

金絲雀發布是什麼？

金絲雀發布（Canary Release），也有人叫灰度發布。核心概念就是：先把一小部分流量導到新版本，觀察一陣子沒問題後，再逐步放大比例，最終完全取代舊版。萬一中途出事，隨時可以把流量切回來。

流量分配的方式可以很靈活：最簡單的是按百分比隨機分配，進階一點可以根據 Request Header、來源 IP、Cookie 等條件來決定誰走新版。

金絲雀發布架構示意圖

藍綠發布是什麼？

藍綠發布的思路不同：同時維護兩套完整的環境（藍色＝現行版本、綠色＝新版本），兩邊都是可用狀態，互為熱備。切換的時候不是漸進式的，而是「全有或全無」——要嘛 100% 走新版，要嘛 100% 走舊版。好處是切換瞬間完成、零停機，回滾也只要把流量切回去就好。

藍綠發布架構示意圖

環境準備：安裝 Higress

我的環境是 Kubernetes v1.27.3，透過 Helm 來安裝 Higress：

# 加入 Helm repo
helm repo add higress.io https://higress.io/helm-charts

# 安裝 Higress
helm install higress -n higress-system higress.io/higress \
  --create-namespace \
  --render-subchart-notes \
  --set global.local=true \
  --set higress-console.o11y.enabled=false \
  --set higress-console.domain=console.higress.io \
  --set higress-console.admin.password.value=********

安裝完成後，設定 hosts 對應並做 port-forward：

# /etc/hosts 加入
127.0.0.1 demo.kubesre.com console.higress.io

# Port forward
kubectl port-forward service/higress-gateway -n higress-system 80:80

接著就可以用瀏覽器打開 http://console.higress.io/plugin 登入管理介面（帳密請自行設定）。

部署範例應用

先部署一個 v1 版本的 demo 應用：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo
  labels:
    app: demo
spec:
  replicas: 1
  selector:
    matchLabels:
      app: demo
  template:
    metadata:
      labels:
        app: demo
    spec:
      containers:
      - name: demo
        imagePullPolicy: Always
        image: registry.cn-shanghai.aliyuncs.com/kubesre01/demo:v1
        ports:
        - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: demo-svc
spec:
  type: ClusterIP
  selector:
    app: demo
  ports:
  - port: 8080
    targetPort: 8080

設定 Higress 路由

在 Higress Console 完成以下設定：

步驟	設定項目	內容
1	網域管理	新增網域 demo.kubesre.com
2	路由配置	建立路由，指向 demo-svc
3	驗證	curl http://demo.kubesre.com/info

驗證成功會回傳：

{"message":"雲原生運維圈！"}

部署新版本

接著部署 v2 版本：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-new
  labels:
    app: demo-new
spec:
  replicas: 1
  selector:
    matchLabels:
      app: demo-new
  template:
    metadata:
      labels:
        app: demo-new
    spec:
      containers:
      - name: demo-new
        imagePullPolicy: Always
        image: registry.cn-shanghai.aliyuncs.com/kubesre01/demo:v2
        ports:
        - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: demo-new-svc
spec:
  type: ClusterIP
  selector:
    app: demo-new
  ports:
  - port: 8080
    targetPort: 8080

實戰一：依 Request Header 切流量

這是最常見的場景之一：只讓帶有特定 Header 的請求走新版本，其餘維持舊版。適合內部測試人員先行驗證。

在 Higress Console 新建一條路由規則，設定 Header 匹配條件，目標服務指向 demo-new-svc。

驗證結果：

# 帶指定 Header → 走新版
curl -H "user: kubesre" http://demo.kubesre.com/info
{"message":"雲原生運維圈！新版本"}

# 不帶 Header → 走舊版
curl http://demo.kubesre.com/info
{"message":"雲原生運維圈！"}

實戰二：依來源 IP 切流量

另一個常見需求：只讓公司內網 IP 訪問新版本，外部使用者照舊。等內部驗證通過再全量切換。

在路由規則中設定來源 IP 白名單，即可達成。

驗證結果：

# 指定來源 IP → 走新版
curl -H "X-Forwarded-For:123.456.789.123" http://demo.kubesre.com/info
{"message":"雲原生運維圈！新版本"}

# 其他 IP → 走舊版
curl http://demo.kubesre.com/info
{"message":"雲原生運維圈！"}

實戰三：依權重比例切流量

這就是典型的灰度發布了。比如先把 30% 流量導到新版本，跑一段時間穩定後，再逐步加大比例直到 100%。

透過修改 Ingress 的 annotation 來設定權重：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    higress.io/canary: "true"
    higress.io/canary-weight: "30"
    higress.io/destination: demo-new-svc.default.svc.cluster.local:8080
  name: demo-new-canary
  namespace: higress-system
spec:
  ingressClassName: higress
  rules:
    ...

驗證結果（連打 20 次，大約 30% 會走新版）：

for i in {1..20}; do curl http://demo.kubesre.com/info; done
# 部分回傳 {"message":"雲原生運維圈！新版本"}
# 大部分回傳 {"message":"雲原生運維圈！"}

Higress 灰度發布常用 Annotation 整理

Annotation	用途	說明
higress.io/canary	開關	設為 "true" 啟用灰度
higress.io/canary-weight	權重百分比	0~100 的整數
higress.io/canary-weight-total	權重總和	預設 100
higress.io/canary-by-header	Header 匹配	指定 Header 名稱，值為 always 時導向灰度服務

小結

這篇整理了金絲雀發布和藍綠發布的核心差異，並透過 Higress 閘道搭配 Kubernetes 實際走了三種流量切分場景：Header 匹配、來源 IP 匹配、以及權重比例。在實際工作中，我個人比較常用的是權重比例的方式，因為操作直覺、也容易自動化整合到 CI/CD pipeline 裡。希望這篇能幫到正在評估發布策略的你。