輸入設定

總覽

本頁面提供完整總覽，說明您可以在Google Cloud上透過 Kubernetes Ingress 設定哪些項目。本文也比較了Google Cloud 上 Ingress 支援的功能，並說明如何使用預設控制器、FrontendConfig 參數和 BackendConfig 參數設定 Ingress。

本頁面適用於網路專家，他們負責為機構設計及建構網路，並安裝、設定及支援網路設備。如要進一步瞭解我們在Google Cloud 內容中提及的常見角色和範例工作，請參閱「常見的 GKE Enterprise 使用者角色和工作」。

功能比較

下表列出 Ingress 在 Google Cloud上支援的功能。 此外，也會顯示功能正式版或 Beta 版的推出狀態。

^B這項功能已推出 Beta 版，適用於指定版本。如果功能未列出版本，表示所有可用的 GKE 版本都支援該功能。

^G這項功能從指定版本開始支援正式發布版。

使用預設控制器設定 Ingress

您無法使用 Google Cloud SDK 或 Google Cloud 控制台手動設定 LoadBalancer 功能。您必須使用 BackendConfig 或 FrontendConfig Kubernetes 資源。

使用預設控制器建立 Ingress 時，您可以在 Ingress 物件上使用註解，選擇負載平衡器類型 (外部應用程式負載平衡器或內部應用程式負載平衡器)。您可以透過每個 Service 物件的註解，選擇 GKE 是否要建立區域性 NEG，或是使用執行個體群組。

FrontendConfig 和 BackendConfig 自訂資源定義 (CRD) 可讓您進一步自訂負載平衡器。這些 CRD 可讓您以比註解更結構化的方式，階層式定義其他負載平衡器功能。如要使用 Ingress (和這些 CRD)，必須啟用 HTTP 負載平衡外掛程式。根據預設，GKE 叢集已啟用 HTTP 負載平衡，不得停用該功能。

FrontendConfig 會在 Ingress 物件中參照，且只能搭配外部 Ingress 使用。BackendConfig 會由 Service 物件參照。多個 Service 或 Ingress 物件可以參照相同的 CRD，確保設定一致性。FrontendConfig 和 BackendConfig CRD 與對應的 Ingress 和 Service 資源共用相同生命週期，且通常會一併部署。

下圖說明如何：

• Ingress 或 MultiClusterIngress 物件上的註解會參照 FrontendConfig CRD。FrontendConfig CRD 會參照 Google Cloud SSL 政策。

• Service 或 MultiClusterService 物件的註解會參照 BackendConfig CRD。BackendConfig CRD 會為對應後端服務的健康狀態檢查指定自訂設定。

將 FrontendConfig 與 Ingress 建立關聯

FrontendConfig 只能搭配外部 Ingress 使用。

您可以將 FrontendConfig 與 Ingress 或 MultiClusterIngress 建立關聯。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    networking.gke.io/v1beta1.FrontendConfig: "FRONTENDCONFIG_NAME"
...

apiVersion: networking.gke.io/v1
kind: MultiClusterIngress
metadata:
  annotations:
    networking.gke.io/frontend-config: "FRONTENDCONFIG_NAME"
...

將 BackendConfig 與 Ingress 建立關聯

您可以使用 cloud.google.com/backend-config 或 beta.cloud.google.com/backend-config 註解指定 BackendConfig 的名稱。

所有服務通訊埠都使用相同的 BackendConfig

如要為所有通訊埠使用相同的 BackendConfig，請在註解中使用 default 鍵。每當 Ingress 控制器建立負載平衡器後端服務，以參照 Service 的其中一個通訊埠時，都會使用相同的 BackendConfig。

您可以使用 default 金鑰，同時用於 Ingress 和 MultiClusterIngress 資源。

apiVersion: v1
kind: Service
metadata:
  annotations:
    cloud.google.com/backend-config: '{"default": "my-backendconfig"}'
...

每個 Service 通訊埠都有專屬的 BackendConfig

對於 Ingress 和 MultiClusterIngress，您可以使用與通訊埠名稱或號碼相符的鍵，為一或多個通訊埠指定自訂 BackendConfig。Ingress 控制器為參照的 Service 通訊埠建立負載平衡器後端服務時，會使用特定的 BackendConfig。

apiVersion: v1
kind: Service
metadata:
  annotations:
    cloud.google.com/backend-config: '{"ports": {
    "SERVICE_REFERENCE_A":"BACKENDCONFIG_REFERENCE_A",
    "SERVICE_REFERENCE_B":"BACKENDCONFIG_REFERENCE_B"
    }}'
spec:
  ports:
  - name: PORT_NAME_1
    port: PORT_NUMBER_1
    protocol: TCP
    targetPort: 50000
  - name: PORT_NAME_2
    port: PORT_NUMBER_2
    protocol: TCP
    targetPort: 8080
...

apiVersion: v1
kind: Service
metadata:
  annotations:
    cloud.google.com/backend-config: '{"ports": {
      PORT_NAME_1:"BACKENDCONFIG_REFERENCE_A",
      PORT_NAME_2:"BACKENDCONFIG_REFERENCE_B"
    }}'
spec:
  ports:
  - name: PORT_NAME_1
    port: PORT_NUMBER_1
    protocol: TCP
    targetPort: 50000
  - name: PORT_NAME_2
    port: PORT_NUMBER_2
    protocol: TCP
    targetPort: 8080
...

更改下列內容：

• BACKENDCONFIG_REFERENCE_A：現有 BackendConfig 的名稱。
• BACKENDCONFIG_REFERENCE_B：現有 BackendConfig 的名稱。
• SERVICE_REFERENCE_A：使用 PORT_NUMBER_1 或 PORT_NAME_1 的值。 這是因為服務的 BackendConfig 註解可以參照通訊埠名稱 (spec.ports[].name) 或通訊埠編號 (spec.ports[].port)。
• SERVICE_REFERENCE_B：使用 PORT_NUMBER_2 或 PORT_NAME_2 的值。 這是因為服務的 BackendConfig 註解可以參照通訊埠名稱 (spec.ports[].name) 或通訊埠編號 (spec.ports[].port)。

如要以數字參照服務的通訊埠，請使用 port 值，而非 targetPort 值。這裡使用的通訊埠編號僅用於繫結 BackendConfig，不會控管負載平衡器傳送流量或健康狀態檢查探測器的通訊埠：

• 使用容器原生負載平衡時，負載平衡器會將流量傳送至網路端點群組中的端點 (與 Pod IP 位址相符)，位於參照服務通訊埠的 targetPort (必須與服務 Pod 的 containerPort 相符)。否則，負載平衡器會將流量傳送至參照服務通訊埠的節點 IP 位址 nodePort。

• 使用 BackendConfig 提供自訂負載平衡器健康狀態檢查時，負載平衡器健康狀態檢查使用的通訊埠號碼，可能與 Service 的 spec.ports[].port 號碼不同。如要進一步瞭解健康狀態檢查的通訊埠編號，請參閱自訂健康狀態檢查設定。

透過 FrontendConfig 參數設定 Ingress 功能

下一節說明如何設定 FrontendConfig，以啟用特定 Ingress 功能。

安全資料傳輸層 (SSL) 政策

您可以透過 SSL 政策指定一組 TLS 版本和密碼，供負載平衡器終止來自用戶端的 HTTPS 流量。您必須先在 GKE 外部建立 SSL 政策。建立完成後，您可以在 FrontendConfig CRD 中參照該物件。

FrontendConfig 中的 sslPolicy 欄位會參照與 GKE 叢集位於相同 Google Cloud 專案中的 SSL 政策名稱。這項作業會將 SSL 政策附加至 Ingress 為外部 HTTP(S) 負載平衡器建立的目標 HTTPS Proxy。多個 Ingress 資源可以參照相同的 FrontendConfig 資源和 SSL 政策。如果參照的 SSL 政策有所變更，系統會將變更內容傳播至 Google Front End (GFE)，這些 GFE 會為 Ingress 建立的外部 HTTP(S) 負載平衡器提供支援。

下列 FrontendConfig 資訊清單會啟用名為 gke-ingress-ssl-policy 的 SSL 政策：

apiVersion: networking.gke.io/v1beta1
kind: FrontendConfig
metadata:
  name: my-frontend-config
spec:
  sslPolicy: gke-ingress-ssl-policy

從 HTTP 重新導向至 HTTPS

外部 HTTP 負載平衡器可將未加密的 HTTP 要求重新導向至使用相同 IP 位址的 HTTPS 負載平衡器。建立 Ingress 時，如果啟用從 HTTP 重新導向至 HTTPS 的功能，系統會自動建立這兩個負載平衡器。系統會自動將通訊埠 80 上 Ingress 外部 IP 位址的要求，重新導向至通訊埠 443 上的相同外部 IP 位址。這項功能是以 Cloud Load Balancing 提供的 HTTP 到 HTTPS 重新導向為基礎。

如要支援 HTTP 至 HTTPS 的重新導向，必須將 Ingress 設定為同時處理 HTTP 和 HTTPS 流量。如果停用 HTTP 或 HTTPS，重新導向功能將無法運作。

HTTP 至 HTTPS 的重新導向是使用 FrontendConfig 自訂資源中的 redirectToHttps 欄位設定。系統會為整個 Ingress 資源啟用重新導向功能，因此 Ingress 參照的所有服務都會啟用 HTTPS 重新導向功能。

下列 FrontendConfig 資訊清單會啟用從 HTTP 重新導向至 HTTPS 的功能。將 spec.redirectToHttps.enabled 欄位設為 true，啟用 HTTPS 重新導向。spec.responseCodeName 為選填欄位。如果省略此欄位，系統會使用 301 Moved Permanently 重新導向。

apiVersion: networking.gke.io/v1beta1
kind: FrontendConfig
metadata:
  name: my-frontend-config
spec:
  redirectToHttps:
    enabled: true
    responseCodeName: RESPONSE_CODE

請將 RESPONSE_CODE 替換為下列其中一個值：

• MOVED_PERMANENTLY_DEFAULT，傳回 301 重新導向回應代碼 (如未指定 responseCodeName，則為預設值)。
• FOUND，傳回 302 重新導向回應代碼。
• SEE_OTHER，傳回 303 重新導向回應代碼。
• TEMPORARY_REDIRECT，傳回 307 重新導向回應代碼。
• PERMANENT_REDIRECT，傳回 308 重新導向回應代碼。

啟用重新導向後，Ingress 控制器會建立負載平衡器，如下圖所示：

如要驗證重新導向是否正常運作，請使用 curl 指令：

curl http://IP_ADDRESS

將 IP_ADDRESS 替換為 Ingress 的 IP 位址。

回應會顯示您設定的重新導向回應代碼。舉例來說，以下範例是為設定 301: MovedPermanently 重新導向的 FrontendConfig：

<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>301 Moved</TITLE></HEAD><BODY>
<H1>301 Moved</H1>
The document has moved
<A HREF="https://35.244.160.59/">here</A>.</BODY></HTML>

透過 BackendConfig 參數設定 Ingress 功能

以下各節說明如何設定 BackendConfig，以啟用特定 Ingress 功能。BackendConfig 資源的變更會持續進行調解，因此您不需要刪除及重新建立 Ingress，即可查看 BackendConfig 變更是否已反映。

如要瞭解 BackendConfig 限制，請參閱「限制」一節。

後端服務逾時

您可以使用 BackendConfig 設定後端服務逾時時間，以秒為單位。如未指定值，預設值為 30 秒。

下列 BackendConfig 資訊清單指定 40 秒的逾時時間：

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  timeoutSec: 40

Cloud CDN

您可以使用 BackendConfig 啟用 Cloud CDN。

下列 BackendConfig 資訊清單顯示啟用 Cloud CDN 時的所有可用欄位：

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  cdn:
    enabled: CDN_ENABLED
    cachePolicy:
      includeHost: INCLUDE_HOST
      includeProtocol: INCLUDE_PROTOCOL
      includeQueryString: INCLUDE_QUERY_STRING
      queryStringBlacklist: QUERY_STRING_DENYLIST
      queryStringWhitelist: QUERY_STRING_ALLOWLIST
    cacheMode: CACHE_MODE
    clientTtl: CLIENT_TTL
    defaultTtl: DEFAULT_TTL
    maxTtl: MAX_TTL
    negativeCaching: NEGATIVE_CACHING
    negativeCachingPolicy:
      code: NEGATIVE_CACHING_CODE
      ttl: NEGATIVE_CACHING_TTL
    requestCoalescing: REQ_COALESCING
    serveWhileStale: SERVE_WHILE_STALE
    signedUrlCacheMaxAgeSec: SIGNED_MAX_AGE
    signedUrlKeys:
      keyName: KEY_NAME
      keyValue: KEY_VALUE
      secretName: SECRET_NAME

更改下列內容：

• CDN_ENABLED：如果設為 true，系統會為這個 Ingress 後端啟用 Cloud CDN。
• INCLUDE_HOST：如果設為 true，系統會分別快取對不同主機的要求。
• INCLUDE_PROTOCOL：如果設為 true，系統會分別快取 HTTP 和 HTTPS 要求。
• INCLUDE_QUERY_STRING：如果設為 true，系統會根據 queryStringBlacklist 或 queryStringWhitelist 的值，將查詢字串參數包含在快取金鑰中。如果這兩個欄位都沒有設定，系統會將整個查詢字串包含在快取金鑰中。如果設為 false，整個查詢字串會從快取金鑰中排除。
• QUERY_STRING_DENYLIST：指定字串陣列，其中包含要從快取金鑰排除的查詢字串參數名稱。所有其他參數都會包含在內。 您可以指定 queryStringBlacklist 或 queryStringWhitelist，但不能兩者同時指定。
• QUERY_STRING_ALLOWLIST：指定字串陣列，其中包含要納入快取金鑰的查詢字串參數名稱。所有其他參數都會遭到排除。您可以選擇 queryStringBlacklist 或 queryStringWhitelist，但不能兩者同時指定。

只有在 GKE Ingress 中，使用 1.23.3-gke.900 以上版本的 GKE 時，才支援下列欄位。多叢集 Ingress 不支援下列功能：

• CACHE_MODE： 快取模式。
• CLIENT_TTL、DEFAULT_TTL 和 MAX_TTL：存留時間設定。詳情請參閱「使用存留時間設定和覆寫」。
• NEGATIVE_CACHING：如果設為 true，系統會啟用負向快取。詳情請參閱「使用負向快取」一文。
• NEGATIVE_CACHING_CODE 和 NEGATIVE_CACHING_TTL：負面快取設定。 詳情請參閱「使用負向快取」一文。
• REQ_COALESCING：如果設為 true，系統會啟用摺疊功能。詳情請參閱「要求摺疊 (合併)」。
• SERVE_WHILE_STALE：回應過期後，Cloud CDN 繼續提供舊版內容的時間 (以秒為單位)。詳情請參閱「提供過時內容」。
• SIGNED_MAX_AGE：回應可快取的最大時間 (以秒為單位)。詳情請參閱「自行選擇是否自訂快取時間上限」。
• KEY_NAME、KEY_VALUE 和 SECRET_NAME：已簽署網址金鑰設定。 詳情請參閱「建立簽署的要求金鑰」。

展開下列章節，查看透過 Ingress 部署 Cloud CDN，然後驗證應用程式內容是否已快取的範例。

curl -v ADDRESS/?cache=true

HTTP/1.1 200 OK
Date: Fri, 25 Jan 2019 02:34:08 GMT
Content-Length: 70
Content-Type: text/plain; charset=utf-8
Via: 1.1 google
Cache-Control: max-age=86400,public
Age: 2716

Hello, world!
Version: 1.0.0
Hostname: my-deployment-7f589cc5bc-l8kr8
...

gcloud compute addresses delete cdn-how-to-address --global

連線排除逾時

您可以使用 BackendConfig 設定「連線排除逾時」。連線排除逾時是指等待連線排除的時間 (以秒計算)。後端遭到移除之後，系統盡可能會在指定的逾時時間長度內完成傳送至該後端的現有要求。負載平衡器不會將新的要求傳送至已移除的後端。逾時時間長度屆滿之後，系統就會關閉所有剩餘的後端連線。逾時時間長度可介於 0 至 3,600 秒之間。預設值為 0，這也會停用連線排除功能。

下列 BackendConfig 資訊清單指定連線排除逾時為 60 秒：

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  connectionDraining:
    drainingTimeoutSec: 60

自訂健康狀態檢查設定

透過 Ingress 部署時，GKE 會以多種方式設定Google Cloud 負載平衡器健康檢查。如要進一步瞭解 GKE Ingress 如何部署健康狀態檢查，請參閱「Ingress 健康狀態檢查」。

BackendConfig 可讓您精確控管負載平衡器健康狀態檢查設定。

您可以將多個 GKE Service 設定為參照同一個 BackendConfig，做為可重複使用的範本。對於 healthCheck 參數，系統會為每個對應 GKE 服務的後端服務，建立專屬的Google Cloud 健康狀態檢查。

下列 BackendConfig 資訊清單顯示設定 BackendConfig 健康狀態檢查時可用的所有欄位：

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  healthCheck:
    checkIntervalSec: INTERVAL
    timeoutSec: TIMEOUT
    healthyThreshold: HEALTH_THRESHOLD
    unhealthyThreshold: UNHEALTHY_THRESHOLD
    type: PROTOCOL
    requestPath: PATH
    port: PORT

更改下列內容：

• INTERVAL：為每個健康狀態檢查探測器指定check-interval (以秒為單位)。這是指從某個探測器開始檢查到下一次檢查開始之間的時間。如果省略這個參數，系統會使用預設的 5 秒。 Google Cloud 如需其他實作詳細資料，請參閱「多個探測器和頻率」。
• TIMEOUT：指定 Google Cloud 等待探測回應的時間長度。TIMEOUT 的值必須小於或等於 INTERVAL 的值。單位為秒。每個探測器都需要在探測器逾時前傳送 HTTP 200 (OK) 回應代碼。
• HEALTH_THRESHOLD 和 UNHEALTHY_THRESHOLD：指定至少一個探測器必須連續成功或失敗多少次連線嘗試，才能將健康狀態從良好變更為不良，反之亦然。如果省略其中一個參數，Google Cloud 會使用預設值 2。
• PROTOCOL：指定探測系統用於健康狀態檢查的通訊協定。BackendConfig 僅支援使用 HTTP、HTTPS 或 HTTP2 通訊協定建立健康狀態檢查。詳情請參閱「HTTP、HTTPS 和 HTTP/2 的成功標準」。您無法省略這個參數。
• PATH：針對 HTTP、HTTPS 或 HTTP2 健康狀態檢查，請指定探測系統應連線的 request-path。如省略這個參數，Google Cloud 會使用預設的 /。

• PORT：BackendConfig 僅支援使用通訊埠編號指定負載平衡器健康狀態檢查通訊埠。如省略這個參數， Google Cloud 會使用預設值 80。

  • 使用容器原生負載平衡時，請選取與服務 Pod 的 containerPort 相符的通訊埠 (無論該 containerPort 是否由服務的 targetPort 參照)。由於負載平衡器會直接將探測傳送至 Pod 的 IP 位址，因此您不限於 Service targetPort 參照的 containerPort。健康狀態檢查探測系統會連線至您指定通訊埠上服務 Pod 的 IP 位址。

  • 如果是執行個體群組後端，您必須選取與 Service nodePort公開的項目相符的連接埠。健康狀態檢查探測系統隨後會連線至該通訊埠上的每個節點。

如要使用自訂 HTTP 健康狀態檢查設定 GKE Ingress，請參閱使用自訂 HTTP 健康狀態檢查的 GKE Ingress。

Google Cloud Armor Ingress 安全性政策

Google Cloud Armor 安全性政策可協助您保護負載平衡應用程式，免受網路攻擊。設定 Google Cloud Armor 安全性政策後，您可以使用 BackendConfig 參照該政策。

將安全性政策名稱新增至 BackendConfig。下列 BackendConfig 資訊清單會指定名為 example-security-policy 的安全性政策：

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  namespace: cloud-armor-how-to
  name: my-backendconfig
spec:
  securityPolicy:
    name: "example-security-policy"

兩個真實來源

雖然是透過 GKE 設定，但您仍可使用底層的 Compute Engine BackendService API，直接修改要套用的安全防護政策。這會建立兩個可靠資料來源：GKE 和 Compute Engine。下表說明 GKE Ingress 控制器對 BackendConfig 中 securityPolicy 欄位的回應行為。為避免發生衝突和非預期的行為，建議使用 GKE BackendConfig 管理要使用的安全性政策。

如要設定 GKE Ingress 並啟用 Google Cloud Armor 保護功能，請參閱「已啟用 Google Cloud Armor 的 Ingress」。

HTTP 存取記錄

Ingress 可以將用戶端的所有 HTTP 要求記錄到 Cloud Logging。您可以使用 BackendConfig 啟用及停用存取記錄，並設定存取記錄取樣率。

如要設定存取記錄，請使用 BackendConfig 中的 logging 欄位。如果省略 logging，存取記錄會採取預設行為。這取決於 GKE 版本。

您可以設定下列欄位：

• enable：如果設為 true，系統會為這個 Ingress 啟用存取記錄，並在 Cloud Logging 中提供記錄。否則，這個 Ingress 的存取記錄功能會停用。
• sampleRate：指定介於 0.0 到 1.0 之間的值，其中 0.0 表示不會記錄任何封包，1.0 則表示會記錄所有封包。只有在 enable 設為 true 時，這個欄位才適用。sampleRate 是選用欄位，但如果已設定，則必須一併設定 enable: true，否則系統會將其解讀為 enable: false。

下列 BackendConfig 資訊清單會啟用存取記錄，並將特定 Ingress 資源的 HTTP 要求取樣率設為 50%：

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  logging:
    enable: true
    sampleRate: 0.5

Identity-Aware Proxy

如要為Identity-Aware Proxy IAP 設定 BackendConfig，您需要在 BackendConfig 的 iap 區塊中指定 enabled 和 secretName 值。如要指定這些值，請確認您具備 compute.backendServices.update 權限。

下列 BackendConfig 資訊清單會啟用 Identity-Aware Proxy：

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name:  my-backendconfig
spec:
  iap:
    enabled: true
    oauthclientCredentials:
      secretName: my-secret

使用 Google 代管的 OAuth 用戶端啟用 IAP

從 GKE 1.29.4-gke.1043000 版開始，您可以使用 BackendConfig，將 IAP 設定為使用 Google 代管的 OAuth 用戶端。如要決定使用 Google 代管的 OAuth 用戶端或自訂 OAuth 用戶端，請參閱 IAP 說明文件中的「何時使用自訂 OAuth 設定」。

如要使用 Google 管理的 OAuth 用戶端啟用 IAP，請勿在 BackendConfig 中提供 OAuthCredentials。如果使用者已使用 OAuthCredentials 設定 IAP，則無法遷移至 Google 代管的 OAuth 用戶端：您必須重新建立 Backend (從 Ingress 移除 Service，然後重新附加)。我們建議在維護期間執行這項作業，因為這會導致停機。您也可以反向遷移，從 Google 代管的 OAuth 用戶端切換至 OAuthCredentials。

下列 BackendConfig 資訊清單會啟用 Identity-Aware Proxy，並使用 Google 管理的 OAuth 用戶端：

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name:  my-backendconfig
spec:
  iap:
    enabled: true

如需完整操作說明，請參閱 IAP 說明文件中的「為 GKE 啟用 IAP」一文。

搭配內部 Ingress 的 Identity-Aware Proxy

如要為 IAP 設定內部 Ingress，必須使用進階級。如果您未使用進階層級，就無法查看或建立具有 Identity-Aware Proxy 的內部應用程式負載平衡器。您也必須訂閱 Chrome Enterprise Premium，才能使用 IAP 的內部 Ingress。

如要設定安全無虞的 GKE Ingress，並使用 Identity-Aware Proxy 進行驗證，請參閱「已啟用 IAP 的 Ingress」範例。

工作階段相依性

您可以使用 BackendConfig 將工作階段相依性設為用戶端 IP 或產生的 Cookie。

用戶端 IP 相依性

如要使用 BackendConfig 設定用戶端 IP 相依性，請將 affinityType 設為 "CLIENT_IP"，如下列範例所示：

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  sessionAffinity:
    affinityType: "CLIENT_IP"

產生的 Cookie 相依性

如要使用 BackendConfig 設定已產生 Cookie 的相依性，請在 BackendConfig 資訊清單中將 affinityType 設為 GENERATED_COOKIE。您也可以使用 affinityCookieTtlSec 設定 Cookie 的有效時間。

下列資訊清單將相依性類型設為產生的 Cookie，並將 Cookie 的存留時間設為 50 秒：

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  sessionAffinity:
    affinityType: "GENERATED_COOKIE"
    affinityCookieTtlSec: 50

使用者定義的要求標頭

您可以使用 BackendConfig 設定使用者定義的要求標頭。 負載平衡器會將您指定的標頭新增至轉送至後端的要求。

負載平衡器只會將自訂要求標頭新增至用戶端要求，不會新增至健康狀態檢查探測。如果後端需要授權專用的標頭，但健康狀態檢查封包中沒有，健康狀態檢查可能會失敗。

如要啟用使用者定義的要求標頭，您必須在 BackendConfig 資源的 customRequestHeaders 屬性中指定一份標頭清單。請將每個標頭指定為 header-name:header-value 字串。

下列 BackendConfig 資訊清單會新增三個要求標頭：

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  customRequestHeaders:
    headers:
    - "X-Client-Region:{client_region}"
    - "X-Client-City:{client_city}"
    - "X-Client-CityLatLong:{client_city_lat_long}"

自訂回應標頭

如要啟用自訂回應標頭，請在 BackendConfig 資源的 customResponseHeaders 屬性中指定標頭清單。請將每個標頭指定為 header-name:header-value 字串。

自訂回應標頭僅適用於 GKE 叢集 1.25 以上版本。

以下 BackendConfig 資訊清單範例會新增 HTTP 嚴格傳輸安全性 (HSTS) 回應標頭：

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  customResponseHeaders:
    headers:
    - "Strict-Transport-Security: max-age=28800; includeSubDomains"

練習：使用後端服務設定 Ingress 超時

下列練習會說明如何使用 BackendConfig 資源，透過 Ingress 設定逾時和連線排空。

如要設定 Ingress 的後端屬性，請完成下列工作：

1. 建立部署作業。
2. 建立 BackendConfig。
3. 建立 Service，並將 Service 的其中一個通訊埠與 BackendConfig 建立關聯。
4. 建立 Ingress，將 Ingress 與 (Service、通訊埠) 組合建立關聯。
5. 驗證後端服務的屬性。
6. 清除所用資源。

建立部署

建立 BackendConfig 和 Service 之前，您必須先建立部署。

以下範例資訊清單適用於名為 my-deployment.yaml 的 Deployment：

# my-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
spec:
  selector:
    matchLabels:
      purpose: bsc-config-demo
  replicas: 2
  template:
    metadata:
      labels:
        purpose: bsc-config-demo
    spec:
      containers:
      - name: hello-app-container
        image: us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0

執行下列指令來建立 Deployment：

kubectl apply -f my-deployment.yaml

建立 BackendConfig

使用 BackendConfig 指定要使用的 Ingress 功能。

這個名為 my-backendconfig.yaml 的 BackendConfig 資訊清單指定：

• 逾時為 40 秒。
• 連線排除逾時為 60 秒。

# my-backendconfig.yaml
apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  timeoutSec: 40
  connectionDraining:
    drainingTimeoutSec: 60

執行下列指令來建立 BackendConfig：

kubectl apply -f my-backendconfig.yaml

建立服務

即使 Service 有多個通訊埠，BackendConfig 也只對應一組 Service-Port 組合。每個通訊埠只能與一個 BackendConfig CRD 建立關聯。如果 Ingress 參照了某個 Service 通訊埠，且該 Service 通訊埠與某個 BackendConfig 相關聯，則 HTTP(S) 負載平衡後端服務的設定會有部分是來自 BackendConfig。

以下是名為 my-service.yaml 的 Service 資訊清單範例：

# my-service.yaml
apiVersion: v1
kind: Service
metadata:
  name: my-service
  labels:
    purpose: bsc-config-demo
  annotations:
    cloud.google.com/backend-config: '{"ports": {"80":"my-backendconfig"}}'
    cloud.google.com/neg: '{"ingress": true}'
spec:
  type: ClusterIP
  selector:
    purpose: bsc-config-demo
  ports:
  - port: 80
    protocol: TCP
    targetPort: 8080

cloud.google.com/backend-config 註解會指定通訊埠與 BackendConfig 物件之間的對應關係。在 my-service.yaml 中：

• 任何具有 purpose: bsc-config-demo 標籤的 Pod 都是 Service 的成員。
• Service 的 TCP 通訊埠 80 會與名為 my-backendconfig 的 BackendConfig 相關聯。這是由 cloud.google.com/backend-config 註解所指定。
• 當要求傳入在通訊埠 80 上的 Service 時，會轉送至在通訊埠 8080 上的其中一個成員 pod。

如要建立服務，請執行下列指令：

kubectl apply -f my-service.yaml

建立 Ingress

以下是名為 my-ingress.yaml. 的 Ingress 資訊清單。在這個範例中，傳入要求會轉送至名為 my-service 的 Service 通訊埠 80。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
  - http:
      paths:
      - path: /*
        pathType: ImplementationSpecific
        backend:
          service:
            name: my-service
            port:
              number: 80

如要建立 Ingress，請執行下列指令：

kubectl apply -f my-ingress.yaml

請稍候幾分鐘，讓 Ingress 控制器設定外部應用程式負載平衡器與相關的後端服務。完成後，您已將 Ingress 設定為使用 40 秒的逾時時間，以及 60 秒的連線排除逾時時間。

驗證後端服務屬性

您可以透過 BackendConfig 驗證是否已套用正確的負載平衡器設定。如要執行這項操作，請找出 Ingress 部署的後端服務，並檢查其設定，確認設定與 Deployment 資訊清單相符。

首先，請說明 my-ingress 資源，並篩選出列出與 Ingress 相關聯後端服務的註解。例如：

kubectl describe ingress my-ingress | grep ingress.kubernetes.io/backends

輸出結果應該會類似下列內容：

ingress.kubernetes.io/backends: '{"k8s1-27fde173-default-my-service-80-8d4ca500":"HEALTHY","k8s1-27fde173-kube-system-default-http-backend-80-18dfe76c":"HEALTHY"}

輸出內容會提供後端服務的相關資訊。舉例來說，這個註解包含兩個後端服務：

• "k8s1-27fde173-default-my-service-80-8d4ca500":"HEALTHY" 提供與 my-service Kubernetes 服務相關聯的後端服務資訊。
  • k8s1-27fde173 是用來描述叢集的雜湊。
  • default 是 Kubernetes 命名空間。
  • HEALTHY 表示後端健康狀態良好。
• "k8s1-27fde173-kube-system-default-http-backend-80-18dfe76c":"HEALTHY" 提供與預設後端 (404 伺服器) 相關聯的後端服務資訊。
  • k8s1-27fde173 是用來描述叢集的雜湊。
  • kube-system 是命名空間。
  • default-http-backend 是 Kubernetes 服務名稱。
  • 80 是主機通訊埠。
  • HEALTHY 表示後端健康狀態良好。

接著，使用 gcloud 檢查與 my-service 相關聯的後端服務。 篩選 "drainingTimeoutSec" 和 "timeoutSec"，確認這些值已在 Google Cloud 負載平衡器控制平面中設定。例如：

# Optionally, set a variable
export BES=k8s1-27fde173-default-my-service-80-8d4ca500

# Filter for drainingTimeoutSec and timeoutSec
gcloud compute backend-services describe ${BES} --global | grep -e "drainingTimeoutSec" -e "timeoutSec"

輸出：

  drainingTimeoutSec: 60
  timeoutSec: 40

如果輸出內容顯示 drainingTimeoutSec 和 timeoutSec，表示這些值已透過 BackendConfig 正確設定。

正在清除所用資源

如要避免系統向您的帳戶收取不必要的費用，請刪除您為本練習建立的 Kubernetes 物件：

kubectl delete ingress my-ingress
kubectl delete service my-service
kubectl delete backendconfig my-backendconfig
kubectl delete deployment my-deployment

BackendConfig 限制

BackendConfig 有下列限制：

• 一組 (Service、通訊埠) 只能使用一個 BackendConfig，即使有多個 Ingress 物件參照該組 (Service、通訊埠) 也一樣。因此，參照同一組 (Service、通訊埠) 的所有 Ingress 物件，都必須使用相同的 Google Cloud Armor、IAP 和 Cloud CDN 設定。

• IAP 和 Cloud CDN 無法針對相同的 HTTP(S) 負載平衡後端服務來啟用，因此您無法在相同的 BackendConfig 中同時設定 IAP 和 Cloud CDN。

• 您必須使用 kubectl 1.7 以上版本才能與 BackendConfig 互動。

移除 FrontendConfig 或 BackendConfig 中指定的設定

如要撤銷 Ingress 功能，您必須在 FrontendConfig 或 BackendConfig CRD 中明確停用該功能設定。Ingress 控制器只會核對這些 CRD 中指定的設定。

如要清除或停用先前啟用的設定，請視欄位類型將欄位值設為空字串 ("") 或布林值 false。

下列 BackendConfig 資訊清單會停用 Google Cloud Armor 安全性政策和 Cloud CDN：

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  cdn:
    enabled: false
  securityPolicy:
    name: ""

刪除 FrontendConfig 或 BackendConfig

疑難排解

您可以使用 Ingress 診斷工具偵測常見的設定錯誤。此外，請務必正確設定所有健康狀態檢查。

找不到 BackendConfig

如果 Service 註解已指定 Service 通訊埠的 BackendConfig，卻找不到實際的 BackendConfig 資源，就會發生這個錯誤。

如要評估 Kubernetes 事件，請執行下列指令：

kubectl get event

以下輸出範例表示系統找不到 BackendConfig：

KIND    ... SOURCE
Ingress ... loadbalancer-controller

MESSAGE
Error during sync: error getting BackendConfig for port 80 on service "default/my-service":
no BackendConfig for service port exists

如要解決這個問題，請確認您未在錯誤的命名空間中建立 BackendConfig 資源，或是在服務註解中拼錯參照名稱。

找不到輸入安全性政策

建立 Ingress 物件之後，如果安全性政策沒有正確地與 LoadBalancer 服務建立關聯，請評估 Kubernetes 事件，確認是否有設定錯誤。如果 BackendConfig 指定不存在的安全政策，系統會定期發出警告事件。

如要評估 Kubernetes 事件，請執行下列指令：

kubectl get event

以下輸出範例表示系統找不到安全性政策：

KIND    ... SOURCE
Ingress ... loadbalancer-controller

MESSAGE
Error during sync: The given security policy "my-policy" does not exist.

如要解決這個問題，請在 BackendConfig 中指定正確的安全性政策名稱。

在 GKE 中調度工作負載時，使用 NEG 解決 500 系列錯誤

症狀：

使用 GKE 佈建的 NEG 進行負載平衡時，工作負載縮減期間，服務可能會發生 502 或 503 錯誤。如果現有連線關閉前 Pod 就終止，就會發生 502 錯誤；如果流量導向已刪除的 Pod，就會發生 503 錯誤。

如果您使用採用 NEG 的 GKE 代管負載平衡產品 (包括 Gateway、Ingress 和獨立 NEG)，這個問題可能會影響叢集。如果經常調整工作負載規模，叢集受影響的風險會比較高。

診斷：

如果未先排除端點並從 NEG 中移除，就直接移除 Kubernetes 中的 Pod，會導致 500 系列錯誤。為避免 Pod 終止期間發生問題，您必須考量作業順序。下列圖片顯示 BackendService Drain Timeout 未設定，以及 BackendService Drain Timeout 設為 BackendConfig 時的場景。

情境 1：BackendService Drain Timeout 未設定。

下圖顯示 BackendService Drain Timeout 未設定的情形。

情境 2：已設定 BackendService Drain Timeout。

下圖顯示設定 BackendService Drain Timeout 的情境。

500 系列錯誤的確切發生時間取決於下列因素：

• NEG API 分離延遲時間：NEG API 分離延遲時間代表在 Google Cloud中完成分離作業所花費的目前時間。這會受到 Kubernetes 以外的各種因素影響，包括負載平衡器類型和特定區域。

• 排空延遲：排空延遲是指負載平衡器開始將流量從系統的特定部分導出的時間。啟動排空程序後，負載平衡器會停止將新要求傳送至端點，但觸發排空程序仍有延遲 (排空延遲)，如果 Pod 不再存在，可能會導致暫時性的 503 錯誤。

• 健康狀態檢查設定：更敏感的健康狀態檢查門檻可縮短 503 錯誤的持續時間，因為即使分離作業尚未完成，這類門檻也能向負載平衡器發出信號，要求停止將要求傳送至端點。

• 終止寬限期：終止寬限期會決定 Pod 結束作業的時間上限。不過，Pod 可以在終止寬限期結束前結束。如果 Pod 執行時間超過這個期限，系統會在期限結束時強制結束 Pod。這是 Pod 的設定，需要在工作負載定義中設定。

潛在解決方法：

如要避免發生 5XX 錯誤，請套用下列設定。逾時值僅供參考，您可能需要根據特定應用程式調整。下一節將引導您完成自訂程序。

下圖顯示如何使用 preStop 勾點讓 Pod 維持運作：

如要避免發生 500 系列錯誤，請執行下列步驟：

1. 將服務的 BackendService Drain Timeout 設為 1 分鐘。

   • 如果是 Ingress 使用者，請參閱在 BackendConfig 上設定逾時。

   • 如果是閘道使用者，請參閱在 GCPBackendPolicy 上設定逾時。

   • 如果使用獨立 NEG 時直接管理 BackendService，請參閱直接在後端服務上設定逾時。

2. 擴充 Pod 上的 terminationGracePeriod。

   將 Pod 上的 terminationGracePeriodSeconds 設為 3.5 分鐘。搭配建議設定使用時，這項功能可讓 Pod 在端點從 NEG 移除後，有 30 到 45 秒的時間安全關閉。如果需要更多時間完成正常關機程序，可以延長寬限期，或按照「自訂逾時」一節的指示操作。

   下列 Pod 資訊清單指定連線排除逾時為 210 秒 (3.5 分鐘)：

   spec:
     terminationGracePeriodSeconds: 210
     containers:
     - name: my-app
       ...
     ...
   

3. 將 preStop 勾點套用至所有容器。

   套用 preStop hook，確保 Pod 在負載平衡器排除 Pod 端點，以及從 NEG 移除端點時，仍可存活 120 秒。

   spec:
     containers:
     - name: my-app
       ...
       lifecycle:
         preStop:
           exec:
             command: ["/bin/sh", "-c", "sleep 120s"]
     ...
   

自訂逾時

為確保 Pod 持續運作並避免發生 500 系列錯誤，Pod 必須保持運作，直到端點從 NEG 移除為止。具體來說，如要避免發生 502 和 503 錯誤，請考慮同時導入逾時和 preStop hook。

如要在關機程序期間延長 Pod 的運作時間，請在 Pod 中新增 preStop 掛鉤。在系統發出 Pod 結束訊號前執行 preStop hook，因此 preStop hook 可用於讓 Pod 維持運作，直到對應的端點從 NEG 中移除為止。

如要延長 Pod 在關機程序期間保持運作的時間，請在 Pod 設定中插入 preStop hook，如下所示：

spec:
  containers:
  - name: my-app
    ...
    lifecycle:
      preStop:
        exec:
          command: ["/bin/sh", "-c", "sleep <latency time>"]

您可以設定逾時和相關設定，在工作負載縮減期間管理 Pod 的正常關機程序。您可以根據特定用途調整逾時時間。建議您先設定較長的逾時時間，再視需要縮短。您可以透過下列方式，設定逾時相關參數和 preStop 勾點，自訂逾時時間：

後端服務排空逾時

Backend Service Drain Timeout 參數預設為未設定，因此不會產生任何作用。如果您設定 Backend Service Drain Timeout 參數並啟用，負載平衡器會停止將新要求轉送至端點，並等待逾時，然後終止現有連線。

您可以透過 Ingress 使用 BackendConfig、透過 Gateway 使用 GCPBackendPolicy，或在獨立 NEG 的 BackendService 上手動設定 Backend Service Drain Timeout 參數。逾時時間應為處理要求所需時間的 1.5 至 2 倍。這樣可確保在排空程序啟動前收到的要求，會在逾時前完成。將 Backend Service Drain Timeout 參數設為大於 0 的值，有助於減輕 503 錯誤，因為系統不會將新要求傳送至排定要移除的端點。如要讓這個逾時時間生效，您必須搭配使用 preStop 勾點，確保 Pod 在排空期間保持運作。如果沒有這項組合，現有未完成的要求會收到 502 錯誤。

preStop 吸引觀眾的時間

preStop hook 必須延遲 Pod 關閉，讓排除延遲和後端服務排除逾時都能完成，確保在 Pod 關閉前，連線能正常排除，且端點已從 NEG 移除。

為獲得最佳結果，請確保 preStop hook 執行時間大於或等於 Backend Service Drain Timeout 和耗電延遲的總和。

使用下列公式計算理想的preStop掛鉤執行時間：

preStop hook execution time >= BACKEND_SERVICE_DRAIN_TIMEOUT + DRAIN_LATENCY

更改下列內容：

• BACKEND_SERVICE_DRAIN_TIMEOUT：您為 Backend Service Drain Timeout 設定的時間。
• DRAIN_LATENCY：預估排空延遲時間。建議您以一分鐘做為估算值。

如果 500 錯誤持續發生，請估算總發生時間，並將該時間加倍後，加到預估的排空延遲時間。這可確保 Pod 有足夠時間正常排空，然後再從服務中移除。如果這個值對特定用途而言太長，可以調整。

或者，您也可以查看 Pod 的刪除時間戳記，以及 Cloud 稽核記錄中端點從 NEG 移除的時間戳記，藉此估算時間。

終止寬限期參數

您必須設定 terminationGracePeriod 參數，確保 preStop 勾點有足夠時間完成，且 Pod 能順利關閉。

如未明確設定，預設值為 30 秒。terminationGracePeriod您可以使用下列公式計算最佳 terminationGracePeriod：

terminationGracePeriod >= preStop hook time + Pod shutdown time

如要在 Pod 的設定中定義 terminationGracePeriod，請按照下列步驟操作：

  spec:
    terminationGracePeriodSeconds: <terminationGracePeriod>
    containers:
    - name: my-app
      ...
    ...

建立內部 Ingress 資源時找不到 NEG

在 GKE 中建立內部 Ingress 時，可能會發生下列錯誤：

Error syncing: error running backend syncing routine: googleapi: Error 404: The resource 'projects/PROJECT_ID/zones/ZONE/networkEndpointGroups/NEG' was not found, notFound

發生這項錯誤的原因是，內部應用程式負載平衡器的 Ingress 需要使用網路端點群組 (NEG) 做為後端。

在共用 VPC 環境或啟用網路政策的叢集中，請將 cloud.google.com/neg: '{"ingress": true}' 註解新增至服務資訊清單。

504 閘道逾時：上游要求逾時

從 GKE 內部 Ingress 存取 Service 時，可能會發生下列錯誤：

HTTP/1.1 504 Gateway Timeout
content-length: 24
content-type: text/plain

upsteam request timeout

發生這項錯誤的原因是，傳送至內部應用程式負載平衡器的流量，會由 Proxy 專用子網路範圍內的 Envoy Proxy 進行 Proxy 處理。

如要允許來自僅限 Proxy 子網路範圍的流量，請在服務的 targetPort 上建立防火牆規則。

錯誤 400：欄位「resource.target」的值無效

從 GKE 內部 Ingress 存取 Service 時，可能會發生下列錯誤：

Error syncing:LB_NAME does not exist: googleapi: Error 400: Invalid value for field 'resource.target': 'https://www.googleapis.com/compute/v1/projects/PROJECT_NAME/regions/REGION_NAME/targetHttpProxies/LB_NAME. A reserved and active subnetwork is required in the same region and VPC as the forwarding rule.

如要解決這個問題，請建立僅限 Proxy 的子網路。

同步處理期間發生錯誤：執行負載平衡器同步處理常式時發生錯誤：負載平衡器不存在

升級 GKE 控制平面或修改 Ingress 物件時，可能會發生下列其中一個錯誤：

"Error during sync: error running load balancer syncing routine: loadbalancer
INGRESS_NAME does not exist: invalid ingress frontend configuration, please
check your usage of the 'kubernetes.io/ingress.allow-http' annotation."

或：

Error during sync: error running load balancer syncing routine: loadbalancer LOAD_BALANCER_NAME does not exist:
googleapi: Error 400: Invalid value for field 'resource.IPAddress':'INGRESS_VIP'. Specified IP address is in-use and would result in a conflict., invalid

如要解決這些問題，請按照下列步驟操作：

• 在 Ingress 資訊清單的 tls 區段中新增 hosts 欄位，然後刪除 Ingress。請稍候五分鐘，等待 GKE 刪除未使用的 Ingress 資源。然後重新建立 Ingress。詳情請參閱「Ingress 物件的主機欄位」。
• 還原對 Ingress 所做的變更。然後使用註解或 Kubernetes Secret 新增憑證。

已知問題

無法使用 V1 Ingress 命名配置啟用 HTTPS 重新導向

在 GKE 1.16.8-gke.12 以下版本建立的 GKE Ingress 資源，無法啟用 HTTPS 重新導向。您必須重新建立 Ingress，才能啟用 HTTPS 重新導向，否則系統會建立錯誤事件，且 Ingress 不會同步處理。

錯誤事件訊息類似於下列內容：

Error syncing: error running load balancer syncing routine: loadbalancer lb-name does not exist: ensureRedirectUrlMap() = error: cannot enable HTTPS Redirects with the V1 Ingress naming scheme. Please recreate your ingress to use the newest naming scheme.

從 BackendConfig 移除的 Google Cloud Armor 安全性政策欄位

已知問題：使用 v1beta1 API 更新 BackendConfig 資源時，系統會從其服務中移除有效的 Google Cloud Armor 安全性政策。這個問題會影響下列 GKE 版本：

• 1.18.19-gke.1400 至 1.18.20-gke.5099
• 1.19.10-gke.700 至 1.19.14-gke.299
• 1.20.6-gke.700 至 1.20.9-gke.899

如果您未透過 BackendConfig 在 Ingress 資源上設定 Google Cloud Armor，這個問題就不會影響叢集。

對於透過 BackendConfig 設定 Google Cloud Armor 的 GKE 叢集，強烈建議只使用 v1 API 更新 BackendConfig 資源。使用 v1beta1BackendConfig 資源將 BackendConfig 套用至叢集時，系統會從參照的服務中移除 Google Cloud Armor 安全性政策。

為避免這個問題，請只使用 v1 BackendConfig API 更新 BackendConfig。v1 BackendConfig 支援與 v1beta1 相同的所有欄位，且不會造成破壞性變更，因此 API 欄位可以透明地更新。將所有有效 BackendConfig 資訊清單的 apiVersion 欄位替換為 cloud.google.com/v1，且不要使用 cloud.google.com/v1beta1。下列範例資訊清單說明使用 v1 API 的 BackendConfig 資源：

  apiVersion: cloud.google.com/v1
  kind: BackendConfig
  metadata:
    name: my-backend-config
  spec:
    securityPolicy:
      name: "ca-how-to-security-policy"

如果您有定期更新 BackendConfig 資源的 CI/CD 系統或工具，請確保在這些系統中使用 cloud.google.com/v1 API 群組。

如果您的 BackendConfig 已透過 v1beta1 API 更新，Google Cloud Armor 安全性政策可能已遭移除。您可以執行下列指令，判斷是否發生這種情況：

kubectl get backendconfigs -A -o json | jq -r '.items[] | select(.spec.securityPolicy == {}) | .metadata | "\(.namespace)/\(.name)"'

如果回應傳回輸出內容，表示叢集受到問題影響。 這項指令的輸出內容會傳回受問題影響的 BackendConfig 資源清單 (<namespace>/<name>)。如果輸出內容為空白，表示自問題發生以來，您的 BackendConfig 尚未透過 v1beta1 API 更新。日後如要更新 BackendConfig，請務必使用 v1。

如果 Google Cloud Armor 安全性政策遭到移除，您可以使用下列 Logging 查詢，判斷移除時間：

resource.type="gce_backend_service"
protoPayload.methodName="v1.compute.backendServices.setSecurityPolicy"
protoPayload.authenticationInfo.principalEmail:"container-engine-robot.iam.gserviceaccount.com"
protoPayload.response.status = "RUNNING"
NOT protoPayload.authorizationInfo.permission:"compute.securityPolicies.use"

如果任何叢集受到影響，請使用 v1 API 將更新推送至 BackendConfig 資源，即可修正問題。

將 GKE 控制層升級至下列更新版本之一，這些版本已修補這個問題，可安全使用 v1beta1 BackendConfig 資源：

• 1.18.20-gke.5100 以上版本
• 1.19.14-gke.300 以上版本
• 1.20.9-gke.900 以上版本

後續步驟

• 單一叢集負載平衡的 GKE Ingress。

• Ingress 教學課程：為 GKE 應用程式部署 HTTP(S) 轉送。

• 使用自訂 HTTP 健康狀態檢查實作 GKE Ingress