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

設定內部應用程式負載平衡器的 Ingress

Autopilot Standard

本頁面說明如何在 Google Kubernetes Engine (GKE) 中，設定及使用適用於內部應用程式負載平衡器的 Ingress。Ingress 內建支援功能，可透過 GKE Ingress 控制器進行內部負載平衡。

如要進一步瞭解內部應用程式負載平衡器的 Ingress 支援哪些功能，請參閱「Ingress 功能」。您也可以參閱「內部應用程式負載平衡器的 Ingress」，進一步瞭解內部應用程式負載平衡器的 Ingress 運作方式。

事前準備

開始之前，請確認您已執行下列工作：

啟用 Google Kubernetes Engine API。

啟用 Google Kubernetes Engine API

如要使用 Google Cloud CLI 執行這項工作，請安裝並初始化 gcloud CLI。如果您先前已安裝 gcloud CLI，請執行 gcloud components update 指令，取得最新版本。較舊的 gcloud CLI 版本可能不支援執行本文中的指令。
注意：如果已安裝 gcloud CLI，請務必設定 compute/region 屬性。如果您主要使用可用區叢集，請改為設定 compute/zone。設定預設位置後，即可避免 gcloud CLI 發生錯誤，例如 One of [--zone, --region] must be supplied: Please specify location。如果叢集位置與您設定的預設位置不同，您可能需要在特定指令中指定位置。

需求條件和限制

內部應用程式負載平衡器的 Ingress 須符合下列規定：

叢集必須使用 1.16.5-gke.10 以上的 GKE 版本。
叢集必須是虛擬私有雲原生。
叢集必須啟用 HttpLoadBalancing 外掛程式。這項外掛程式預設為啟用。請勿停用。
您必須使用網路端點群組 (NEG) 做為服務的後端。
您無法為內部應用程式負載平衡器啟用全域存取權。如需全域存取權，建議您部署內部閘道。
單一堆疊 IPv6 叢集不支援 GKE Ingress。如要在單一堆疊 IPv6 叢集上設定內部應用程式負載平衡器，請改為部署內部閘道。

部署內部應用程式負載平衡器的 Ingress

下列練習說明如何為內部應用程式負載平衡器部署 Ingress：

準備環境。
建立叢集。
部署應用程式。
部署服務。
部署 Ingress。
驗證部署作業。
刪除 Ingress 資源。

準備環境

您必須先準備網路環境，才能透過 Kubernetes Ingress API 部署負載平衡器資源，以便在特定區域部署負載平衡器 Proxy。

建立 Proxy 專用子網路：

gcloud compute networks subnets create proxy-only-subnet \
    --purpose=REGIONAL_MANAGED_PROXY \
    --role=ACTIVE \
    --region=COMPUTE_REGION \
    --network=NETWORK_NAME \
    --range=10.129.0.0/23

更改下列內容：

COMPUTE_REGION：Compute Engine 區域。
NETWORK_NAME：子網路的網路名稱。

詳情請參閱「設定僅限 Proxy 的子網路」。

建立防火牆規則

Ingress 控制器不會建立防火牆規則，允許來自 Proxy 子網路中負載平衡器 Proxy 的連線。您必須手動建立這項防火牆規則。不過，Ingress 控制器會建立防火牆規則，允許 Google Cloud 健康狀態檢查的輸入流量。

建立防火牆規則，允許從僅限 Proxy 子網路中的負載平衡器 Proxy 連線至 Pod 監聽通訊埠：

gcloud compute firewall-rules create allow-proxy-connection \
    --allow=TCP:CONTAINER_PORT \
    --source-ranges=10.129.0.0/23 \
    --network=NETWORK_NAME

將 CONTAINER_PORT 替換為 Pod 監聽的通訊埠值，例如 9376。

建立叢集

在本節中，您將建立 VPC 原生叢集，以便與內部應用程式負載平衡器的 Ingress 搭配使用。您可以使用 Google Cloud CLI 或 Google Cloud 控制台建立這個叢集。

gcloud

在與僅限 Proxy 子網路相同的網路中建立叢集：

gcloud container clusters create-auto CLUSTER_NAME \
    --location=COMPUTE_LOCATION \
    --network=NETWORK_NAME

更改下列內容：

CLUSTER_NAME：叢集名稱。
COMPUTE_LOCATION：叢集的 Compute Engine 位置。您必須使用與上一節建立的 Proxy 子網路相同的位置。

控制台

前往 Google Cloud 控制台的「Create an Autopilot cluster」(建立 Autopilot 叢集) 頁面。
前往「Create an Autopilot cluster」(建立 Autopilot 叢集) 頁面
在「Cluster basics」(叢集基本資訊) 部分，完成下列操作：
1. 輸入叢集的名稱。
2. 在「Location type」(位置類型) 部分，選取叢集的 Compute Engine 區域。您必須使用與上一節建立的 Proxy 子網路相同的區域。
在導覽窗格中，按一下「Networking」(網路)。
在「Network」(網路) 清單中，選取要在其中建立叢集的網路。這個網路必須與 Proxy 子網路位於同一個虛擬私有雲網路。
在「Node subnet」(節點子網路) 清單中，選取您建立的 Proxy 子網路
點選「建立」。

部署網頁應用程式

在本節中，您將建立Deployment。

如要建立 Deployment，請按照下列步驟操作：

將下列資訊清單範例儲存為 web-deployment.yaml：

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: hostname
  name: hostname-server
spec:
  selector:
    matchLabels:
      app: hostname
  minReadySeconds: 60
  replicas: 3
  template:
    metadata:
      labels:
        app: hostname
    spec:
      containers:
      - image: registry.k8s.io/serve_hostname:v1.4
        name: hostname-server
        ports:
        - containerPort: 9376
          protocol: TCP
      terminationGracePeriodSeconds: 90

這個資訊清單描述的 Deployment 會監聽通訊埠 9376 上的 HTTPS 伺服器。這個 Deployment 也會管理應用程式的 Pod。每個 Pod 都會執行一個應用程式容器，其中包含 HTTPS 伺服器，可傳回應用程式伺服器的主機名稱做為回應。Pod 的預設主機名稱就是 Pod 的名稱。容器也會安全終止。

將資訊清單套用至叢集：
```
kubectl apply -f web-deployment.yaml
```

將 Service 部署為網路端點群組 (NEG)

在本節中，您將建立服務資源。Service 會依據標籤選取後端容器，讓 Ingress 控制器將這些容器設為後端端點。內部應用程式負載平衡器的 Ingress 必須使用 NEG 做為後端。這項功能不支援執行個體群組做為後端。由於必須使用 NEG 後端，因此部署透過 Ingress 公開的服務時，必須使用下列 NEG 註解：

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

如果符合下列所有條件，系統會自動為您的 Service 加上 cloud.google.com/neg: '{"ingress": true}' 註解：

您使用的是 VPC 原生叢集。
您未使用 Shared VPC。
您未使用 GKE 網路政策。

系統會使用名稱為 neg-annotation.config.common-webhooks.networking.gke.io 的 MutatingWebhookConfiguration 自動新增註解。您可以使用下列指令，檢查 MutatingWebhookConfiguration 是否存在：

kubectl get mutatingwebhookconfigurations

使用 NEG 可讓 Ingress 控制器執行容器原生負載平衡。流量會直接從 Ingress Proxy 負載平衡至 Pod IP，而非周遊節點 IP 或 kube-proxy 網路。此外，系統會實作 Pod 完備性閘道，從負載平衡器的角度判斷 Pod 的健康狀態，而不僅僅是 Kubernetes 完備性和運作狀態檢查。Pod readiness 閘道可確保在 Pod 啟動、Pod 遺失或節點遺失等生命週期事件期間，流量不會遭到捨棄。

如未加入 NEG 註解，Ingress 物件會顯示警告，導致您無法設定內部應用程式負載平衡器。如果未加入 NEG 註解，Ingress 也會產生 Kubernetes 事件。以下是事件訊息範例：

Message
-------
error while evaluating the ingress spec: could not find port "8080" in service "default/no-neg-svc"

在 Ingress 參照 Service 之前，系統不會建立 NEG。在 Ingress 和參照的 Service 都存在之前，NEG 不會顯示在 Compute Engine 中。NEG 是可用區資源，如果是多可用區叢集，則會為每個可用區的每項 Service 建立一個 NEG。

如要建立 Service，請按照下列步驟操作：

將下列資訊清單範例儲存為 web-service.yaml：

apiVersion: v1
kind: Service
metadata:
  name: hostname
  namespace: default
  annotations:
    cloud.google.com/neg: '{"ingress": true}'
spec:
  ports:
  - name: host1
    port: 80
    protocol: TCP
    targetPort: 9376
  selector:
    app: hostname
  type: ClusterIP

將資訊清單套用至叢集：
```
kubectl apply -f web-service.yaml
```

部署 Ingress

在本節中，您將建立 Ingress 資源，透過 Ingress 控制器觸發 Compute Engine 負載平衡器的部署作業。內部應用程式負載平衡器的 Ingress 需要下列註解：

annotations:
    kubernetes.io/ingress.class: "gce-internal"

您無法使用 ingressClassName 欄位指定 GKE Ingress。您必須使用 kubernetes.io/ingress.class 註解。詳情請參閱「GKE Ingress 控制器行為」。

如要建立 Ingress，請按照下列步驟操作：

將下列資訊清單範例儲存為 internal-ingress.yaml：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ilb-demo-ingress
  namespace: default
  annotations:
    kubernetes.io/ingress.class: "gce-internal"
spec:
  defaultBackend:
    service:
      name: hostname
      port:
        number: 80

將資訊清單套用至叢集：
```
kubectl apply -f internal-ingress.yaml
```

驗證 Ingress 部署作業是否成功

在本節中，您將驗證部署作業是否成功。

Ingress 資源會在幾分鐘內完整佈建。在此期間，Ingress 控制器會建立轉送規則、後端服務、網址對應和 NEG 等項目。

如要擷取您在上一節建立的 Ingress 資源狀態，請執行下列指令：

kubectl get ingress ilb-demo-ingress

輸出結果會與下列內容相似：

NAME               HOSTS    ADDRESS            PORTS     AGE
ilb-demo-ingress   *        10.128.0.58        80        59s

填入 ADDRESS 欄位後，Ingress 即可使用。如果這個欄位使用 RFC 1918 位址，表示虛擬私有雲中的內部 IP。

由於內部應用程式負載平衡器是區域性負載平衡器，因此只有相同區域和虛擬私有雲中的用戶端才能存取虛擬 IP (VIP)。擷取負載平衡器 VIP 後，您可以使用工具 (例如 curl)，從虛擬私有雲內部對 VIP 發出 HTTP GET 呼叫。

如要發出 HTTP GET 呼叫，請完成下列步驟：

如要從虛擬私有雲內部連至 Ingress VIP，請在與叢集相同的區域和網路中部署 VM：
```
gcloud compute instances create l7-ilb-client \
    --image-family=debian-12 \
    --image-project=debian-cloud \
    --network=NETWORK_NAME \
    --subnet=SUBNET_NAME \
    --zone=COMPUTE_ZONE \
    --tags=allow-ssh
```
更改下列內容：
- SUBNET_NAME：網路中的子網路名稱。
- COMPUTE_ZONE：區域中的 Compute Engine 可用區。
如要進一步瞭解如何建立執行個體，請參閱「建立及啟動 VM 執行個體」。
如要從 VM 內部存取內部 VIP，請使用 curl：
1. 透過 SSH 登入上一個步驟中建立的 VM：
```
gcloud compute ssh l7-ilb-client \
    --zone=COMPUTE_ZONE
```
2. 使用 curl 存取內部應用程式 VIP：
```
curl 10.128.0.58
hostname-server-6696cf5fc8-z4788
```
  成功的 HTTP 回應和其中一個後端容器的主機名稱，表示完整的負載平衡路徑運作正常。

刪除 Ingress 資源

移除 Ingress 和 Service 資源時，也會一併移除與其相關聯的 Compute Engine 負載平衡器資源。為避免資源外洩，請務必在不再需要時，拆除 Ingress 資源。此外，您必須先刪除 Ingress 和 Service 資源，才能刪除叢集，否則 Compute Engine 負載平衡資源會遭到孤立。

如要移除 Ingress，請完成下列步驟：

刪除 Ingress。舉例來說，如要刪除您在本頁建立的 Ingress，請執行下列指令：
```
kubectl delete ingress ilb-demo-ingress
```
刪除 Ingress 後，與該 Ingress 資源相關聯的轉送規則、後端服務和網址對應也會一併移除。
刪除 Service。舉例來說，如要刪除您在本頁面建立的 Service，請執行下列指令：
```
kubectl delete service hostname
```
刪除 Service 後，與 Service 相關聯的 NEG 也會一併移除。

如要在 GKE 上部署應用程式，並透過私人負載平衡 IP 位址公開應用程式，請參閱「基本內部 Ingress」。

靜態 IP 位址

內部 Ingress 資源支援靜態和臨時 IP 位址。如未指定 IP 位址，系統會自動從 GKE 節點子網路分配可用的 IP 位址。不過，Ingress 資源不會從僅限 Proxy 的子網路佈建 IP 位址，因為該子網路僅用於內部 Proxy 消耗。這些臨時 IP 位址只會在內部 Ingress 資源的生命週期內分配給 Ingress。如果您刪除 Ingress，並從同一個資訊清單檔案建立新的 Ingress，不一定會取得相同的外部 IP 位址。

如要使用永久 IP 位址，且不希望該位址與內部 Ingress 資源的生命週期綁定，則必須預留區域性靜態內部 IP 位址。接著，您可以使用 Ingress 資源上的 kubernetes.io/ingress.regional-static-ip-name 註解指定靜態 IP 位址。

以下範例說明如何新增這個註解：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
  annotations:
    kubernetes.io/ingress.regional-static-ip-name: STATIC_IP_NAME
    kubernetes.io/ingress.class: "gce-internal"

將 STATIC_IP_NAME 替換為符合下列條件的靜態 IP 名稱：

請先建立靜態 IP 位址，再部署 Ingress。負載平衡器必須在靜態 IP 存在後才會部署，而參照不存在的 IP 位址資源並不會建立靜態 IP。如果您修改現有的 Ingress，改用靜態 IP 位址而非臨時 IP 位址，GKE 可能會在重新建立負載平衡器的轉送規則時，變更負載平衡器的 IP 位址。
如果是部署在 Shared VPC 服務專案中的 Ingress，靜態 IP 會保留在服務專案中。
請依名稱 (而非 IP 位址) 參照 Google Cloud IP 位址資源。
IP 位址必須來自與 GKE 叢集位於相同區域的子網路。您可以使用該區域內任何可用的私人子網路 (Proxy 專用子網路除外)。不同的 Ingress 資源也可以有來自不同子網路的位址。

用戶端和負載平衡器之間的 HTTPS

內部負載平衡的 Ingress 支援向用戶端提供 TLS 憑證。您可以透過 Kubernetes Secret 或 Google Cloud中的預先共用區域 SSL 憑證提供 TLS 憑證。您也可以為每個 Ingress 資源指定多個憑證。GKE 1.25 以上版本支援同時使用 HTTPS 和 HTTP。如要啟用這項功能，您必須建立 PURPOSE=SHARED_LOADBALANCER_VIP 的靜態 IP 位址，並在 Ingress 上設定。如未提供靜態 IP 位址，則僅允許 HTTPS 流量，且您必須按照停用 HTTP 的說明文件操作。

下列步驟詳細說明如何在 Google Cloud 中建立憑證，然後透過 Ingress 將憑證提供給內部用戶端，用於 HTTPS 和 HTTP 流量：

建立區域性憑證：
```
gcloud compute ssl-certificates create CERT_NAME \
    --certificate CERT_FILE_PATH \
    --private-key KEY_FILE_PATH \
    --region COMPUTE_REGION
```
更改下列內容：
- CERT_NAME：您選擇的憑證名稱。
- CERT_FILE_PATH：本機憑證檔案的路徑，用於建立自行管理的憑證。憑證必須採用 PEM 格式。
- KEY_FILE_PATH：本機私密金鑰檔案的路徑。私密金鑰必須採用 PEM 格式，並使用 RSA 或 ECDSA 加密。
- COMPUTE_REGION：憑證的 Compute Engine 區域。
按照「靜態 IP 定址」一文的說明，保留並套用靜態 IP 位址。

將下列範例資訊清單儲存為 ingress-pre-shared-cert.yaml：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ilb-demo-ing
  namespace: default
  annotations:
    ingress.gcp.kubernetes.io/pre-shared-cert: "CERT_NAME"
    kubernetes.io/ingress.regional-static-ip-name: STATIC_IP_NAME
    kubernetes.io/ingress.class: "gce-internal"
spec:
  rules:
  - host: DOMAIN
    http:
      paths:
      - pathType: ImplementationSpecific
        backend:
          service:
            name: SERVICE_NAME
            port:
              number: 80

更改下列內容：

DOMAIN：您的網域。
CERT_NAME：您在上一節建立的憑證名稱。
SERVICE_NAME：Service 的名稱。

將資訊清單套用至叢集：

kubectl apply -f ingress-pre-shared-cert.yaml

負載平衡器和應用程式之間的 HTTPS

如果應用程式在 GKE Pod 中執行，且可接收 HTTPS 要求，您可以將負載平衡器設為在將要求轉送至應用程式時使用 HTTPS。若須更多訊息，請參閱負載平衡器和應用程式之間的 HTTPS (TLS)。

Shared VPC

手動新增 NEG 註解

如果您部署 Ingress 資源的 GKE 位於 Shared VPC 服務專案中，系統不會自動為服務加上 cloud.google.com/neg: '{"ingress": true}' 註解，因為負責將註解插入服務的 MutatingWebhookConfiguration 並未安裝。

您必須將 NEG 註解新增至 Service 的資訊清單，這些 Service 是透過 Ingress 公開，用於內部應用程式負載平衡器。

虛擬私有雲防火牆規則

如果部署 Ingress 資源的 GKE 叢集位於 Shared VPC 服務專案中，且您希望 GKE 控制層管理主專案中的防火牆資源，則必須按照「使用 Shared VPC 管理叢集的防火牆資源」一文，在主專案中授予服務專案的 GKE 服務帳戶適當的 IAM 權限。這樣一來，Ingress 控制器就能建立防火牆規則，允許Google Cloud 健康狀態檢查的輸入流量。

以下是 Ingress 資源記錄中可能出現的事件範例。如果權限設定不正確，Ingress 控制器無法建立防火牆規則，允許 Google Cloud 健康狀態檢查的輸入流量，就會發生這項錯誤。

Firewall change required by security admin: `gcloud compute firewall-rules update <RULE_NAME> --description "GCE L7 firewall rule" --allow tcp:<PORT> --source-ranges 130.211.0.0/22,35.191.0.0/16 --target-tags <TARGET_TAG> --project <HOST_PROJECT>

如果您想從主專案手動佈建防火牆規則，可以將 networking.gke.io/suppress-firewall-xpn-error: "true" 註解新增至 Ingress 資源，忽略 firewallXPNError 事件。

內部 Ingress 註解摘要

下表列出為內部應用程式負載平衡器建立 Ingress 和 Service 資源時，可以新增的註解。

Ingress 註解

註解	說明
`kubernetes.io/ingress.class`	您可以將內部 Ingress 設為 `"gce-internal"`。如未指定類別，Ingress 資源預設會解讀為外部 Ingress。詳情請參閱「GKE Ingress 控制器行為」。
`kubernetes.io/ingress.allow-http`	您可以允許用戶端與 HTTP(S) 負載平衡器之間的 HTTP 流量。可能的值為 `true` 和 `false`。預設值為 `true`。詳情請參閱「停用 HTTP」。
`ingress.gcp.kubernetes.io/pre-shared-cert`	您可以將憑證和金鑰上傳至 Google Cloud 專案。使用這個註解參照憑證和金鑰。詳情請參閱「搭配使用多個 SSL 憑證與外部應用程式負載平衡器」。
`networking.gke.io/suppress-firewall-xpn-error`	在 GLBC 1.4 以上版本中，您可以將 `firewallXPNError` 事件設為靜音。如果是 Ingress 負載平衡器，當 Kubernetes 因權限不足而無法變更防火牆規則時，系統每隔幾分鐘就會建立 `firewallXPNError` 事件。將 `networking.gke.io/suppress-firewall-xpn-error: "true"` 註解新增至 ingress 資源。預設值為 `false`。如要取消靜音，請移除這個註解。
`kubernetes.io/ingress.regional-static-ip-name`	您可以指定靜態 IP 位址，佈建內部 Ingress 資源。詳情請參閱「靜態 IP 位址」。

與 Ingress 相關的服務註解

註解	說明
`cloud.google.com/backend-config`	使用這個註解，設定與 servicePort 相關聯的後端服務。詳情請參閱「輸入設定」。
`cloud.google.com/neg`	使用這個註解，指定負載平衡器應使用網路端點群組。詳情請參閱「使用容器原生負載平衡」。

疑難排解

如要瞭解及觀察 Ingress 的狀態，通常需要檢查相關聯的資源。常見的問題類型包括負載平衡資源未正確建立、流量未到達後端，或後端未顯示健康狀態。

常見的疑難排解步驟包括：

確認用戶端流量來自與負載平衡器相同的區域和虛擬私有雲。
確認 Pod 和後端健康狀態良好。
驗證 VIP 的流量路徑和 Compute Engine 健康狀態檢查，確保未遭防火牆規則封鎖。
檢查 Ingress 資源事件是否有錯誤。
說明 Ingress 資源，瞭解與 Compute Engine 資源的對應關係。
驗證 Compute Engine 負載平衡資源是否存在、設定是否正確，以及是否未回報錯誤。

篩選輸入事件

下列查詢會篩選叢集中所有 Ingress 事件的錯誤：

kubectl get events --all-namespaces --field-selector involvedObject.kind=Ingress

您也可以依物件或物件名稱篩選：

kubectl get events --field-selector involvedObject.kind=Ingress,involvedObject.name=hostname-internal-ingress

在下列錯誤中，您可以看到 Ingress 參照的 Service 不存在：

LAST SEEN   TYPE      REASON      OBJECT                              MESSAGE
0s          Warning   Translate   ingress/hostname-internal-ingress   error while evaluating the ingress spec: could not find service "default/hostname-invalid"

檢查 Compute Engine 負載平衡器資源

下列指令會顯示 Ingress 資源的完整輸出內容，以便您查看與 Ingress 控制器建立的 Compute Engine 資源之間的對應關係：

kubectl get ing INGRESS_FILENAME -o yaml

將 INGRESS_FILENAME 替換為 Ingress 資源的檔案名稱。

輸出結果會與下列內容相似：

apiVersion: v1
items:
- apiVersion: networking.k8s.io/v1
  kind: Ingress
  metadata:
    annotations:
      ingress.kubernetes.io/backends: '{"k8s1-241a2b5c-default-hostname-80-29269aa5":"HEALTHY"}'
      ingress.kubernetes.io/forwarding-rule: k8s-fw-default-ilb-demo-ingress--241a2b5c94b353ec
      ingress.kubernetes.io/target-proxy: k8s-tp-default-ilb-demo-ingress--241a2b5c94b353ec
      ingress.kubernetes.io/url-map: k8s-um-default-ilb-demo-ingress--241a2b5c94b353ec
      kubectl.kubernetes.io/last-applied-configuration: |
       {"apiVersion":"networking.k8s.io/v1","kind":"Ingress","metadata":{"annotations":{"kubernetes.io/ingress.class":"gce-internal"},"name":"ilb-demo-ingress","namespace":"default"},"spec":{"defaultBackend":{"service":{"name":"hostname"},"port":{"number":80}}}}
      kubernetes.io/ingress.class: gce-internal
    creationTimestamp: "2019-10-15T02:16:18Z"
    finalizers:
    - networking.gke.io/ingress-finalizer
    generation: 1
    name: ilb-demo-ingress
    namespace: default
    resourceVersion: "1538072"
    selfLink: /apis/networking.k8s.io/v1/namespaces/default/ingresses/ilb-demo-ingress
    uid: 0ef024fe-6aea-4ee0-85f6-c2578f554975
  spec:
    defaultBackend:
      service:
        name: hostname
        port:
          number: 80
  status:
    loadBalancer:
      ingress:
      - ip: 10.128.0.127
kind: List
metadata:
  resourceVersion: ""
  selfLink: ""

ingress.kubernetes.io/backends 註解會列出後端及其狀態。確認後端列為 HEALTHY。

您可以直接查詢 Ingress 建立的 Compute Engine 資源，瞭解其狀態和設定。執行這些查詢也有助於疑難排解。

如要列出所有 Compute Engine 轉送規則，請執行下列指令：

gcloud compute forwarding-rules list

輸出結果會與下列內容相似：

NAME                                                        REGION       IP_ADDRESS      IP_PROTOCOL  TARGET
k8s-fw-default-hostname-internal-ingress--42084f6a534c335b  REGION_NAME  10.128.15.225   TCP          REGION_NAME/targetHttpProxies/k8s-tp-default-hostname-internal-ingress--42084f6a534c335b

如要列出後端服務的健康狀態，請先列出後端服務，然後複製要檢查的後端服務名稱：

gcloud compute backend-services list

輸出結果會與下列內容相似：

NAME                                         BACKENDS                                                                       PROTOCOL
k8s1-42084f6a-default-hostname-80-98cbc1c1   REGION_NAME/networkEndpointGroups/k8s1-42084f6a-default-hostname-80-98cbc1c1 HTTP

現在可以使用後端服務名稱查詢健康狀態：

gcloud compute backend-services get-health k8s1-42084f6a-default-hostname-80-98cbc1c1 \
    --region COMPUTE_REGION

將 COMPUTE_REGION 替換為後端服務的 Compute Engine 區域。

輸出結果會與下列內容相似：

backend: https://www.googleapis.com/compute/v1/projects/user1-243723/zones/ZONE_NAME/networkEndpointGroups/k8s1-42084f6a-default-hostname-80-98cbc1c1
status:
  healthStatus:
  - healthState: HEALTHY

設定內部應用程式負載平衡器的 Ingress 透過集合功能整理內容 你可以依據偏好儲存及分類內容。

事前準備

需求條件和限制

部署內部應用程式負載平衡器的 Ingress

準備環境

建立防火牆規則

建立叢集

gcloud

控制台

部署網頁應用程式

將 Service 部署為網路端點群組 (NEG)

部署 Ingress

驗證 Ingress 部署作業是否成功

刪除 Ingress 資源

靜態 IP 位址

用戶端和負載平衡器之間的 HTTPS

負載平衡器和應用程式之間的 HTTPS

Shared VPC

手動新增 NEG 註解

虛擬私有雲防火牆規則

內部 Ingress 註解摘要

Ingress 註解

與 Ingress 相關的服務註解

疑難排解

篩選輸入事件

檢查 Compute Engine 負載平衡器資源

後續步驟

設定內部應用程式負載平衡器的 Ingress