應用程式負載平衡器的 GKE Ingress

本頁將概略介紹外部應用程式負載平衡器的 Ingress，以及運作方式。Google Kubernetes Engine (GKE) 提供內建的代管 Ingress 控制器，稱為 GKE Ingress。在 GKE 中建立 Ingress 資源時，控制器會自動設定 HTTPS 負載平衡器，允許 HTTP 或 HTTPS 流量連線至您的服務。

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

閱讀本頁面之前，請先熟悉 Kubernetes。

總覽

在 GKE 中，Ingress 物件定義了將 HTTP(S) 流量轉送至叢集中執行的應用程式的規則。Ingress 物件會與一或多個服務物件建立關聯，每個服務物件會再與一組 Pod 建立關聯。如要進一步瞭解 Ingress 如何使用 Service 公開應用程式，請參閱服務網路總覽。

建立 Ingress 物件時，GKE Ingress 控制器會根據 Ingress 中的資訊及相關聯的 Service 建立 Trusted Cloud by S3NS HTTP(S) 負載平衡器，並進行設定。

如要使用 Ingress，必須啟用 HTTP 負載平衡外掛程式。根據預設，GKE 叢集已啟用 HTTP 負載平衡，不得停用該功能。

外部和內部流量的輸入

GKE Ingress 資源分為兩種類型：

• 外部應用程式負載平衡器的 Ingress 會部署傳統版應用程式負載平衡器。這個面向網際網路的負載平衡器會部署在 Google 邊緣網路的全球各地，做為可擴充的代管負載平衡資源集區。瞭解如何設定及使用外部應用程式負載平衡器的 Ingress。

• 內部應用程式負載平衡器的 Ingress 會部署內部應用程式負載平衡器。這些內部應用程式負載平衡器是由 GKE 叢集外部但 VPC 網路內的 Envoy Proxy 系統提供支援。瞭解如何設定及使用適用於內部應用程式負載平衡器的 Ingress。

GKE Ingress 控制器行為

如果叢集執行的是 1.18 以上版本的 GKE，GKE Ingress 控制器是否會處理 Ingress，取決於 kubernetes.io/ingress.class 註解的值：

如果叢集執行的 GKE 版本較舊，GKE 控制器會處理任何沒有 kubernetes.io/ingress.class 註解的 Ingress，或是註解值為 gce 或 gce-internal 的 Ingress。

kubernetes.io/ingress.class 註解淘汰

雖然 kubernetes.io/ingress.class 註解已在 Kubernetes 中遭到淘汰，但 GKE 仍會繼續使用這個註解。

您無法使用 ingressClassName 欄位指定 GKE Ingress。您必須使用 kubernetes.io/ingress.class 註解。

外部應用程式負載平衡器的功能

Ingress 設定的外部應用程式負載平衡器包括以下功能：

• 彈性的 Service 設定。Ingress 定義流量如何到達您的 Service，以及流量如何轉送到您的應用程式。此外，Ingress 可以為叢集中的多個 Service 提供單一 IP 位址。
• 與 Trusted Cloud 網路服務整合
• 支援多個傳輸層安全標準 (TLS) 憑證。Ingress 可以指定使用多個傳輸層安全標準 (TLS) 憑證來要求終止。

如需完整清單，請參閱Ingress 設定。

負載平衡方法

GKE 支援容器原生負載平衡和執行個體群組。

容器原生負載平衡

容器原生負載平衡是指直接對 GKE 中的 Pod 端點進行負載平衡。容器原生負載平衡是網路端點群組 (NEG) 的一種。

使用 NEG 時，流量會從負載平衡器直接負載平衡至 Pod IP，而不會經過 VM IP 和 kube-proxy 網路。此外，我們也實作了 Pod 就緒閘道，從負載平衡器的角度判斷 Pod 的健康狀態，而不僅是 Kubernetes 叢集內健康狀態探查。負載平衡器基礎架構會感知生命週期事件，例如 Pod 啟動、Pod 遺失或 VM 遺失，進而提升整體流量穩定性。這些功能可解決上述限制，並提升網路效能和穩定性。

如果符合下列所有條件，系統會預設為 Service 啟用容器原生負載平衡：

• 適用於在 GKE 叢集 1.17.6-gke.7 以上版本中建立的服務
• 使用 VPC 原生叢集
• 未使用共用虛擬私有雲網路
• 未使用 GKE 網路政策

在這些情況下，系統會自動使用 cloud.google.com/neg: '{"ingress": true}' 註解服務，表示應建立 NEG 來鏡像服務中的 Pod IP。NEG 可讓 Compute Engine 負載平衡器直接與 Pod 通訊。請注意，在 GKE 1.17.6-gke.7 之前建立的現有服務，不會由服務控制器自動註解。

對於 GKE 1.17.6-gke.7 之前的版本，NEG 註解是自動產生，因此如有需要，可以停用 NEG，並強制 Compute Engine 外部負載平衡器使用執行個體群組做為後端。方法是使用 cloud.google.com/neg: '{"ingress": false}' 明確註解服務。您無法透過 Ingress 停用內部應用程式負載平衡器的 NEG。

對於 NEG 不是預設值的叢集，我們強烈建議使用容器原生負載平衡，但必須針對每個服務明確啟用。註解應以下列方式套用至服務：

kind: Service
...
  annotations:
    cloud.google.com/neg: '{"ingress": true}'
...

執行個體群組

使用執行個體群組時，Compute Engine 負載平衡器會將流量傳送至 VM IP 位址做為後端。在 VM 上執行容器時，容器會共用相同的主機介面，因此會產生下列限制：

• 這會產生兩次負載平衡躍點：一次是從負載平衡器到 VM NodePort，另一次是透過 kube-proxy 路由傳送到 Pod IP 位址 (可能位於不同的 VM)。
• 額外的躍點會增加延遲時間，並使流量路徑更加複雜。
• Compute Engine 負載平衡器無法直接查看 Pod，導致流量平衡不盡理想。
• 由於流量會經過兩次躍點，因此環境事件 (例如 VM 或 Pod 遺失) 更可能導致流量間歇性遺失。

外部 Ingress 和使用路由的叢集

如果您使用以路徑為基礎的叢集和外部 Ingress，GKE Ingress 控制器就無法使用容器原生負載平衡，也就是 GCE_VM_IP_PORT 網路端點群組 (NEG)。而是使用非代管的執行個體群組後端，其中包含所有節點集區中的所有節點。如果這些非代管執行個體群組也由LoadBalancer服務使用，可能會導致單一負載平衡執行個體群組限制相關問題。

在 VPC 原生叢集中建立的某些舊版外部 Ingress 物件，可能會在建立的每個外部應用程式負載平衡器後端服務上，使用執行個體群組後端。這與內部 Ingress 無關，因為內部 Ingress 資源一律使用 GCE_VM_IP_PORT NEG，且需要 VPC 原生叢集。

如要瞭解如何排解外部 Ingress 的 502 錯誤，請參閱「外部 Ingress 產生 HTTP 502 錯誤」。

共用虛擬私有雲

Ingress 和 MultiClusterIngress 資源支援共用虛擬私有雲，但需要額外準備。

Ingress 控制器會在 GKE 控制層上執行，並使用叢集專案的 GKE 服務帳戶，向 Trusted Cloud by S3NS 發出 API 呼叫。根據預設，當位於共用虛擬私有雲服務專案中的叢集使用共用虛擬私有雲網路時，Ingress 控制器無法使用服務專案的 GKE 服務帳戶，在主專案中建立及更新 Ingress 允許防火牆規則。

您可以授予服務專案的 GKE 服務帳戶權限，在主專案中建立及管理 VPC 防火牆規則。授予這些權限後，GKE 會為下列項目建立 Ingress 允許防火牆規則：

• 外部應用程式負載平衡器用於外部 Ingress 的 Google Front End (GFE) Proxy 和健康狀態檢查系統。詳情請參閱「外部應用程式負載平衡器總覽」。

• 內部 Ingress 使用的內部應用程式負載平衡器健康狀態檢查系統。

從主專案手動佈建防火牆規則

如果安全政策只允許從主專案管理防火牆，您可以手動佈建這些防火牆規則。在共用虛擬私有雲中部署 Ingress 時，Ingress 資源事件會提供您需要新增的特定防火牆規則，以提供存取權。

如要手動佈建規則，請按照下列步驟操作：

1. 查看 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 欄中。

2. 從主專案複製並套用建議的防火牆規則。套用這項規則後，負載平衡器和Trusted Cloud 健康狀態檢查工具就能存取 Pod。

授予 GKE 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.s3ns-system.iam.gserviceaccount.com \
  --role=roles/compute.securityAdmin

更改下列內容：

• HOST_PROJECT_ID：共用虛擬私有雲主專案的專案 ID。
• SERVICE_PROJECT_NUMBER：包含叢集的服務專案專案編號。

多項後端服務

每個外部或內部應用程式負載平衡器都會使用單一網址對應，該網址對應會參照一或多個後端服務。每個後端服務都對應至 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
        backend:
          service:
            name: my-products
            port:
              number: 60000
      - path: /discounted-products
        backend:
          service:
            name: my-discounted-products
            port:
              number: 80

建立 Ingress 時，GKE 輸入控制器會根據 Ingress 和關聯的 Service 中的資訊，建立和設定外部或內部應用程式負載平衡器。同時，系統會給負載平衡器一個穩定的 IP 位址，以與網域名稱建立關聯。

上述範例假設您已將負載平衡器的 IP 位址與網域名稱 your-store.example 關聯。要求由用戶端傳送至 your-store.example 後，會轉送至通訊埠 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

在服務資訊清單中，您必須使用 type: NodePort，除非您使用容器原生負載平衡。如果使用容器原生負載平衡，請使用 type: ClusterIP。

在 Service 資訊清單中，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

在 Service 資訊清單中，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」。

對應至 Compute Engine 資源的 Ingress

GKE Ingress 控制器會根據叢集中部署的 Ingress 資源，部署及管理 Compute Engine 負載平衡器資源。Compute Engine 資源的對應方式取決於 Ingress 資源的結構。

下列資訊清單說明 Ingress：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
  - http:
      paths:
      - path: /*
        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 建立下列 Compute Engine 資源：

• 轉送規則和 IP 位址。
• Compute Engine 防火牆規則，允許負載平衡器健康狀態檢查的流量，以及來自 Google Front End 或 Envoy 代理程式的應用程式流量。
• 如果您設定了 TLS，則為目標 HTTP Proxy 和目標 HTTPS Proxy。
• 網址對應，其中單一主機規則參照單一路徑比對器。路徑比對器有兩項路徑規則，分別適用於 /* 和 /discounted。每個路徑規則都會對應至專屬的後端服務。
• NEG，其中包含每個服務的 Pod IP 位址清單做為端點。這些是 my-discounted-products 和 my-products 服務的結果。

提供 SSL 憑證的方法

您可以透過下列方法，將 SSL 憑證提供給 HTTP(S) 負載平衡器：

Google 代管憑證

系統會針對您的網域佈建、配置、更新及代管

Google 代管的 SSL 憑證。代管憑證不支援萬用字元網域。

與「 Trusted Cloud」共用的自行管理憑證

您可以佈建自己的 SSL 憑證，並在 Trusted Cloud 專案中建立憑證資源。接著，您就可以在 Ingress 上的註解中列出憑證資源，以建立使用該憑證的 HTTP(S) 負載平衡器。詳情請參閱預先共用憑證的操作說明。

將自行管理憑證做為密鑰資源

您可以佈建自己的 SSL 憑證，並建立密鑰來保存憑證。接著，您就可以參閱 Ingress 規範中的密鑰，以建立使用憑證的 HTTP(S) 負載平衡器。詳情請參閱在密鑰中使用憑證的操作說明。

健康狀態檢查

使用預設的 Ingress 控制器，透過 Ingress 公開一或多個 Service 時，GKE 會建立傳統型應用程式負載平衡器或內部應用程式負載平衡器。這兩種負載平衡器都支援單一網址對應上的多個後端服務。每個後端服務都對應至 Kubernetes 服務，且每個後端服務都必須參照Trusted Cloud 健康狀態檢查。這項健康狀態檢查與 Kubernetes 執行中或已就緒探測器不同，因為健康狀態檢查是在叢集外部實作。

負載平衡器健康狀態檢查是針對每個後端服務指定，雖然可以對負載平衡器的所有後端服務使用相同的健康狀態檢查，但系統不會為整個負載平衡器 (在 Ingress 物件本身) 指定健康狀態檢查參照。

GKE 會根據下列其中一種方法建立健康狀態檢查：

• BackendConfig CRD：自訂資源定義 (CRD)，可精確控管服務與負載平衡器的互動方式。BackendConfig CRD 可讓您為與相應後端服務相關聯的健康狀態檢查指定自訂設定。這些自訂設定可讓您更靈活地控管 Ingress 建立的傳統版應用程式負載平衡器和內部應用程式負載平衡器健康狀態檢查。
• 完備性探測：診斷檢查，用於判斷 Pod 內的容器是否已準備好處理流量。GKE Ingress 控制器會根據該 Service 服務 Pod 使用的就緒探針，為 Service 的後端服務建立健康狀態檢查。您可以從就緒探查定義衍生健康狀態檢查參數，例如路徑、通訊埠和通訊協定。
• 預設值：未設定 BackendConfig CRD 或定義就緒探查屬性時使用的參數。

GKE 會使用下列程序，為 Kubernetes 服務對應的每個後端服務建立健康狀態檢查：

• 如果 Service 參照含有 healthCheck 資訊的 BackendConfig CRD，GKE 會使用該資訊建立健康狀態檢查。GKE Enterprise Ingress 控制器和 GKE Ingress 控制器都支援以這種方式建立健康狀態檢查。

• 如果 Service 未參照 BackendConfig CRD：

  • 如果服務 Pod 使用的 Pod 範本含有容器，且該容器的完備性探針具有可解讀為健康狀態檢查參數的屬性，GKE 就能推斷部分或所有健康狀態檢查參數。如需實作詳細資料，請參閱「準備探查的參數」一文；如需可用於建立健康狀態檢查參數的屬性清單，請參閱「預設和推斷參數」一文。只有 GKE Ingress 控制器支援從就緒探針推斷參數。

  • 如果服務的服務 Pod 的 Pod 範本沒有包含完備性探針的容器，且該容器的屬性可解讀為健康狀態檢查參數，系統會使用預設值建立健康狀態檢查。GKE Enterprise 輸入控制器和 GKE 輸入控制器都只能使用預設值建立健康狀態檢查。

預設和推斷參數

如果您「未」使用 BackendConfig CRD 為對應服務指定健康狀態檢查參數，系統就會使用下列參數。

完備性探測的參數

當 GKE 為 Service 的後端服務建立健康狀態檢查時，GKE 可以從該 Service 服務 Pod 使用的其中一個容器完備性探測器複製特定參數。這個選項僅適用於 GKE Ingress 控制器。

如要查看可解讀為健康狀態檢查參數的就緒探查屬性，請參閱「預設和推斷參數」一節，其中列出支援的屬性和預設值。如果就緒探查中未指定任何屬性，或您完全未指定就緒探查，系統會使用預設值。

如果 Service 的服務 Pod 包含多個容器，或是您使用 GKE Enterprise Ingress 控制器，則應使用 BackendConfig CRD 定義健康狀態檢查參數。詳情請參閱「何時改用 CRD」。BackendConfig

何時改用 BackendConfig CRD

在下列情況中，您應建立 Service 的 BackendConfig CRD，明確定義後端服務的健康狀態檢查參數，而非依賴 Pod 準備狀態探測的參數：

• 如果您使用 GKE Enterprise：GKE Enterprise 輸入控制器「不」支援從服務 Pod 的就緒探針取得健康狀態檢查參數。只能使用隱含參數建立健康狀態檢查，或在 BackendConfig CRD 中定義。

• 如果服務 Pod 中有多個容器： GKE 無法從特定容器選取就緒探針，藉此推斷健康狀態檢查參數。由於每個容器都可以有自己的就緒探測，且就緒探測並非容器的必要參數，因此您應透過參照對應服務的 BackendConfig CRD，為對應的後端服務定義健康狀態檢查。

• 如要控管負載平衡器健康狀態檢查所用的通訊埠：只有當該通訊埠與 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。

使用多個 TLS 憑證

假設您希望 HTTP(S) 負載平衡器提供 your-store.example 和 your-experimental-store.example 這兩個主機名稱的內容。此外，您希望負載平衡器在 your-store.example 與 your-experimental-store.example 使用不同的憑證。

方法是在 Ingress 資訊清單中指定多個憑證。如果憑證中的通用名稱 (CN) 與要求中使用的主機名稱相符，負載平衡器就會選擇該憑證。如要詳細瞭解如何設定多個憑證，請參閱「使用 Ingress 在 HTTPS 負載平衡中使用多個 SSL 憑證」。

比較 Kubernetes Service 與 Trusted Cloud 後端服務

Kubernetes Service 與Trusted Cloud 後端服務不同。兩者之間有很強的關係，但這種關係不一定是一對一的。GKE 輸入控制器會為 Ingress 資訊清單中的每對 (service.name、service.port) 建立 Trusted Cloud 後端服務。因此，一個 Kubernetes Service 物件可能與多個後端服務相關。 Trusted Cloud

限制

• 在 1.16 之前的叢集版本中，命名空間的總長度和 Ingress 的名稱不得超過 40 個字元。若未遵照本指南執行，可能導致 GKE Ingress 控制器異常。詳情請參閱這篇有關長名稱的 GitHub 問題。

• 在採用 NEG 的叢集中，Ingress 數量可能會影響 Ingress 調解時間。 舉例來說，如果叢集有 20 個 Ingress，每個 Ingress 包含 20 個不同的 NEG 後端，Ingress 變更的協調作業可能需要超過 30 分鐘的延遲時間。由於需要更多 NEG，這對區域叢集的影響尤其明顯。

• 適用網址對應配額。

• 適用 Compute Engine 資源配額。

• 如果未使用 NEGs 和 GKE 輸入控制器，則 GKE 叢集的節點數上限為 1,000 個。使用 NEG 部署服務時，沒有 GKE 節點限制。透過 Ingress 公開的任何非 NEG 服務，在節點超過 1,000 個的叢集上都無法正常運作。

• 要使 GKE Ingress 控制器使用 readinessProbes 作為健康狀態檢查，則 Ingress 的 Pod 必須在 Ingress 建立時存在。如果您的複本縮放為 0，則將套用預設的健康狀況檢查。詳情請參閱這則 GitHub 問題評論。

• Pod 的 readinessProbe 變更，在 Ingress 建立後便不會對其造成影響。

• 外部應用程式負載平衡器終止 TLS 的位置分散在世界各地，這樣可縮短用戶端與負載平衡器之間的延遲。如果需要對 TLS 終止位置進行地理位置控制，則應使用透過 GKE 服務 (類型為 LoadBalancer) 公開的自訂輸入控制器，並在適合您需求之地區中的後端終止 TLS。

• 系統不支援將多個 Ingress 資源合併為單一 Trusted Cloud by S3NS 負載平衡器 。

• 您必須關閉應用程式的 mTLS，因為外部應用程式負載平衡器不支援這項功能。

• Ingress 只能為前端公開 HTTP 通訊埠 80 和 443。

作品詳細資訊

• Ingress 控制器會從 Trusted Cloud by S3NS 專案擷取測試資源，定期檢查服務帳戶權限。您會看到這個項目是名為「k8s-ingress-svc-acct-permission-check-probe」的 (不存在) 全域 BackendService 的 GET。由於這個資源通常不存在，GET 要求會傳回「找不到」。這是正常情況，因為控制器會檢查 API 呼叫是否因授權問題而遭拒。如果您建立同名的 BackendService，GET 會成功，而不是傳回「找不到」。

Ingress 設定範本

• 在 GKE 網路範例的「Ingress」部分，您可以找到 GKE 提供的範本，瞭解許多常見的 Ingress 用法。

後續步驟

• 瞭解 GKE 網路食譜
• 進一步瞭解 Trusted Cloud中的負載平衡。
• 閱讀 GKE 網路總覽。
• 瞭解如何設定內部應用程式負載平衡器的 Ingress。
• 瞭解如何設定外部應用程式負載平衡器的 Ingress。