本頁面說明 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 憑證的方法
您可以透過下列方法，將 SSL 憑證提供給 HTTP(S) 負載平衡器：
Google 代管的憑證：這些是網域驗證 (DV) 憑證，由 Google 佈建、更新及管理您的網域名稱。這些憑證無法證明您個人或機構的身分。Google 代管憑證最多支援 100 個非萬用字元網域。詳情請參閱「使用 Google 代管的憑證」。
與 Google Cloud共用的自行管理憑證：您可以佈建自己的 SSL 憑證，並在 Google Cloud 專案中建立憑證資源。接著，您可以在 Ingress 上的註解中列出憑證資源，以建立使用該憑證的 HTTP(S) 負載平衡器。詳情請參閱「使用預先共用憑證」。
使用 Kubernetes Secret 的自行管理憑證：您可以佈建自己的 SSL 憑證，並建立 Secret 來保存憑證。接著，您就可以參閱 Ingress 資訊清單的
tls欄位中的密鑰，以建立 HTTP(S) 負載平衡器。詳情請參閱「使用 Kubernetes Secret」。
使用多個憑證服務 HTTPS 流量
您可以設定應用程式負載平衡器，向用戶端顯示最多 15 個 TLS 憑證。如要從多個主機名稱提供內容，且每個主機名稱都需要不同的憑證 (例如，your-store.example 和 your-experimental-store.example 各自需要不同的憑證)，就必須使用多個憑證。您可以在 Ingress 資訊清單中指定多個憑證。
憑證選取和優先順序
負載平衡器會使用伺服器名稱指示 (SNI)，判斷要向用戶端呈現哪些憑證。
如果用戶端使用 SNI，或使用的網域名稱與其中一個可用憑證的常用名稱 (CN) 相符，負載平衡器就會使用 CN 與用戶端要求的主機名稱最相符的憑證。
如果用戶端不支援 SNI，或要求的網域名稱與任何可用憑證的 CN 不符，負載平衡器會使用 Ingress 資訊清單中列出的第一個憑證做為預設憑證。負載平衡器會根據下列規則選擇這個憑證：
- 針對
tls區塊中列出的密鑰：主要憑證是tls區塊中的第一個密鑰。 - 針對
pre-shared-cert註解中的預先共用憑證，主要憑證是註解中列出的第一個憑證。 managed-certificates註解中的 Google 代管憑證：所有代管憑證都會依名稱字母順序排序。主要憑證是這個字母排序清單中的第一個憑證。如要將特定憑證設為主要憑證，您必須相應命名ManagedCertificate物件，以控管排序順序。舉例來說，如要將my-default-cert設為主要項目，而非another-cert，您可以將兩者分別命名為0-my-default-cert和1-another-cert。
- 針對
負載平衡器透過不同的 GKE 方法提供多個憑證時，預先共用的憑證會優先於 Ingress tls 區塊中列出的密鑰。
下圖顯示負載平衡器如何根據要求中使用的網域名稱，將流量傳送至不同後端：
憑證輪替最佳做法
如要輪替 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)。除非使用容器原生負載平衡，否則這個服務資訊清單必須包含 type: NodePort。如果您使用容器原生負載平衡，請使用 type: ClusterIP。
HTTPS 負載平衡器的靜態 IP 位址
為外部應用程式負載平衡器建立 Ingress 物件時，您會取得一個穩定的外部 IP 位址，用戶端可以使用該位址存取您的 Service，並存取您正在執行的容器。這個 IP 位址在 Ingress 物件的整個生命週期中會持續存在，因此可說是相當穩定。刪除 Ingress 再從同一份資訊清單檔案建立新的 Ingress，並不能保證會獲得相同的外部 IP 位址。
如果您想在刪除 Ingress 後再建立新的 Ingress 時，IP 位址都能保持不變 (永久 IP 位址)，則必須保留一個全域靜態外部 IP 位址。然後在您的 Ingress 資訊清單中加入一個註解，提供您保留的靜態 IP 位址名稱。如果您修改現有 Ingress，改為使用靜態 IP 位址而非臨時 IP 位址，GKE 重新建立負載平衡器的轉送規則時，可能會變更負載平衡器的 IP 位址。
轉送流量
GKE Ingress 會使用網址對應，定義如何將連入要求轉送至特定後端服務。您可以根據主機名稱、網址路徑或兩者的組合設定轉送規則，透過單一負載平衡器管理多個應用程式的流量。
多項後端服務
每個外部或內部應用程式負載平衡器都會使用單一網址對應，該網址對應會參照一或多個後端服務。每個後端服務都對應至 Ingress 參照的每個服務。
舉例來說，您可以設定負載平衡器，使其根據 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 輸入控制器只會佈建一個後端服務
以下是名為 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 和關聯的 Service 中的資訊，建立和設定外部或內部應用程式負載平衡器。同時，系統會給負載平衡器一個穩定的 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 Service 的資訊清單看起來可能像這樣：
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 Service 的資訊清單看起來可能像這樣：
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-backendNodePort 服務的形式建立。
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)，可精確控管服務與負載平衡器的互動方式。BackendConfigCRD 可讓您為與對應後端服務相關聯的健康狀態檢查指定自訂設定。這些自訂設定可讓您更彈性地控管 Ingress 建立的傳統版應用程式負載平衡器和內部應用程式負載平衡器的健康狀態檢查。- Readiness 探測：診斷檢查，判斷 Pod 內的容器是否準備好處理流量。GKE Ingress 控制器會根據該 Service 服務 Pod 使用的就緒探測器，為 Service 的後端服務建立健康狀態檢查。您可以從就緒探測器定義衍生健康狀態檢查參數，例如路徑、通訊埠和通訊協定。
- 預設值：未設定
BackendConfigCRD 或定義就緒探查屬性時使用的參數。
使用 BackendConfig CRD，盡可能控管負載平衡器健康狀態檢查設定。
GKE 會使用下列程序，為 Kubernetes 服務對應的每個後端服務建立健康狀態檢查：
如果 Service 參照含有
healthCheck資訊的BackendConfigCRD，GKE 會使用該資訊建立健康狀態檢查。GKE Enterprise Ingress 控制器和 GKE Ingress 控制器都支援以這種方式建立健康狀態檢查。如果 Service 未參照
BackendConfigCRD：
預設和推斷參數
如果您「未」使用 BackendConfig
CRD 為對應的服務指定健康狀態檢查參數，系統就會使用下列參數。
| 健康狀態檢查參數 | 預設值 | 可推斷的值 |
|---|---|---|
| 通訊協定 | 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 為 Service 的後端服務建立健康狀態檢查時，GKE 可以從該 Service 服務 Pod 使用的其中一個容器完備性探測器複製特定參數。這個選項僅適用於 GKE Ingress 控制器。
如要查看可解讀為健康狀態檢查參數的支援就緒探查屬性，請參閱「預設和推斷參數」一節，其中列出這些屬性和預設值。如果就緒探查中未指定任何屬性，或您完全未指定就緒探查，系統就會使用預設值。
如果 Service 的服務 Pod 包含多個容器，或是使用 GKE Enterprise Ingress 控制器，則應使用 BackendConfig CRD 定義健康狀態檢查參數。詳情請參閱「何時改用 BackendConfig CRD」。
改用 BackendConfig CRD 的時機
在下列情況中，您應建立 Service 的 BackendConfig CRD，明確定義後端服務的健康狀態檢查參數，而非依據 Pod 準備狀態探測的參數：
如果您使用 GKE Enterprise：GKE Enterprise 輸入控制器「不」支援從服務 Pod 的就緒探測器取得健康狀態檢查參數。只能使用隱含參數建立健康狀態檢查，或在
BackendConfigCRD 中定義。如果服務 Pod 中有多個容器： GKE 無法從特定容器選取就緒探針，藉此推斷健康狀態檢查參數。由於每個容器都可以有自己的就緒探測，且就緒探測並非容器的必要參數，因此您應透過參照對應服務的
BackendConfigCRD，為對應的後端服務定義健康狀態檢查。如要控管負載平衡器健康狀態檢查所用的通訊埠：只有當該通訊埠與 Ingress 參照的 Service 的服務通訊埠相符時，GKE 才會使用就緒探查的
containers[].readinessProbe.httpGet.port做為後端服務的健康狀態檢查。spec.rules[].http.paths[].backend.servicePort
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 的完備性門檻值設為 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_PORT網路端點群組中。NEG 會附加至後端服務。後端服務已通過負載平衡器健康狀態檢查。 - Pod 的一或多個 IP 位址是端點，位於由 GKE 控制層管理的
GCE_VM_IP_PORT網路端點群組中。NEG 已附加至後端服務。後端服務的負載平衡器健康狀態檢查逾時。 - 一或多個 Pod 的 IP 位址是其中一或多個 NEG 的端點。
GCE_VM_IP_PORT沒有任何 NEG 附加至後端服務。 沒有可用的負載平衡器健康狀態檢查資料。
WebSocket 的支援
使用外部應用程式負載平衡器時，WebSocket 通訊協定無需任何設定即可運作。
如果您打算使用 WebSocket 通訊協定，則可能需要使用大於預設值 30 秒的逾時值。對於透過Google Cloud 外部應用程式負載平衡器傳送的 WebSocket 流量，後端服務逾時會被解讀為 WebSocket 連線可保持開啟的最長時間 (無論是否閒置)。
如要設定後端服務的逾時值，請參閱「後端回應逾時」。
進階網路情境
GKE Ingress 支援進階網路設定，例如跨專案共用網路資源，以及使用自訂 Ingress 控制器。
共用虛擬私有雲
在共用虛擬私有雲中支援 Ingress 和 MultiClusterIngress 資源，但需要額外準備。
輸入控制器會在 GKE 控制層上執行，並使用叢集專案的 GKE 服務帳戶，向 Google Cloud 發出 API 呼叫。根據預設，當位於共用虛擬私有雲服務專案中的叢集使用共用虛擬私有雲網路時，Ingress 控制器無法使用服務專案的 GKE 服務帳戶，在主專案中建立及更新 Ingress 允許防火牆規則。
您可以授予服務專案的 GKE 服務帳戶權限，在主專案中建立及管理 VPC 防火牆規則。授予這些權限後，GKE 會為下列項目建立允許連入的防火牆規則：
外部應用程式負載平衡器用於外部 Ingress 的 Google 前端 (GFE) 代理伺服器和健康狀態檢查系統。詳情請參閱「外部應用程式負載平衡器總覽」。
內部 Ingress 使用的內部應用程式負載平衡器健康狀態檢查系統。
從主專案手動佈建防火牆規則
如果安全政策只允許從主專案管理防火牆，您可以手動佈建這些防火牆規則。在共用虛擬私有雲中部署 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 叢集在主專案中建立及管理防火牆資源，請使用下列其中一種策略，將適當的 IAM 權限授予服務專案的 GKE 服務帳戶：
將運算安全管理員角色授予主專案的服務專案 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 控制器，請在 Ingress 資訊清單中設定 ingressClassName
欄位。下列資訊清單說明 Ingress，其中指定了 cilium 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 用法。