Google 會運用 AI 技術將內容翻譯成你偏好的語言，但可能會出錯。

將 Ingress 遷移至 Gateway API

Autopilot Standard

本頁面說明如何將 Google Kubernetes Engine (GKE) 的流量管理功能從 Ingress API 遷移至 Gateway API。Gateway API 提供全代管解決方案，可處理應用程式流量。 Google Cloud

如要盡量減少停機時間並降低風險，最有效的方法是同時執行現有的 Ingress API 和新的 Gateway API 設定，藉此遷移至 Gateway API。這個方法可在實際環境中徹底測試新的 Gateway 設定，不會影響目前的服務。驗證新的閘道設定後，您可以快速轉換 DNS，將流量重新導向至 Gateway API，確保轉換過程順暢且風險低。

大致來說，遷移策略包含下列階段：

設定新的負載平衡器。
定義處理連入流量的規則。
部署新設定，並測試流向新閘道 IP 位址的流量。
將正式版流量切換至 Gateway API。
清除剩餘的 Ingress 資源。

設定新的負載平衡器

在這個階段，您會部署 Kubernetes 閘道資源，將流量負載平衡到您的 GKE 叢集。部署 Gateway 資源時，GKE 會設定第 7 層應用程式負載平衡器，將 HTTP(S) 流量公開給叢集中執行的應用程式。您需要為每個叢集或每個負載平衡器部署一個 Gateway 資源。

在下列範例中，您將設定全域外部應用程式負載平衡器。如要建立 Gateway，請將下列資訊清單儲存為 gateway.yaml：

kind: Gateway
apiVersion: gateway.networking.k8s.io/v1
metadata:
  name: external-http-gateway
spec:
  gatewayClassName: gke-l7-global-external-managed # GKE's managed external Application Load Balancer
  listeners:
  - name: http
    protocol: HTTP
    port: 80
    allowedRoutes:
      namespaces:
        from: Same # Only allow HTTPRoutes from the same namespace

上述資訊清單描述的閘道包含下列欄位：

gatewayClassName: gke-l7-global-external-managed：指定這個閘道的 GatewayClass。這個閘道類別使用全域外部應用程式負載平衡器。
protocol: HTTP 和 port: 80：指定閘道公開通訊埠 80，用於 HTTP 流量。

定義傳入流量的流量規則

路由資源會定義通訊協定專屬規則，用於將流量從閘道對應至後端服務。

在這個階段，您要將 Ingress 資訊清單轉換為 HTTPRoute 資源。如要轉換 Ingress 資訊清單，請按照 ingress2gateway 工具中的步驟操作。

這個範例假設您有下列 Ingress 資源：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: cafe-ingress
spec:
  ingressClassName: nginx
  rules:
  - host: cafe.example.com
    http:
      paths:
      - path: /tea
        pathType: Prefix
        backend:
          service:
            name: tea-svc
            port:
              number: 80
      - path: /coffee
        pathType: Prefix
        backend:
          service:
            name: coffee-svc
            port:
              number: 80

使用 ingress2gateway 工具轉換資訊清單後，輸出內容會是翻譯後的 HTTPRoute 資訊清單。

將下列範例資訊清單儲存為 httproute.yaml：

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: cafe-route
spec:
  # This route attaches to our new Gateway
  parentRefs:
  - name: external-http-gateway
  # The hostname is the same as before
  hostnames:
  - "cafe.example.com"
  # The routing rules are now more explicit
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /tea
    backendRefs:
    - name: tea-svc
      port: 80
  - matches:
    - path:
        type: PathPrefix
        value: /coffee
    backendRefs:
    - name: coffee-svc
      port: 80

請注意，HTTPRoute 資訊清單中的 rules 欄位，直接對應至原始 Ingress 資訊清單中定義的路由規則。

部署及測試新設定

在這個階段，您要套用前兩個階段建立的 Gateway 和 HTTPRoute 資訊清單，並測試流量是否會流向 Gateway 的新 IP 位址。

套用閘道和 HTTPRoute 資訊清單：

kubectl apply -f gateway.yaml
kubectl apply -f httproute.yaml

取得閘道的 IP 位址。系統可能需要幾分鐘才能分配 IP 位址：
```
kubectl get gateway external-http-gateway -o=jsonpath="{.status.addresses[0].value}" --watch
```
輸出內容是閘道的外部 IP 位址，例如 203.0.113.90。
測試新的閘道 IP 位址。使用下列 curl 指令將要求傳送至 IP 位址，並指定 cafe.example.com 主機名稱。例如：
```
curl --resolve cafe.example.com:80:203.0.113.90 http://cafe.example.com/tea
curl --resolve cafe.example.com:80:203.0.113.90 http://cafe.example.com/coffee
```
將 203.0.113.90 替換為您在上一個步驟中取得的外部 IP 位址。輸出內容確認新的閘道 IP 位址正確轉送 cafe.example.com 的流量，不需執行 DNS 查詢。

將流量導向新的閘道 IP 位址

在這個階段，您要更新 DNS 記錄，將網址指向新的 Gateway IP 位址，藉此將即時流量從先前的 Ingress 切換至新的 Gateway。更新 DNS 記錄的確切步驟會因 DNS 供應商而異。

舉例來說，如果您在 Ingress 中設定 cafe.example.com，請向 DNS 供應商查詢 cafe.example.com 的 A 記錄，然後將舊 Ingress IP 位址的值變更為 203.0.113.90，也就是新的 Gateway IP 位址。

更新 DNS 記錄後，流量會開始從 Ingress 轉移至 Gateway，但並非所有用戶端都會立即切換。如果 DNS 解析器已快取先前的記錄，則會等待記錄的存留時間 (TTL) 值到期，然後再次查詢記錄並接收更新後的 IP 位址。因此，在確認傳入 Ingress 的流量已停止前，您應繼續並行執行現有的 Ingress 和新的 Gateway，這表示 DNS 傳播已完成，用戶端不再導向舊的 IP 位址。如要確認這點，請監控負載平衡器或 Ingress 控制器的流量。詳情請參閱「檢查 DNS 傳播」。

如果您使用 Cloud DNS，可以利用目標權重，逐步將流量從舊 IP 位址轉移至新 IP 位址。詳情請參閱「設定 DNS 路由政策和健康狀態檢查」。

清除其餘 Ingress 資源

確認新的 Gateway 順利運作後，請清除舊的 Ingress 資源。

刪除 Ingress 資源：
```
kubectl delete ingress cafe-ingress
```
解除安裝 ingress-nginx 控制器。舉例來說，如果您使用 Helm 安裝控制器，請執行下列指令：
```
helm uninstall ingress-nginx -n ingress-nginx
```

Ingress NGINX 和 GKE Gateway 的功能比較

Gateway API 提供更標準化的方式來設定 ingress，並具備與大多數常見功能 (例如轉送、標頭和流量分割) 相同的功能。

下表比較 Ingress 控制器和 Gateway API 中常用功能的設定。

功能	Ingress 中的註解	GKE Gateway 中的設定	同位元
主機轉送	Ingress 物件中的 `spec.rules.host` 欄位。	HTTPRoute 物件中的 `hostnames` 欄位。	完全一致。
路徑型轉送	Ingress 物件中的 `spec.rules.http.paths` 欄位。	HTTPRoute 物件中的 `rules.matches.path` 欄位。	完全一致。
流量拆分	`nginx.ingress.kubernetes.io/canary` 則註解。	HTTPRoute，內含加權的 `backendRefs` 欄位。	完全一致。此外，您也可以精細控管流量分配。
工作階段相依性	`nginx.ingress.kubernetes.io/affinity` 和 `nginx.ingress.kubernetes.io/affinity-mode` 註解。	GCPTrafficDistributionPolicy ，並包含 `sessionAffinity` 欄位。	完全對等。 GKE Gateway 支援多種工作階段相依性類型，包括以 Cookie 為基礎的相依性類型 (`HTTP_COOKIE`、`GENERATED_COOKIE` 和有狀態 `STRONG_COOKIE_AFFINITY`)、以標頭為基礎的相依性 (`HEADER_FIELD`)，以及以用戶端 IP 為基礎的相依性 (`CLIENT_IP`)。
CORS (跨源資源共享)	`nginx.ingress.kubernetes.io/enable-cors`	含有 `CORS` 篩選器的 HTTPRoute。	完全一致。注意：GKE Gateway 會限制每個接聽程式或主機名稱可定義的萬用字元模式數量
網址重寫	`nginx.ingress.kubernetes.io/rewrite-target`	含有 `urlRewrite` 篩選器的 HTTPRoute。	部分均等。GKE Gateway 僅支援前置字元替換。
標頭操弄	`nginx.ingress.kubernetes.io/proxy-set-headers`或`add-headers`	具有 `requestHeaderModifier` 修飾符或 `responseHeaderModifier` 篩選器的 HTTPRoute。	完全一致。
驗證	`nginx.ingress.kubernetes.io/auth-url` 進行外部驗證。	Identity-Aware Proxy (IAP)：GCPBackendPolicy 自訂資源。其他：需要更客製化的做法，可能要使用服務網格或自訂篩選器。	部分均等。建議您使用 Identity-Aware Proxy 保護閘道，並在後端設定。

後續步驟

瞭解如何保護閘道。
瞭解 Gateway 流量管理的運作方式。