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

將 Ingress 遷移至 Gateway API

Autopilot Standard

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

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

一般來說，遷移策略包含下列階段：

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

設定新的負載平衡器

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

在以下範例中，您將設定全域外部應用程式負載平衡器。如要建立閘道，請將下列資訊清單儲存為 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 資訊清單中定義的路由規則。

部署及測試新設定

在這個階段，您會套用在前兩個階段建立的閘道和 HTTPRoute 資訊清單，並測試流量是否流向閘道的新 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 記錄，將即時流量從先前的 Ingress 移轉至新的閘道，並指向新的閘道 IP 位址。更新 DNS 記錄的實際步驟會因 DNS 供應商而異。

舉例來說，如果您在 Ingress 中設定 cafe.example.com，則應在 DNS 供應商中找出 cafe.example.com 的 A 記錄，並將舊 Ingress IP 位址的值變更為 203.0.113.90，也就是新的閘道 IP 位址。

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

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

清除剩餘的 Ingress 資源

確認新的閘道成功執行後，請清除舊的 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` 欄位，以及用於規則運算式路徑比對的 `nginx.ingress.kubernetes.io/use-regex` 註解。	HTTPRoute 物件中的 `rules.matches.path` 欄位。	完全對等。GKE Gateway 支援路徑的完全比對、前置字元比對和規則運算式比對 (`RegularExpression`)。此外，您可以使用確切值或規則運算式，比對 HTTP 標頭 (`rules.matches.headers`) 和查詢參數 (`rules.matches.queryParams`)。
流量拆分	`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，或含有 `spec.urlRewrite.regexModifier` 欄位的 GCPHTTPFilter。	完全一致。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 保護閘道，並在後端設定。

後續步驟

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