設定內部負載平衡器

內部負載平衡器 (ILB) 會從指派給機構的內部 IP 集區，公開機構內的服務。ILB 服務一律無法從機構外部的任何端點存取。

根據預設，您可以從機構中的任何叢集，存取同一專案中的 ILB 服務。根據預設，專案網路政策不允許從專案外部存取任何專案資源，這項限制也適用於 ILB 服務。如果平台管理員 (PA) 設定的專案網路政策允許其他專案存取您的專案，則同一個機構中的其他專案也能存取 ILB 服務。

事前準備

如要設定 ILB，請務必完成下列步驟：

  • 擁有要設定負載平衡器的專案。詳情請參閱「建立專案」一文。

  • 具備必要的 Identity and Access 角色：

    • 請要求機構 IAM 管理員授予您「負載平衡器管理員」(load-balancer-admin) 角色。
    • 如果是全域 ILB，請要求機構 IAM 管理員授予您全域負載平衡器管理員 (global-load-balancer-admin) 角色。詳情請參閱「預先定義的角色說明」。

  • 瞭解代管工作負載的叢集類型。設定共用和標準叢集的 ILB 時，請分別按照不同操作說明進行。

為共用叢集建立內部負載平衡器

您可以為共用叢集建立全域或可用區 ILB。全球 ILB 的範圍涵蓋整個 GDC 宇宙。區域 ILB 的範圍僅限於建立時指定的區域。詳情請參閱「全域和區域負載平衡器」。

在 GDC 中使用三種不同方法建立 ILB：

您可以使用 KRM API 和 gdcloud CLI，以 Pod 或 VM 工作負載為目標。直接從 Kubernetes 叢集使用 Kubernetes 服務時，只能以建立 Service 物件的叢集中的工作負載為目標。

建立可用區 ILB

使用 gdcloud CLI、KRM API 或 Kubernetes 叢集中的 Kubernetes 服務，建立區域 ILB：

gdcloud

使用 gdcloud CLI 建立以 Pod 或 VM 工作負載為目標的 ILB。

這個 ILB 會以專案中符合 Backend 物件所定義標籤的所有工作負載為目標。

如要使用 gdcloud CLI 建立 ILB，請按照下列步驟操作：

  1. 建立 Backend 資源，定義 ILB 的端點：

    gdcloud compute backends create BACKEND_NAME \
  --labels=LABELS \
  --project=PROJECT_NAME \
  --zone=ZONE \
  --cluster-name=CLUSTER_NAME

    更改下列內容：

    • BACKEND_NAME：您為後端資源選擇的名稱，例如 my-backend。
    • LABELS：這個選取器會定義要用於這個後端資源的 Pod 和 VM 之間的端點。例如：app=web。
    • PROJECT_NAME：專案名稱。
    • ZONE：用於這次呼叫的可用區。如要為所有需要區域旗標的指令預先設定該旗標，請執行：gdcloud config set core/zone ZONE。區域標記僅適用於多區域環境。這是選填欄位。
    • CLUSTER_NAME：定義選取器的範圍僅限於該叢集。如未指定這個欄位，系統會選取具有指定標籤的所有端點。這是選填欄位。

  2. 如果這個 ILB 是用於 Pod 工作負載，請略過這個步驟。如果您要為 VM 工作負載設定 ILB，請為 ILB 定義健康狀態檢查類型。舉例來說，如要建立 TCP 健康狀態檢查，請定義如下：

    gdcloud compute health-checks create tcp HEALTH_CHECK_NAME \
  --check-interval=CHECK_INTERVAL \
  --healthy-threshold=HEALTHY_THRESHOLD \
  --timeout=TIMEOUT \
  --unhealthy-threshold=UNHEALTHY_THRESHOLD \
  --port=PORT \
  --zone=ZONE

    更改下列內容：

    • HEALTH_CHECK_NAME：您為健康狀態檢查資源選擇的名稱，例如 my-health-check。
    • CHECK_INTERVAL：從某次探測作業開始到下一次探測作業開始之間的時間長度 (以秒為單位)，預設值為 5。這是選填欄位。
    • HEALTHY_THRESHOLD：端點必須通過的連續探測次數，才能判定為健康狀態良好。預設值為 5。這是選填欄位。
    • TIMEOUT：宣告失敗前的等待時間 (以秒為單位)。預設值為 5。這是選填欄位。
    • UNHEALTHY_THRESHOLD：端點必須連續探測失敗的次數，才會被視為健康狀態不良。預設值為 2。這是選填欄位。
    • PORT：執行健康狀態檢查的通訊埠。預設值為 80。這是選填欄位。
    • ZONE：您要建立這個 ILB 的可用區。

  3. 建立 BackendService 資源，並將先前建立的 Backend 資源新增至其中：

    gdcloud compute backend-services create BACKEND_SERVICE_NAME \
  --project=PROJECT_NAME \
  --target-ports=TARGET_PORTS \
  --zone=ZONE \
  --health-check=HEALTH_CHECK_NAME

    更改下列內容：

    • BACKEND_SERVICE_NAME：這個後端服務的所選名稱。
    • TARGET_PORTS：這個後端服務翻譯的目標通訊埠清單 (以半形逗號分隔)，其中每個目標通訊埠都會指定通訊協定、轉送規則中的通訊埠，以及後端執行個體中的通訊埠。您可以指定多個目標連接埠。這個欄位的格式必須為 protocol:port:targetport，例如 TCP:80:8080。這是選填欄位。
    • HEALTH_CHECK_NAME：健康狀態檢查資源的名稱。這是選填欄位。只有在為 VM 工作負載設定 ILB 時，才需要加入這個欄位。

  4. 將 BackendService 資源新增至先前建立的 Backend 資源：

    gdcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
  --backend=BACKEND_NAME \
  --project=PROJECT_NAME \
  --zone=ZONE

  5. 建立內部 ForwardingRule 資源，定義服務可用的 VIP：

    gdcloud compute forwarding-rules create FORWARDING_RULE_INTERNAL_NAME \
  --backend-service=BACKEND_SERVICE_NAME \
  --cidr=CIDR \
  --ip-protocol-port=PROTOCOL_PORT \
  --load-balancing-scheme=INTERNAL \
  --zone=ZONE \
  --project=PROJECT_NAME

    更改下列內容：

    • BACKEND_SERVICE_NAME：後端服務的名稱。
    • FORWARDING_RULE_INTERNAL_NAME 替換成您為轉送規則選擇的名稱。
    • CIDR：這個欄位為選填。如未指定，系統會從區域 IP 集區自動保留 IPv4/32 CIDR。指定與此轉送規則位於相同命名空間的 Subnet 資源名稱。Subnet 資源代表區域子網路的要求和分配資訊。如要進一步瞭解 Subnet 資源，請參閱「自訂資源範例」。
    • PROTOCOL_PORT：要在轉送規則中公開的通訊協定和通訊埠。這個欄位的格式必須為 ip-protocol=TCP:80。公開的通訊埠必須與實際應用程式在容器內公開的通訊埠相同。

  6. 如要驗證設定的 ILB，請確認每個建立物件的 Ready 條件。透過向 VIP 發出的curl要求驗證流量：

    1. 如要取得指派的 VIP，請說明轉送規則：

      gdcloud compute forwarding-rules describe FORWARDING_RULE_INTERNAL_NAME

    2. 使用 curl 要求，在轉送規則的 PROTOCOL_PORT 欄位中指定的通訊埠，驗證 VIP 的流量：

      curl http://FORWARDING_RULE_VIP:PORT

      更改下列內容：

      • FORWARDING_RULE_VIP：轉送規則的 VIP。
      • PORT：轉送規則中 PROTOCOL_PORT 欄位的通訊埠號碼。

API

使用 KRM API 建立以 Pod 或 VM 工作負載為目標的 ILB。 這個 ILB 會以專案中符合 Backend 物件所定義標籤的所有工作負載為目標。

如要使用 KRM API 建立區域 ILB，請按照下列步驟操作：

  1. 建立 Backend 資源，定義 ILB 的端點。為工作負載所在的每個可用區建立 Backend 資源：

    kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.gdc.goog/v1
kind: Backend
metadata:
  namespace: PROJECT_NAME
  name: BACKEND_NAME
spec:
  clusterName: CLUSTER_NAME
  endpointsLabels:
    matchLabels:
      app: server
EOF

    更改下列內容：

    • MANAGEMENT_API_SERVER：區域管理 API 伺服器的 kubeconfig 路徑。詳情請參閱「切換至區域環境」。
    • PROJECT_NAME：專案名稱。
    • BACKEND_NAME：Backend 資源的名稱。
    • CLUSTER_NAME：此為選填欄位。這個欄位會指定定義的選取器範圍所限制的叢集。這個欄位不適用於 VM 工作負載。如果 Backend 資源未包含 clusterName 欄位，指定的標籤會套用至專案中的所有工作負載。

    你可以為每個區域使用相同的 Backend 資源，也可以為每個區域建立具有不同標籤集的 Backend 資源。

  2. 如果這個 ILB 是用於 Pod 工作負載，請略過這個步驟。如果您要為 VM 工作負載設定 ILB，請定義 ILB 的健康狀態檢查：

    kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.gdc.goog/v1
kind: HealthCheck
metadata:
  namespace: PROJECT_NAME
  name: HEALTH_CHECK_NAME
spec:
  tcpHealthCheck:
    port: PORT
  timeoutSec: TIMEOUT
  checkIntervalSec: CHECK_INTERVAL
  healthyThreshold: HEALTHY_THRESHOLD
  unhealthyThreshold: UNHEALTHY_THRESHOLD
EOF

    更改下列內容：

    • HEALTH_CHECK_NAME：您為健康狀態檢查資源選擇的名稱，例如 my-health-check。
    • PORT：執行健康狀態檢查的通訊埠。預設值為 80。
    • TIMEOUT：宣告失敗前的等待時間 (以秒為單位)。預設值為 5。
    • CHECK_INTERVAL：從某次探測作業開始到下一次探測作業開始之間的時間長度 (以秒為單位)，預設值為 5。
    • HEALTHY_THRESHOLD：端點必須通過的連續探測次數，才能判定為健康狀態良好。預設值為 2。
    • UNHEALTHY_THRESHOLD：端點必須連續探測失敗的次數，才會被視為健康狀態不良。預設值為 2。

  3. 使用先前建立的 Backend 資源建立 BackendService 物件。如果您要為 VM 工作負載設定 ILB，請加入 HealthCheck 資源。

    kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.gdc.goog/v1
kind: BackendService
metadata:
  namespace: PROJECT_NAME
  name: BACKEND_SERVICE_NAME
spec:
  backendRefs:
  - name: BACKEND_NAME
  healthCheckName: HEALTH_CHECK_NAME
EOF

    更改下列內容：

    • BACKEND_SERVICE_NAME：您為 BackendService 資源選擇的名稱。
    • HEALTH_CHECK_NAME：先前建立的 HealthCheck 資源名稱。如果您要為 Pod 工作負載設定 ILB，請勿加入這個欄位。

  4. 建立內部 ForwardingRule 資源，定義服務可用的 VIP。

    kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.gdc.goog/v1
kind: ForwardingRuleInternal
metadata:
  namespace: PROJECT_NAME
  Name: FORWARDING_RULE_INTERNAL_NAME
spec:
  cidrRef: CIDR
  ports:
  - port: PORT
    Protocol: PROTOCOL
  backendServiceRef:
    name: BACKEND_SERVICE_NAME
EOF

    更改下列內容：

    • FORWARDING_RULE_INTERNAL_NAME：您為 ForwardingRuleInternal 資源選擇的名稱。
    • CIDR：這個欄位為選填。如未指定，系統會從區域 IP 集區自動保留 IPv4/32 CIDR。指定與此轉送規則位於相同命名空間的 Subnet 資源名稱。Subnet 資源代表區域子網路的要求和分配資訊。如要進一步瞭解 Subnet 資源，請參閱「自訂資源範例」。
    • PORT：使用 ports 欄位指定 L4 通訊埠陣列，封包會轉送至透過這項轉送規則設定的後端。至少須指定一個通訊埠。使用 port 欄位指定通訊埠編號。公開的通訊埠必須與容器內實際公開的應用程式相同。

    • PROTOCOL：轉送規則使用的通訊協定，例如 TCP。ports 陣列中的項目必須如下所示：

      ports:
- port: 80
  protocol: TCP

  5. 如要驗證設定的 ILB，請確認每個建立物件的 Ready 條件。透過向 VIP 發出的curl要求驗證流量：

    1. 如要取得 VIP，請使用 kubectl get：

      kubectl get forwardingruleinternal -n PROJECT_NAME

      輸出內容如下：

      NAME           BACKENDSERVICE                               CIDR              READY
ilb-name       BACKEND_SERVICE_NAME        10.200.32.59/32   True

    2. 使用 curl 要求，在轉送規則的 PORT 欄位中指定的通訊埠，驗證 VIP 的流量：

      curl http://FORWARDING_RULE_VIP:PORT

      將 FORWARDING_RULE_VIP 替換為轉送規則的 VIP。

Kubernetes 服務

如要在 GDC 中建立 ILB，請在 Kubernetes 叢集中建立 LoadBalancer 類型的 Kubernetes Service 物件。這個 ILB 只會以建立 Service 物件的叢集中的工作負載為目標。

如要使用 Service 物件建立 ILB，請按照下列步驟操作：

  1. 建立 LoadBalancer 類型的 Service 定義 YAML 檔案。您必須使用 networking.gke.io/load-balancer-type: internal 註解，將 ILB 服務設計為內部服務。

    以下 Service 物件是 ILB 服務的範例：

    apiVersion: v1
kind: Service
metadata:
  annotations:
    networking.gke.io/load-balancer-type: internal
  name: ILB_SERVICE_NAME
  namespace: PROJECT_NAME
spec:
  ports:
  - port: 1234
    protocol: TCP
    targetPort: 1234
  selector:
    k8s-app: my-app
  type: LoadBalancer

    更改下列內容：

    • ILB_SERVICE_NAME：ILB 服務的名稱。
    • PROJECT_NAME：專案的命名空間，其中包含後端工作負載。

    port 欄位會設定您在 VIP 位址上公開的前端通訊埠。 targetPort 欄位會設定後端埠，您要將後端工作負載上的流量轉送至該埠。負載平衡器支援網路位址轉譯 (NAT)。前端和後端連接埠可以不同。

  2. 在 Service 定義的 selector 欄位中，將 Pod 或虛擬機器指定為後端工作負載。

    選取器會根據您指定的標籤與工作負載上的標籤是否相符，定義要將哪些工作負載做為這項服務的後端工作負載。Service 只能選取與定義 Service 時相同的專案和叢集中的後端工作負載。

    如要進一步瞭解服務選取，請參閱 https://kubernetes.io/docs/concepts/services-networking/service/。

  3. 將 Service 定義檔案儲存在與後端工作負載相同的專案中。ILB 服務只能選取與 Service 定義位於相同叢集的工作負載。

  4. 將 Service 定義檔案套用到叢集：

    kubectl apply -f ILB_FILE

    將 ILB_FILE 替換為 ILB 服務的 Service 定義檔名稱。

    建立 ILB 服務時，服務會取得 IP 位址。您可以查看服務狀態，取得 ILB 服務的 IP 位址：

    kubectl -n PROJECT_NAME get svc ILB_SERVICE_NAME

    更改下列內容：

    • PROJECT_NAME：專案的命名空間，其中包含後端工作負載。
    • ILB_SERVICE_NAME：ILB 服務的名稱。

    您必須取得類似下列範例的輸出內容：

    NAME                    TYPE           CLUSTER-IP    EXTERNAL-IP     PORT(S)          AGE
ilb-service             LoadBalancer   10.0.0.1      10.0.0.1        1234:31930/TCP   22h

    「CLUSTER-IP」和「EXTERNAL-IP」欄位必須顯示相同的值，也就是 ILB 服務的 IP 位址。現在，機構中的其他叢集可以存取這個 IP 位址，但須遵守專案的專案網路政策。

    如果沒有取得輸出內容，請確認您已成功建立 ILB 服務。

    GDC 支援服務的網域名稱系統 (DNS) 名稱。不過，這些名稱僅適用於 ILB 服務的相同叢集。如要從其他叢集存取 ILB 服務，必須使用 IP 位址。

建立全域 ILB

使用 gdcloud CLI 或 KRM API 建立全域 ILB。

gdcloud

使用 gdcloud CLI 建立以 Pod 或 VM 工作負載為目標的 ILB。

這個 ILB 會以專案中符合 Backend 物件所定義標籤的所有工作負載為目標。Backend 自訂資源必須限定於某個區域。

如要使用 gdcloud CLI 建立 ILB，請按照下列步驟操作：

  1. 建立 Backend 資源，定義 ILB 的端點：

    gdcloud compute backends create BACKEND_NAME \
  --labels=LABELS \
  --project=PROJECT_NAME \
  --cluster-name=CLUSTER_NAME \
  --zone=ZONE

    更改下列內容：

    • BACKEND_NAME：您為後端資源選擇的名稱，例如 my-backend。
    • LABELS：這個選取器會定義要用於這個後端資源的 Pod 和 VM 之間的端點。例如：app=web。
    • PROJECT_NAME：專案名稱。
    • CLUSTER_NAME：定義選取器範圍的叢集。如未指定這個欄位，系統會選取具有指定標籤的所有端點。這是選填欄位。
    • ZONE：用於這次呼叫的可用區。如要為所有需要區域標記的指令預先設定該標記，請執行：gdcloud config set core/zone ZONE。可用區標記僅適用於多可用區環境。這是選填欄位。

  2. 如果這個 ILB 是用於 Pod 工作負載，請略過這個步驟。如果您要為 VM 工作負載設定 ILB，請定義 ILB 的健康狀態檢查：

    gdcloud compute health-checks create tcp HEALTH_CHECK_NAME \
  --check-interval=CHECK_INTERVAL \
  --healthy-threshold=HEALTHY_THRESHOLD \
  --timeout=TIMEOUT \
  --unhealthy-threshold=UNHEALTHY_THRESHOLD \
  --port=PORT \
  --global

    更改下列內容：

    • HEALTH_CHECK_NAME：您為健康狀態檢查資源選擇的名稱，例如 my-health-check。
    • CHECK_INTERVAL：從某次探測作業開始到下一次探測作業開始之間的時間長度 (以秒為單位)，預設值為 5。這是選填欄位。
    • HEALTHY_THRESHOLD：宣告失敗前等待的時間。預設值為 5。這是選填欄位。
    • TIMEOUT：宣告失敗前的等待時間 (以秒為單位)。預設值為 5。這是選填欄位。
    • UNHEALTHY_THRESHOLD：端點必須連續探測失敗的次數，才會被視為健康狀態不良。預設值為 2。這是選填欄位。
    • PORT：執行健康狀態檢查的通訊埠。預設值為 80。這是選填欄位。

  3. 建立 BackendService 資源，並將先前建立的 Backend 資源新增至其中：

    gdcloud compute backend-services create BACKEND_SERVICE_NAME \
  --project=PROJECT_NAME \
  --target-ports=TARGET_PORTS \
  --health-check=HEALTH_CHECK_NAME \
  --global

    更改下列內容：

    • BACKEND_SERVICE_NAME：這個後端服務的所選名稱。
    • TARGET_PORTS：這個後端服務翻譯的目標通訊埠清單 (以半形逗號分隔)，其中每個目標通訊埠都會指定通訊協定、轉送規則中的通訊埠，以及後端執行個體中的通訊埠。您可以指定多個目標連接埠。這個欄位的格式必須為 protocol:port:targetport，例如 TCP:80:8080。這是選填欄位。
    • HEALTH_CHECK_NAME：健康狀態檢查資源的名稱。這是選填欄位。只有在為 VM 工作負載設定 ILB 時，才需要加入這個欄位。

  4. 將 BackendService 資源新增至先前建立的 Backend 資源：

    gdcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
  --backend-zone BACKEND_ZONE \
  --backend=BACKEND_NAME \
  --project=PROJECT_NAME \
  --global

  5. 建立內部 ForwardingRule 資源，定義服務可用的 VIP：

    gdcloud compute forwarding-rules create FORWARDING_RULE_INTERNAL_NAME \
  --backend-service=BACKEND_SERVICE_NAME \
  --cidr=CIDR \
  --ip-protocol-port=PROTOCOL_PORT \
  --load-balancing-scheme=INTERNAL \
  --project=PROJECT_NAME \
  --global

    更改下列內容：

    • FORWARDING_RULE_INTERNAL_NAME：您為轉送規則選擇的名稱。
    • CIDR：與這項轉送規則位於相同命名空間的 Subnet 資源名稱。Subnet 資源代表全域子網路的請求和分配資訊。如要進一步瞭解 Subnet 資源，請參閱「自訂資源範例」。如未指定，系統會從全域 IP 集區自動保留 IPv4/32 CIDR。這是選填欄位。
    • PROTOCOL_PORT：要在轉送規則中公開的通訊協定和通訊埠。這個欄位的格式必須為 ip-protocol=TCP:80。 公開的通訊埠必須與應用程式在容器內公開的通訊埠相同。

  6. 如要驗證設定的 ILB，請確認每個建立物件的 Ready 條件。透過向 VIP 發出的curl要求驗證流量：

    1. 如要取得指派的 VIP，請說明轉送規則：

      gdcloud compute forwarding-rules describe FORWARDING_RULE_INTERNAL_NAME --global

    2. 使用 curl 要求，在轉送規則的 PROTOCOL_PORT 欄位中指定的通訊埠，驗證 VIP 的流量：

      curl http://FORWARDING_RULE_VIP:PORT

      更改下列內容：

      • FORWARDING_RULE_VIP：轉送規則的 VIP。
      • PORT：轉送規則中 PROTOCOL_PORT 欄位的通訊埠編號。

API

使用 KRM API 建立以 Pod 或 VM 工作負載為目標的 ILB。這個 ILB 會以專案中符合 Backend 物件所定義標籤的所有工作負載為目標。如要使用 KRM API 建立區域 ILB，請按照下列步驟操作：

  1. 建立 Backend 資源，定義 ILB 的端點。為工作負載所在的每個可用區建立 Backend 資源：

    kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: Backend
metadata:
  namespace: PROJECT_NAME
  name: BACKEND_NAME
spec:
  clusterName: CLUSTER_NAME
  endpointsLabels:
    matchLabels:
      app: server
EOF

    更改下列內容：

    • MANAGEMENT_API_SERVER：全域管理 API 伺服器的 kubeconfig 路徑。詳情請參閱「切換至全域環境」。
    • PROJECT_NAME：專案名稱。
    • BACKEND_NAME：Backend 資源的名稱。
    • CLUSTER_NAME：此為選填欄位。這個欄位會指定定義的選取器範圍所限制的叢集。這個欄位不適用於 VM 工作負載。如果 Backend 資源未包含 clusterName 欄位，指定的標籤會套用至專案中的所有工作負載。

    你可以為每個區域使用相同的 Backend 資源，也可以為每個區域建立具有不同標籤集的 Backend 資源。

  2. 如果這個 ILB 是用於 Pod 工作負載，請略過這個步驟。如果您要為 VM 工作負載設定 ILB，請定義 ILB 的健康狀態檢查：

    apiVersion: networking.global.gdc.goog/v1
kind: HealthCheck
metadata:
  namespace: PROJECT_NAME
  name: HEALTH_CHECK_NAME
spec:
  tcpHealthCheck:
    port: PORT
  timeoutSec: TIMEOUT
  checkIntervalSec: CHECK_INTERVAL
  healthyThreshold: HEALTHY_THRESHOLD
  unhealthyThreshold: UNHEALTHY_THRESHOLD

    更改下列內容：

    • HEALTH_CHECK_NAME：您為健康狀態檢查資源選擇的名稱，例如 my-health-check。
    • PORT：執行健康狀態檢查的通訊埠。預設值為 80。
    • TIMEOUT：宣告失敗前的等待時間 (以秒為單位)。預設值為 5。
    • CHECK_INTERVAL：從某次探測作業開始到下一次探測作業開始之間的時間長度 (以秒為單位)，預設值為 5。
    • HEALTHY_THRESHOLD：端點必須通過的連續探測次數，才能判定為健康狀態良好。預設值為 2。
    • UNHEALTHY_THRESHOLD：端點必須連續探測失敗的次數，才會被視為健康狀態不良。預設值為 2。

    由於這是全域 ILB，請在全域 API 中建立健康狀態檢查。

  3. 使用先前建立的 Backend 資源建立 BackendService 物件。如果您要為 VM 工作負載設定 ILB，請加入 HealthCheck 資源。

    kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: BackendService
metadata:
  namespace: PROJECT_NAME
  name: BACKEND_SERVICE_NAME
spec:
  backendRefs:
  - name: BACKEND_NAME
    zone: ZONE
  healthCheckName: HEALTH_CHECK_NAME
  targetPorts:
  - port: PORT
    protocol: PROTOCOL
    targetPort: TARGET_PORT
EOF

    更改下列內容：

    • BACKEND_SERVICE_NAME：您為 BackendService 資源選擇的名稱。
    • HEALTH_CHECK_NAME：先前建立的 HealthCheck 資源名稱。如果您要為 Pod 工作負載設定 ILB，請勿加入這個欄位。

    • ZONE：建立 Backend 資源的可用區。您可以在 backendRefs 欄位中指定多個後端。例如：

      - name: my-be
  zone: Zone-A
- name: my-be
  zone: Zone-B

    • targetPorts 欄位為選填。這項資源會列出 BackendService 資源轉譯的通訊埠。如果您使用這個物件，請提供下列值：

      • PORT：服務公開的通訊埠。
      • PROTOCOL：流量必須符合的第 4 層通訊協定。僅支援 TCP 和 UDP。

      • TARGET_PORT：PORT 值轉譯成的通訊埠，例如 8080。特定物件中的 TARGET_PORT 值不得重複。targetPorts 的範例如下所示：

        targetPorts:
- port: 80
  protocol: TCP
  targetPort: 8080

  4. 建立內部 ForwardingRule 資源，定義服務可用的 VIP。

    kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: ForwardingRuleInternal
metadata:
  namespace: PROJECT_NAME
  Name: FORWARDING_RULE_INTERNAL_NAME
spec:
  cidrRef: CIDR
  ports:
  - port: PORT
    Protocol: PROTOCOL
  backendServiceRef:
    name: BACKEND_SERVICE_NAME
EOF

    更改下列內容：

    • FORWARDING_RULE_INTERNAL_NAME：您為 ForwardingRuleInternal 資源選擇的名稱。
    • CIDR：與這項轉送規則位於相同命名空間的 Subnet 資源名稱。Subnet 資源代表全域子網路的請求和分配資訊。如要進一步瞭解 Subnet 資源，請參閱「自訂資源範例」。如未指定，系統會從全域 IP 集區自動保留 IPv4/32 CIDR。這是選填欄位。
    • PORT：使用 ports 欄位指定 L4 通訊埠陣列，封包會轉送至透過這項轉送規則設定的後端。至少須指定一個通訊埠。使用 port 欄位指定通訊埠號碼。公開的通訊埠必須與容器內實際應用程式公開的通訊埠相同。

    • PROTOCOL：轉送規則使用的通訊協定，例如 TCP。ports 陣列中的項目必須如下所示：

      ports:
- port: 80
  protocol: TCP

  5. 如要驗證設定的 ILB，請確認每個建立物件的 Ready 條件。透過向 VIP 發出的curl要求驗證流量：

    1. 如要取得 VIP，請使用 kubectl get：

      kubectl get forwardingruleinternal -n PROJECT_NAME

      輸出內容如下：

      NAME           BACKENDSERVICE                               CIDR              READY
ilb-name       BACKEND_SERVICE_NAME        10.200.32.59/32   True

    2. 使用 curl 要求，測試轉送規則中 PORT 欄位指定的通訊埠上 VIP 的流量：

      curl http://FORWARDING_RULE_VIP:PORT

      將 FORWARDING_RULE_VIP 替換為轉送規則的 VIP。

為標準叢集建立內部負載平衡器

您可以為標準叢集建立可用區 ILB，但不支援全域 ILB。 區域 ILB 的範圍僅限於建立時指定的區域。詳情請參閱「全域和區域負載平衡器」。

如要為標準叢集建立區域 ILB，請直接在 Kubernetes 叢集中使用 Kubernetes 服務。直接從 Kubernetes 叢集使用 Kubernetes Service 時，您只能以建立 Service 物件的叢集中的工作負載為目標。

為標準叢集建立可用區 ILB

如要在 GDC 中建立 ILB，請在 Kubernetes 叢集中建立 LoadBalancer 類型的 Kubernetes Service 物件。這個 ILB 只會以建立 Service 物件的叢集中的工作負載為目標。

如要使用 Service 物件建立 ILB，請按照下列步驟操作：

  1. 建立 LoadBalancer 類型的 Service 定義 YAML 檔案。您必須使用 networking.gke.io/load-balancer-type: internal 註解，將 ILB 服務設計為內部服務。

    以下 Service 物件是 ILB 服務的範例：

    apiVersion: v1
kind: Service
metadata:
  annotations:
    networking.gke.io/load-balancer-type: internal
  name: ILB_SERVICE_NAME
  namespace: ILB_SERVICE_NAMESPACE
spec:
  ports:
  - port: 1234
    protocol: TCP
    targetPort: 1234
  selector:
    k8s-app: my-app
  type: LoadBalancer

    更改下列內容：

    • ILB_SERVICE_NAME：ILB 服務的名稱。
    • ILB_SERVICE_NAMESPACE：包含後端工作負載的命名空間。

    port 欄位會設定您在 VIP 位址上公開的前端通訊埠。 targetPort 欄位會設定後端埠，您要將後端工作負載上的流量轉送至該埠。負載平衡器支援網路位址轉譯 (NAT)。前端和後端連接埠可以不同。

  2. 在 Service 定義的 selector 欄位中，指定將做為後端工作負載的 Pod。

    選取器會根據您指定的標籤與工作負載上的標籤是否相符，定義要將哪些工作負載做為這項服務的後端工作負載。Service 只能選取與定義 Service 時相同的專案和叢集中的後端工作負載。

    如要進一步瞭解服務選取，請參閱 https://kubernetes.io/docs/concepts/services-networking/service/。

  3. 將 Service 規格儲存為 YAML 檔案。在下列指令中，將檔案名稱替換為 ILB_FILE。ILB 服務只能選取與 Service 定義位於相同叢集的工作負載。

  4. 將 Service 定義檔案套用到叢集：

    export KUBECONFIG=KUBECONFIG_PATH
kubectl apply -f ILB_FILE

    更改下列內容：

    • ILB_FILE：ILB 服務的 Service 定義檔案名稱。
    • KUBECONFIG_PATH：標準叢集的 kubeconfig 檔案路徑。

    建立 ILB 服務時，服務會取得 IP 位址。您可以查看服務狀態，取得 ILB 服務的 IP 位址：

    kubectl -n ILB_SERVICE_NAMESPACE get svc ILB_SERVICE_NAME

    更改下列內容：

    • ILB_SERVICE_NAMESPACE：包含後端工作負載的命名空間。
    • ILB_SERVICE_NAME：ILB 服務的名稱。
    • KUBECONFIG_PATH：標準叢集的 kubeconfig 檔案路徑。

    您會取得類似下列範例的輸出內容：

    NAME                    TYPE           CLUSTER-IP    EXTERNAL-IP     PORT(S)          AGE
ilb-service             LoadBalancer   10.0.0.1      198.51.0.1        1234:31930/TCP   22h

    現在，機構中的其他叢集可以根據專案的專案網路政策存取這個 IP 位址。

選取 VM 做為負載平衡器的後端

如要將 VM 連結至負載平衡器，請按照下列步驟操作：

  1. 確認 VM 的標籤與負載平衡器設定中使用的標籤選取器相符。

    舉例來說，如果 VM 沒有適當的標籤，您可以從對應區域的後端物件，將指定標籤新增至 VM：

    kubectl --kubeconfig MANAGEMENT_API_SERVER label virtualmachine VM_NAME -n PROJECT_NAMELABEL

    更改下列內容：

    • LABEL：與負載平衡器設定中的 LabelSelector 相符的標籤，例如 app=server。
    • VM_NAME：要連結的虛擬機器名稱。
    • PROJECT_NAME：專案名稱。

  2. 確認伺服器正在接聽與 HealthCheck 物件中指定的相同通訊埠。