本頁面說明 GKE Ingress 的核心功能和網路架構，特別是保護從用戶端到負載平衡器，以及透過負載平衡器到應用程式 Pod 的連線、管理多個後端服務的複雜路由，以及瞭解叢集內負載平衡器健康狀態檢查的協調方式。
本頁面以 GKE Ingress 總覽所述的基本概念為基礎，如需使用 FrontendConfig 和 BackendConfig 等自訂資源的逐步操作說明和導入範例，請參閱「為 GKE 應用程式設定 Ingress 功能」。
本頁面適用於網路專家，他們負責為組織設計網路架構，以及安裝、設定和支援網路設備。如要進一步瞭解我們在Google Cloud 內容中提及的常見角色和範例工作，請參閱「常見的 GKE 使用者角色和工作」。
使用 HTTPS 保護 Ingress
GKE Ingress 可保護用戶端與應用程式負載平衡器之間的流量，以及從負載平衡器到應用程式 Pod 的流量。
設定用戶端與負載平衡器之間的 TLS
HTTP(S) 負載平衡器是用戶端與應用程式間的 Proxy。如果要接受來自用戶端的 HTTPS 要求，負載平衡器必須要有憑證，以向用戶端證明其身分。負載平衡器還必須要有私密金鑰才能完成 HTTPS 握手。
負載平衡器接受用戶端的 HTTPS 要求時，用戶端與負載平衡器之間的流量會使用 TLS 加密。不過，負載平衡器會終止 TLS 加密，並將未加密的要求轉送至應用程式。詳情請參閱「設定負載平衡器與應用程式之間的加密」。
提供 SSL 憑證的方法
您可以透過下列方法，為 HTTP(S) 負載平衡器提供 SSL 憑證：
Google 代管憑證：Google 為您的網域名稱佈建、更新及管理的網域驗證 (DV) 憑證。這些認證無法證明您個人或機構的身分。Google 代管憑證最多支援 100 個非萬用字元網域。詳情請參閱「使用 Google 代管的憑證」。
與 Google Cloud共用的自行管理憑證：您可以佈建自己的 SSL 憑證，並在 Google Cloud 專案中建立憑證資源。然後在 Ingress 的註解中列出憑證資源，建立使用該憑證的 HTTP(S) 負載平衡器。詳情請參閱「使用預先共用的憑證」。
使用 Kubernetes Secret 的自行管理憑證：您可以自行佈建 SSL 憑證，並建立 Secret 來保存憑證。接著，您可以在 Ingress 資訊清單的
tls欄位中參照 Secret，建立 HTTP(S) 負載平衡器。詳情請參閱「使用 Kubernetes Secret」。
使用多個憑證提供 HTTPS 流量
您可以設定應用程式負載平衡器，向用戶端出示最多 15 個 TLS 憑證。如要從多個主機名稱提供內容，且每個主機名稱都需要不同的憑證 (例如，your-store.example 和 your-experimental-store.example 各自需要不同的憑證)，就必須使用多個憑證。您可以在 Ingress 資訊清單中指定這些多個憑證。
憑證選取和優先順序
負載平衡器會使用伺服器名稱指示 (SNI)，判斷要向用戶端提供哪個憑證。
如果用戶端使用 SNI，或使用的網域名稱與其中一個可用憑證中的一般名稱 (CN) 相符，負載平衡器會使用 CN 與用戶端要求的主機名稱最相符的憑證。
如果用戶端不支援 SNI，或要求的網域名稱與任何可用憑證的 CN 不符，負載平衡器會使用 Ingress 資訊清單中列出的第一個憑證做為預設憑證。負載平衡器會根據下列規則選擇憑證：
tls區塊中列出的 Secret：主要憑證是tls區塊中的第一個 Secret。- 如果是
pre-shared-cert註解中的預先共用憑證，主要憑證是註解中列出的第一個憑證。 - 對於
managed-certificates註解中 Google 代管的憑證：所有代管憑證都會依名稱的字母順序排序。主要憑證是這個字母排序清單中的第一個憑證。如要將特定憑證設為主要憑證，請相應命名ManagedCertificate物件，以控管排列順序。舉例來說，如要讓my-default-cert優先於another-cert，您可以將兩者分別命名為0-my-default-cert和1-another-cert。
如果負載平衡器透過不同的 GKE 方法提供多個憑證，預先共用的憑證會優先於 Ingress tls 區塊中列出的 Secret。
下圖顯示負載平衡器如何根據要求中使用的網域名稱，將流量傳送至不同後端：
憑證輪替最佳做法
如要輪替 Secret 或預先共用憑證的內容，請參考下列最佳做法：
- 建立新的 Secret 或預先共用憑證，並使用其他名稱，其中包含新的憑證資料。更新 Ingress，使用新的憑證資源。
- 如果不在意流量中斷，可以從 Ingress 移除舊資源，以相同名稱但不同內容佈建新資源，然後重新附加至 Ingress。
如要避免自行管理憑證輪替，請使用 Google 代管的 SSL 憑證。
強制執行僅限 HTTPS 的流量
如要讓用戶端和 HTTP(S) 負載平衡器之間的所有流量都使用 HTTPS，您可以在 Ingress 資訊清單中加入 kubernetes.io/ingress.allow-http 註解，並將值設為 "false"，藉此停用 HTTP。詳情請參閱「停用 HTTP」。
設定負載平衡器和應用程式之間的加密
本節說明如何保護負載平衡器與應用程式 Pod 之間的連線。
啟用 HTTPS 或 HTTP/2 後端通訊協定
外部應用程式負載平衡器會做為用戶端與 GKE 應用程式之間的 Proxy。雖然用戶端可以使用 HTTPS (用於加密) 和各種通訊協定 (HTTP/1.1 或 HTTP/2) 連線至負載平衡器，但負載平衡器與後端 Pod 的連線預設為未加密的 HTTP/1.1。
如果應用程式可以處理更進階的設定，您可以手動更新外部應用程式負載平衡器，改用下列項目：
- HTTP/2：如果 Pod 支援，可藉此提升效能。
- HTTPS (TLS)：強制執行負載平衡器 Proxy 與 Pod 之間的流量端對端加密。
您可以在 Kubernetes 服務資訊清單中使用 cloud.google.com/app-protocols 註解，控管後端連線使用的通訊協定 (HTTP 或 HTTPS) 和 HTTP 版本 (HTTP/1.1 或 HTTP/2)。除非您使用容器原生負載平衡，否則這個 Service 資訊清單必須包含 type: NodePort。如果您使用容器原生負載平衡，請使用 type: ClusterIP。
HTTPS 負載平衡器的靜態 IP 位址
為外部應用程式負載平衡器建立 Ingress 物件時，您會取得穩定的外部 IP 位址，用戶端可使用該位址存取服務，進而存取執行中的容器。IP 位址在 Ingress 物件的生命週期內保持不變。刪除 Ingress 再從同一份資訊清單檔案建立新的 Ingress，並不能保證會獲得相同的外部 IP 位址。
如要取得永久 IP 位址，在刪除 Ingress 並建立新 Ingress 後仍維持不變，請預留全域靜態外部 IP 位址。然後在 Ingress 資訊清單中加入註解，提供保留的靜態 IP 位址名稱。如果您修改現有的 Ingress，改用靜態 IP 位址而非臨時 IP 位址，GKE 可能會在重新建立負載平衡器的轉送規則時，變更負載平衡器的 IP 位址。
轉送流量
GKE Ingress 會使用網址對應，定義如何將傳入要求轉送至特定後端服務。您可以根據主機名稱、網址路徑或兩者的組合設定路由規則，透過單一負載平衡器管理多個應用程式的流量。
多項後端服務
每個外部或內部應用程式負載平衡器都會使用單一網址對應，該對應會參照一或多個後端服務。每個後端服務都對應至 Ingress 參照的每個 Service。
舉例來說，您可以設定負載平衡器，使其根據 URL 路徑，將請求轉送到不同的後端服務。傳送到 your-store.example 的要求可以轉送到顯示原價商品的後端服務，傳送到 your-store.example/discount 的要求可以轉送到顯示折扣商品的後端服務。
您也可以設定負載平衡器，根據主機名稱轉送要求。讓傳送到 your-store.example 的要求前往某個後端服務，而傳送到 your-experimental-store.example 的要求前往另一個後端服務。
在 GKE 叢集中，您可以透過建立 Kubernetes Ingress 物件，來建立和設定 HTTP(S) 負載平衡器。Ingress 物件必須與一或多個 Service 物件關聯，而每個 Service 物件都會與一組 pod 關聯。
如要為同一主機設定具有多個後端的 GKE Ingress，您必須建立單一規則，其中包含單一主機和多個路徑。否則，GKE Ingress 控制器只會佈建一項後端服務
以下是名為 my-ingress 的 Ingress 資訊清單：
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: my-ingress spec: rules: - host: your-store.example http: paths: - path: /products pathType: ImplementationSpecific backend: service: name: my-products port: number: 60000 - path: /discounted pathType: ImplementationSpecific backend: service: name: my-discounted-products port: number: 80
建立 Ingress 時，GKE Ingress 控制器會根據 Ingress 和相關聯服務中的資訊，建立並設定外部應用程式負載平衡器或內部應用程式負載平衡器。此外，負載平衡器會取得穩定的 IP 位址，您可以將該位址與網域名稱建立關聯。
上述範例假設您已將負載平衡器的 IP 位址與網域名稱 your-store.example 關聯。當用戶端傳送要求至 your-store.example/products 時，要求會路由至通訊埠 60000 上名為 my-products 的 Kubernetes Service。當用戶端向 your-store.example/discounted 傳送要求時，要求會轉送至通訊埠 80 上名為 my-discounted-products 的 Kubernetes Service。
Ingress 的 path 欄位僅支援 * 字元做為萬用字元。* 字元必須接在正斜線 (/) 後方，且必須是模式中的最後一個字元。舉例來說，/*、/foo/* 和 /foo/bar/* 是有效模式，但 *、/foo/bar* 和 /foo/*/bar 則不是。
較明確的模式會優先於較不明確的模式。如果您同時有 /foo/* 和 /foo/bar/*，系統會將 /foo/bar/bat 視為與 /foo/bar/* 相符。
如要進一步瞭解路徑限制和模式比對，請參閱網址對應說明文件。
my-products 服務的資訊清單可能如下所示：
apiVersion: v1 kind: Service metadata: name: my-products spec: type: NodePort selector: app: products department: sales ports: - protocol: TCP port: 60000 targetPort: 50000
請注意上述資訊清單中的下列事項：
spec.type欄位取決於您使用的負載平衡方法：selector欄位表示，任何同時具有app: products標籤和department: sales標籤的 Pod，都是這項 Service 的成員。當要求傳入通訊埠 60000 上的 Service 時，會轉送至在 TCP 通訊埠 50000 上的其中一個成員 pod。
每個成員 Pod 都必須有一個容器監聽 TCP 通訊埠 50000。
my-discounted-products 服務的資訊清單可能如下所示：
apiVersion: v1 kind: Service metadata: name: my-discounted-products spec: type: NodePort selector: app: discounted-products department: sales ports: - protocol: TCP port: 80 targetPort: 8080
請注意上述資訊清單中的下列事項：
selector欄位表示，任何同時具有app: discounted-products標籤和department: sales標籤的 Pod，都是這項 Service 的成員。當要求傳入在通訊埠 80 上的 Service 時，會轉送至在 TCP 通訊埠 8080 上的其中一個成員 pod。
每個成員 Pod 都必須有一個容器監聽 TCP 通訊埠 8080。
預設後端
您可以在 Ingress 資訊清單中提供 spec.defaultBackend 欄位，為 Ingress 指定預設後端。這會處理與 rules 欄位中定義的路徑不符的任何要求。舉例來說，在下列 Ingress 中，任何不符合 /discounted 的要求都會傳送至 60001 連接埠上名為 my-products 的服務。
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: my-ingress
spec:
defaultBackend:
service:
name: my-products
port:
number: 60001
rules:
- http:
paths:
- path: /discounted
pathType: ImplementationSpecific
backend:
service:
name: my-discounted-products
port:
number: 80
如未指定預設後端，GKE 會提供傳回 404 的預設後端。這會在 kube-system 命名空間的叢集上建立為 default-http-backend NodePort 服務。
404 HTTP 回應類似於下列內容：
response 404 (backend NotFound), service rules for the path non-existent
如要使用自訂預設後端設定 GKE Ingress，請參閱「使用自訂預設後端的 GKE Ingress」。
健康狀態檢查
使用預設 Ingress 控制器透過 Ingress 公開一或多項服務時，GKE 會建立傳統型應用程式負載平衡器或內部應用程式負載平衡器。這兩種負載平衡器都支援單一網址對應上的多個後端服務。每個後端服務都對應至 Kubernetes 服務，且每個後端服務都必須參照Google Cloud 健康狀態檢查。這項健康狀態檢查不同於 Kubernetes 活躍性或完備性探測，因為健康狀態檢查是在叢集外部實作。
負載平衡器健康狀態檢查是依後端服務指定。雖然可以為負載平衡器的所有後端服務使用相同的健康狀態檢查，但系統不會為整個負載平衡器 (在 Ingress 物件本身) 指定健康狀態檢查參照。
GKE 會根據下列其中一種方法建立健康狀態檢查：
BackendConfigCRD：自訂資源定義 (CRD)，可讓您精確控管 Service 與負載平衡器的互動方式。您可以透過BackendConfigCRD，為與對應後端服務相關聯的健康狀態檢查指定自訂設定。這些自訂設定可讓您更靈活地控制 Ingress 建立的傳統版和內部應用程式負載平衡器健康狀態檢查。- Readiness 探測：這項診斷檢查會判斷 Pod 內的容器是否已準備好處理流量。GKE Ingress 控制器會根據 Service 的服務 Pod 使用的 readiness 探測，為 Service 的後端服務建立健康狀態檢查。您可以從就緒探測器定義衍生健康狀態檢查參數，例如路徑、通訊埠和通訊協定。
- 預設值：未設定
BackendConfigCRD 或定義就緒探查屬性時使用的參數。
使用 BackendConfig CRD，即可充分掌控負載平衡器健康狀態檢查設定。
GKE 會使用下列程序，為對應 Kubernetes 服務的每個後端服務建立健康狀態檢查：
如果 Service 參照具有
healthCheck資訊的BackendConfigCRD，GKE 會使用該資訊建立健康狀態檢查。GKE Enterprise Ingress 控制器和 GKE Ingress 控制器都支援以這種方式建立健康狀態檢查。如果服務未參照
BackendConfigCRD：如果服務 Pod 使用的 Pod 範本含有容器，且該容器的就緒探針具有可解讀為健康狀態檢查參數的屬性，GKE 就能推斷部分或所有健康狀態檢查參數。如需實作詳細資料，請參閱「readiness 探測的參數」；如需可用於建立健康狀態檢查參數的屬性清單，請參閱「預設和推論參數」。只有 GKE Ingress 控制器支援從就緒探查推斷參數。
如果 Service 服務 Pod 的 Pod 範本沒有容器，且容器具有就緒探測，其屬性可解讀為健康狀態檢查參數，則會使用預設值建立健康狀態檢查。GKE Enterprise Ingress 控制器和 GKE Ingress 控制器都能只使用預設值建立健康狀態檢查。
預設和推斷參數
如果您「未」使用 BackendConfig CRD 為對應的 Service 指定健康狀態檢查參數，系統會使用下列參數。
| 健康狀態檢查參數 | 預設值 | 可推斷的值 |
|---|---|---|
| 通訊協定 | HTTP | 如果服務註解 cloud.google.com/app-protocols 中有提供 |
| 要求路徑 | / |
如果服務 Pod 的 spec 中有這個欄位：containers[].readinessProbe.httpGet.path
|
| 要求主機標頭 | Host: backend-ip-address |
如果服務 Pod 的 spec 中有這個欄位：containers[].readinessProbe.httpGet.httpHeaders
|
| 預期回覆 | HTTP 200 (OK) | HTTP 200 (OK) 無法變更 |
| 檢查間隔 |
|
如果服務 Pod 的 spec 中有：
|
| 檢查逾時 | 5 秒 | 如果服務 Pod 的 spec 中有這個欄位：containers[].readinessProbe.timeoutSeconds |
| 健康狀態良好門檻 | 1 | 1 無法變更 |
| 不良健康狀態判定門檻 |
|
與預設值相同：
|
| 通訊埠規格 |
|
健康狀態檢查探測會傳送至 spec.containers[].readinessProbe.httpGet.port 指定的通訊埠編號，前提是下列所有條件都成立：
|
| 目的地 IP 位址 |
|
與預設值相同：
|
完備性探測的參數
當 GKE 為服務的後端服務建立健康狀態檢查時，GKE 可以從該服務提供 Pod 使用的其中一個容器的就緒探查中複製特定參數。這個選項僅適用於 GKE Ingress 控制器。
支援的 readiness 探測屬性可解讀為健康狀態檢查參數，並與預設值一起列於「預設和推論參數」中。如果未在就緒探測中指定任何屬性，或完全未指定就緒探測，系統會使用預設值。
如果服務的 Pod 包含多個容器，或您使用 GKE Enterprise Ingress 控制器，則應使用 BackendConfig CRD 定義健康狀態檢查參數。詳情請參閱「何時應改用 BackendConfig CRD」。
改用 BackendConfig CRD 的時機
在下列情況中，您應建立 Service 的 BackendConfig CRD，明確定義後端服務的健康狀態檢查參數，而非依據 Pod 準備狀態探查的參數：
如果您使用 GKE Enterprise：GKE Enterprise Ingress 控制器不支援從服務 Pod 的就緒探測器取得健康狀態檢查參數。只能使用隱含參數建立健康狀態檢查，或在
BackendConfigCRD 中定義健康狀態檢查。如果服務 Pod 中有多個容器： GKE 無法選取特定容器的就緒探針，藉此推斷健康狀態檢查參數。由於每個容器都可以有自己的就緒探測，且就緒探測並非容器的必要參數，因此您應在對應的 Service 上參照
BackendConfigCRD，為對應的後端服務定義健康狀態檢查。如要控管負載平衡器健康狀態檢查使用的通訊埠：只有在該通訊埠與 Ingress 參照的 Service
spec.rules[].http.paths[].backend.servicePort服務通訊埠相符時，GKE 才會使用就緒探查containers[].readinessProbe.httpGet.port進行後端服務健康狀態檢查。
BackendConfig CRD 的參數
您可以使用對應 Service 參照的 BackendConfig CRD healthCheck 參數，指定後端服務的健康狀態檢查參數。這樣一來，您就能更彈性地控管 Ingress 建立的傳統版或內部應用程式負載平衡器健康狀態檢查。如要瞭解 GKE 版本相容性，請參閱「Ingress 設定」。
這個範例 BackendConfig CRD 會在 spec.healthCheck 屬性中定義健康狀態檢查通訊協定 (類型)、要求路徑、通訊埠和檢查間隔：
apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
name: http-hc-config
spec:
healthCheck:
checkIntervalSec: 15
port: 15020
type: HTTPS
requestPath: /healthz
如要設定所有欄位，請使用設定 BackendConfig 健康狀態檢查時可用的欄位，請參閱自訂健康狀態檢查設定範例。
如要使用自訂 HTTP 健康狀態檢查設定 GKE Ingress，請參閱「使用自訂 HTTP 健康狀態檢查設定 GKE Ingress」。
Pod 完備性
使用上述任一方法設定負載平衡器的健康狀態檢查後，GKE Ingress 控制器會根據後端端點的健康狀態，判斷 Pod 是否就緒，這對於管理滾動更新和整體流量穩定性至關重要。
對於相關 Pod，對應的 Ingress 控制器會管理 cloud.google.com/load-balancer-neg-ready 類型的就緒閘道。Ingress 控制器會輪詢負載平衡器的健康狀態檢查狀態，包括 NEG 中所有端點的健康狀態。如果負載平衡器的健康狀態檢查結果顯示，特定 Pod 對應的端點健康狀態良好，Ingress 控制器會將 Pod 的 readiness gate 值設為 True。每個節點上執行的 kubelet 接著會計算 Pod 的有效就緒狀態，同時考量這個就緒閘的值，以及 Pod 的就緒探查 (如有定義)。
透過 Ingress 使用容器原生負載平衡功能時，系統會自動啟用 Pod 準備就緒閘道。
完備性門檻會控制滾動式更新的速率。啟動滾動式更新時，GKE 會建立新的 Pod，並將每個新 Pod 的端點新增至 NEG。從負載平衡器的角度來看，如果端點健康狀態良好，Ingress 控制器會將就緒閘道設為 True。新建立的 Pod 至少須通過就緒閘道，GKE 才能移除舊 Pod。這有助於確保 Pod 的對應端點已通過負載平衡器的健康狀態檢查，並維持後端容量。
如果 Pod 的完備性門檻並未顯示 Pod 已準備就緒，可能是因為容器映像檔錯誤，或是負載平衡器健康狀態檢查設定錯誤，導致負載平衡器未將流量導向新 Pod。如果在推出更新後的 Deployment 時發生故障，在嘗試建立新的 Pod 後，因為該 Pod 的完備性門檻永遠不會為 True，所以會暫停推出。如要瞭解如何偵測並修正這種狀況，請參閱疑難排解一節。
在缺少容器原生負載平衡和完備性門檻的情況下，GKE 在將 Pod 標記為準備就緒之前，無法偵測到負載平衡器的端點是否處於健康狀態。在先前的 Kubernetes 版本中，您可以指定延遲期間 (Deployment 規格中的 minReadySeconds) 來控制 Pod 移除和替換的速率。
如果符合下列任一條件，GKE 會將 Pod 的 cloud.google.com/load-balancer-neg-ready 值設為 True：
- Pod 的 IP 位址都不是 GKE 控制層管理的
GCE_VM_IP_PORTNEG 端點。 - Pod 的一或多個 IP 位址是 GKE 控制層管理的
GCE_VM_IP_PORTNEG 中的端點。NEG 會附加至後端服務。後端服務已通過負載平衡器健康狀態檢查。 - Pod 的一或多個 IP 位址是 GKE 控制層管理的
GCE_VM_IP_PORTNEG 中的端點。NEG 已附加至後端服務。後端服務的負載平衡器健康狀態檢查逾時。 - 一或多個 Pod 的 IP 位址是其中一或多個 NEG 的端點。
GCE_VM_IP_PORT沒有任何 NEG 附加至後端服務。 沒有可用的負載平衡器健康狀態檢查資料。
WebSocket 的支援
使用外部應用程式負載平衡器時，WebSocket 通訊協定無需任何設定即可運作。
如果您打算使用 WebSocket 通訊協定，則可能需要使用大於預設值 30 秒的逾時值。如果是透過Google Cloud 外部應用程式負載平衡器傳送的 WebSocket 流量，後端服務逾時時間會解讀為 WebSocket 連線可保持開啟的最長時間，無論是否閒置。
如要為後端服務設定逾時值，請參閱「後端回應逾時」。
進階網路情境
GKE Ingress 支援進階網路設定，例如跨專案共用網路資源，以及使用自訂 Ingress 控制器。
Shared VPC
Shared VPC 支援 Ingress 和 MultiClusterIngress 資源，但需要額外準備。
Ingress 控制器會在 GKE 控制層上執行，並使用叢集專案的 GKE 服務帳戶，向 Google Cloud 發出 API 呼叫。根據預設，當位於 Shared VPC 服務專案的叢集使用虛擬私有雲網路時，Ingress 控制器無法使用服務專案的 GKE 服務帳戶，在主專案中建立及更新 Ingress 允許防火牆規則。
您可以授予服務專案的 GKE 服務帳戶權限，在主專案中建立及管理 VPC 防火牆規則。授予這些權限後，GKE 會建立輸入允許防火牆規則，用於下列項目：
外部應用程式負載平衡器用於外部 Ingress 的 Google Front End (GFE) Proxy 和健康狀態檢查系統。詳情請參閱「外部應用程式負載平衡器總覽」。
內部 Ingress 使用的內部應用程式負載平衡器健康狀態檢查系統。
從主專案手動佈建防火牆規則
如果安全政策只允許從主專案管理防火牆，您可以手動佈建這些防火牆規則。在 Shared VPC 中部署 Ingress 時，Ingress 資源事件會提供必要的特定防火牆規則，以便提供存取權。
如要手動佈建規則，請按照下列步驟操作：
查看 Ingress 資源事件：
kubectl describe ingress INGRESS_NAME將 INGRESS_NAME 替換為 Ingress 名稱。
您會看到類似以下範例的輸出內容：
Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Sync 9m34s (x237 over 38h) loadbalancer-controller Firewall change required by security admin: `gcloud compute firewall-rules update k8s-fw-l7--6048d433d4280f11 --description "GCE L7 firewall rule" --allow tcp:30000-32767,tcp:8080 --source-ranges 130.211.0.0/22,35.191.0.0/16 --target-tags gke-l7-ilb-test-b3a7e0e5-node --project <project>`建議的必要防火牆規則會顯示在「
Message」欄中。從主專案複製並套用建議的防火牆規則。套用規則後，負載平衡器和Google Cloud 健康狀態檢查工具就能存取 Pod。
授予 Ingress 控制器管理主專案防火牆規則的權限
如要讓服務專案中的 GKE 叢集在主專案中建立及管理防火牆資源，請使用下列其中一種策略，授予服務專案的 GKE 服務帳戶適當的 IAM 權限：
將Compute Security Admin 角色授予服務專案的 GKE 服務帳戶。以下範例說明這項策略。
如要採用更精細的做法，請建立自訂 IAM 角色，並僅加入下列權限：
compute.networks.updatePolicy、compute.firewalls.list、compute.firewalls.get、compute.firewalls.create、compute.firewalls.update、compute.firewalls.delete和compute.subnetworks.list。將服務專案的自訂角色授予主專案的 GKE 服務帳戶。
如果有多個服務專案的叢集，您必須選擇其中一種策略，並針對每個服務專案的 GKE 服務帳戶重複執行。
gcloud projects add-iam-policy-binding HOST_PROJECT_ID \
--member=serviceAccount:service-SERVICE_PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com \
--role=roles/compute.securityAdmin
更改下列內容：
HOST_PROJECT_ID：Shared VPC 主專案的專案 ID。SERVICE_PROJECT_NUMBER：包含叢集的服務專案的專案編號。
使用自訂 Ingress 控制器
您可以停用 HttpLoadBalancing 外掛程式，執行自訂 Ingress 控制器。這可防止 GKE Ingress 控制器處理 Ingress 資源。
如要執行啟用 HttpLoadBalancing 外掛程式的自訂 Ingress 控制器 (例如使用子集和 Private Service Connect 等功能)，可以採用下列其中一種方法：
- 在 Ingress 資訊清單中，設定
kubernetes.io/ingress.class註解。這項設定適用於執行所有 GKE 版本的叢集。 - 設定
ingressClassName欄位。 - 設定預設 Ingress 類別。
您必須確保 spec.ingressClassName 不會意外遭到任何程序覆寫。如果更新作業將 spec.IngressClassName 從有效值變更為空字串 ("")，GKE Ingress 控制器就會處理 Ingress。
設定 ingressClassName 欄位
您可以在 Ingress 資訊清單中設定 ingressClassName 欄位，使用自訂 Ingress 控制器。下列資訊清單描述指定 cilium Ingress 控制器的 Ingress：
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: cafe-ingress
spec:
ingressClassName: cilium
tls:
- hosts:
- cafe.example.com
secretName: cafe-secret
rules:
- host: cafe.example.com
設定預設 Ingress 類別
如要為叢集中的所有 Ingress 資源設定預設 Ingress 類別，請建立 IngressClass 資源，並將註解 ingressclass.kubernetes.io/is-default-class 設為 true：
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
name: gce
annotations:
ingressclass.kubernetes.io/is-default-class: "true"
spec:
controller: k8s.io/ingress-gce
GKE Ingress 控制器行為摘要
如果叢集執行 GKE 1.18 以上版本，GKE Ingress 控制器是否處理 Ingress，取決於 Ingress 資訊清單中的 kubernetes.io/ingress.class 註解值和 ingressClassName 欄位。詳情請參閱「GKE Ingress 控制器行為」。
Ingress 設定範本
- 在 GKE 網路食譜的「Ingress」部分，您可以找到 GKE 提供的範本，瞭解許多常見的 Ingress 用法。