部署高可用性容器應用程式

本文說明如何在 Google Distributed Cloud (GDC) 實體隔離環境中，部署高可用性 (HA) Kubernetes 容器應用程式。為確保復原能力，您必須在多個可用區部署應用程式，並設定儲存空間複製功能，以便在發生非預期停機或本機災難時復原應用程式和資料。

本文件適用於負責建立彈性容器工作負載的應用程式開發人員。

詳情請參閱「GDC 實體隔離方案說明文件的目標對象」。

目標

  • 在 GDC 宇宙中的兩個以上可用區建立 Kubernetes 叢集。
  • 設定全域負載平衡。
  • 將容器工作負載部署至各個可用區 Kubernetes 叢集。
  • 佈建儲存空間並附加至 Pod。
  • 使用區塊儲存空間或物件儲存庫，設定儲存空間複製功能。

事前準備

如要準備執行本文件中的工作，您必須取得必要權限並驗證環境。

要求 IAM 角色和權限

請與 IAM 機構組織管理員聯絡，要求下列角色：

  • 命名空間管理員 (namespace-admin)：在共用叢集中建立及編輯容器工作負載。
  • 使用者叢集管理員 (user-cluster-admin)：建立及編輯共用叢集。
  • 使用者叢集開發人員 (user-cluster-developer)：在共用叢集中建立及編輯節點集區。
  • Harbor 執行個體管理員 (harbor-instance-admin)：建立及編輯 Harbor 執行個體、Harbor 專案和容器映像檔。
  • 專案網路政策管理員 (global-project-networkpolicy-admin)：建立及編輯各可用區的專案網路政策。
  • 全域負載平衡器管理員 (global-load-balancer-admin)：建立及編輯全域負載平衡器。
  • 磁碟區複製全域管理員 (app-volume-replication-admin-global)：管理區塊儲存空間資源的磁碟區複製關係。
  • Bucket 專案管理員 (global-project-bucket-admin)：建立及編輯雙可用區儲存空間 bucket。

詳情請參閱角色說明。

準備環境

確認實體隔離環境中具備下列工具和設定：

在多個可用區建立 Kubernetes 叢集

如要建立高可用性的容器應用程式，您必須在 GDC universe 的每個可用區中，建立獨立的共用 Kubernetes 叢集。

如要進一步瞭解可用的叢集設定選項，請參閱「Kubernetes 叢集設定」。

控制台

  1. 在導覽選單中，依序選取 「Kubernetes Engine」 > 「叢集」。

  2. 點選「建立叢集」。

  3. 在「Name」(名稱) 欄位中，指定叢集名稱。

  4. 選取叢集的 Kubernetes 版本。

  5. 選取要建立叢集的可用區。

  6. 按一下「Attach Project」(附加專案)，然後選取要附加至叢集的現有專案。點選這個選項後，按一下 [儲存]。建立叢集後，您可以透過「Project details」(專案詳細資料) 頁面附加或卸載專案。您必須先將專案附加至叢集，才能在叢集部署容器工作負載。

  7. 點選「下一步」。

  8. 設定叢集的網路設定。叢集建立後，您就無法變更這些網路設定。Kubernetes 叢集預設且唯一支援的網際網路通訊協定是網際網路通訊協定第 4 版 (IPv4)。

    1. 指定負載平衡器 IP 位址集區大小，例如 20。

    2. 選取要使用的 Service CIDR (無類別跨網域路由)。系統會從這個範圍內，為您部署的服務 (例如負載平衡器) 分配 IP 位址。

    3. 選取要使用的 Pod CIDR。叢集會從這個範圍分配 IP 位址給 Pod 和 VM。

    4. 點選「下一步」。

  9. 查看叢集自動生成的預設節點集區詳細資料。按一下「 Edit」(編輯)，修改預設節點集區。

  10. 如要建立其他節點集區，請選取「新增節點集區」。編輯預設節點集區或新增節點集區時，您可以使用下列選項進行自訂：

    1. 為節點集區命名。節點集區建立後即無法修改名稱。
    2. 指定要在節點集區中建立的 worker 節點數量。

    3. 請依據工作負載需求，選取最合適的機器類別。查看下列設定清單：

      • 機型
      • CPU
      • 記憶體

    4. 按一下 [儲存]。

    5. 點選「建立」來建立叢集。

  11. 針對 GDC universe 中的每個可用區重複執行上述步驟。請確認您要用於高可用性策略的每個可用區中，都有 Kubernetes 叢集。

API

如要直接使用 API 建立新的 Kubernetes 叢集，請將自訂資源套用至各個 GDC 可用區。

  1. 建立 Cluster 自訂資源，並部署至區域的 Management API 伺服器：

    kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: cluster.gdc.goog/v1
kind: Cluster
metadata:
  name: CLUSTER_NAME
  namespace: platform
spec:
  clusterNetwork:
    podCIDRSize: POD_CIDR
    serviceCIDRSize: SERVICE_CIDR
  initialVersion:
    kubernetesVersion: KUBERNETES_VERSION
  nodePools:
  - machineTypeName: MACHINE_TYPE
    name: NODE_POOL_NAME
    nodeCount: NUMBER_OF_WORKER_NODES
    taints: TAINTS
    labels: LABELS
    acceleratorOptions:
      gpuPartitionScheme: GPU_PARTITION_SCHEME
  releaseChannel:
    channel: UNSPECIFIED
EOF

    更改下列內容：

    • MANAGEMENT_API_SERVER：可用區 Management API 伺服器的 kubeconfig 路徑。詳情請參閱「切換至可用區環境」。
    • CLUSTER_NAME：叢集名稱。叢集名稱結尾不得為 -system。-system 後置字串是保留給 GDC 建立的叢集。
    • POD_CIDR：分配 Pod 虛擬 IP 位址 (VIP) 的網路範圍大小。如未設定，系統會使用預設值 21。
    • SERVICE_CIDR：分配服務 VIP 的網路範圍大小。如未設定，系統會使用預設值 23。
    • KUBERNETES_VERSION：叢集的 Kubernetes 版本，例如 1.26.5-gke.2100。如要列出可設定的 Kubernetes 版本，請參閱「列出叢集可用的 Kubernetes 版本」。
    • MACHINE_TYPE：節點集區 worker 節點的機型。請參閱可用的機型，瞭解可設定的項目。
    • NODE_POOL_NAME：節點集區的名稱。
    • NUMBER_OF_WORKER_NODES：要在節點集區中佈建的 worker 節點數量。
    • TAINTS：要套用至這個節點集區節點的 taint。這是選填欄位。
    • LABELS：要套用至這個節點集區節點的標籤。其中包含鍵/值組合清單。這是選填欄位。
    • GPU_PARTITION_SCHEME：GPU 分割配置 (如果您執行 GPU 工作負載)，例如 mixed-2。如未設定這個欄位，GPU 就不會分區。如要瞭解可用的多實體 GPU (MIG) 設定檔，請參閱「支援的 MIG 設定檔」。

  2. 針對要託管容器應用程式的每個可用區，重複執行前述步驟，以實施高可用性策略。

設定負載平衡器

如要在不同可用區的 Pod 之間分配流量，請建立負載平衡器。您可以在全域設定內部和外部負載平衡器，確保用戶端要求會轉送至健康狀態良好的可用區。

建立全域內部負載平衡器

內部負載平衡器 (ILB) 會從指派給組織的內部 IP 位址集區，公開組織內的服務。組織外部的任何端點都無法存取 ILB 服務。

請按照下列步驟，為容器工作負載建立全域 ILB。

gdcloud

使用 gdcloud CLI 建立指定 Pod 工作負載的 ILB。

這個 ILB 會指定專案中所有符合 Backend 物件定義標籤的工作負載。Backend 自訂資源必須限定在特定可用區。

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

  1. 在 Pod 運作的每個可用區中建立可用區 Backend 資源，定義 ILB 的端點：

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

    更改下列內容：

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

    針對 GDC universe 中的每個可用區，重複執行這個步驟。

  2. 建立全域 BackendService 資源：

    gdcloud compute backend-services create BACKEND_SERVICE_NAME \
    --project=PROJECT \
    --target-ports=TARGET_PORTS \
    --global

    更改下列內容：

    • BACKEND_SERVICE_NAME：後端服務的名稱。
    • PROJECT：專案名稱。
    • TARGET_PORTS：以半形逗號分隔的清單，列出這項後端服務轉譯的目標通訊埠，其中每個目標通訊埠都會指定通訊協定、轉送規則上的通訊埠，以及後端執行個體上的通訊埠。您可以指定多個目標通訊埠。這個欄位的格式必須為 protocol:port:targetport，例如 TCP:80:8080。這是選填欄位。

  3. 將 BackendService 資源新增至各可用區中先前建立的 Backend 資源：

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

    更改下列內容：

    • BACKEND_SERVICE_NAME：全域後端服務的名稱。
    • ZONE：後端的可用區。
    • BACKEND_NAME：可用區後端的名稱。
    • PROJECT：專案名稱。

    請為先前建立的每個可用區後端完成這個步驟。

  4. 建立內部 ForwardingRule 資源，定義服務可用的虛擬 IP 位址 (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 \
    --global

    更改下列內容：

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

  5. 如要驗證設定的 ILB，請確認每個建立的物件是否符合 Ready 條件。向 VIP 傳送 curl 要求，驗證流量：

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

      gdcloud compute forwarding-rules describe FORWARDING_RULE_INTERNAL_NAME --global

    2. 向轉送規則欄位中指定的通訊埠，傳送 curl 要求至 VIP，驗證流量：

      curl http://FORWARDING_RULE_VIP:PORT

    更改下列內容：

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

API

使用 KRM API 建立以容器工作負載為目標的 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: BACKEND_NAME
spec:
  clusterName: CLUSTER_NAME
  endpointsLabels:
    matchLabels:
      app: APP_NAME
EOF

    更改下列內容：

    • MANAGEMENT_API_SERVER：可用區 Management API 伺服器的 kubeconfig 路徑。詳情請參閱「切換至可用區環境」。
    • PROJECT：專案名稱。
    • BACKEND_NAME：Backend 資源的名稱。
    • CLUSTER_NAME：定義的選取器範圍僅限於這個 Kubernetes 叢集。如未指定這個欄位，系統會選取具有指定標籤的所有端點。這是選填欄位。
    • APP_NAME：容器應用程式的名稱。

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

  2. 使用先前建立的 Backend 資源建立 BackendService 物件。請務必加入 HealthCheck 資源：

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

    更改下列內容：

    • GLOBAL_API_SERVER：全域 API 伺服器的 kubeconfig 路徑。
    • PROJECT：專案名稱。
    • BACKEND_SERVICE_NAME：您為 BackendService 資源選擇的名稱。
    • HEALTH_CHECK_NAME：先前建立的 HealthCheck 資源名稱。
    • BACKEND_NAME：可用區Backend資源的名稱。

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

      - name: my-backend-1
  zone: us-east1-a
- name: my-backend-2
  zone: us-east1-b

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

    • PORT：服務公開的通訊埠。

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

    • TARGET_PORT：值轉譯後的通訊埠，例如 8080。指定物件中的值不得重複。

      targetPorts 的範例如下：

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

  3. 建立內部 ForwardingRule 資源，定義服務可用的虛擬 IP 位址 (VIP)。

    kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: ForwardingRuleInternal
metadata:
  namespace: PROJECT
  name: FORWARDING_RULE_INTERNAL_NAME
spec:
  cidrRef:
    name: CIDR_NAME
  ports:
  - port: PORT
    protocol: PROTOCOL
  backendServiceRef:
    name: BACKEND_SERVICE_NAME
EOF

    更改下列內容：

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

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

      ports:
- port: 80
  protocol: TCP

  4. 如要驗證設定的 ILB，請確認每個建立的物件是否符合 Ready 條件。向 VIP 傳送 curl 要求，驗證流量：

    1. 擷取 VIP：

      kubectl get forwardingruleinternal -n PROJECT

      輸出內容如下：

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

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

      curl http://FORWARDING_RULE_VIP:PORT

      更改下列內容：

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

建立全域外部負載平衡器

外部負載平衡器 (ELB) 會從指派給組織的集區 IP 位址 (來自較大的執行個體外部 IP 位址集區)，公開服務以供組織外部存取。

請完成下列步驟，為容器工作負載建立全域 ELB。

gdcloud

使用 gdcloud CLI 建立全域 ELB，指定專案中所有符合 Backend 物件定義標籤的工作負載。Backend 自訂資源必須限定在可用區範圍內。

  1. 如要使用 ELB 服務，您必須設定並套用自訂的 ProjectNetworkPolicy 資料移入政策，允許流量傳送至這項 ELB 服務的工作負載。網路政策會控管工作負載的存取權，而非負載平衡器本身。ELB 會將工作負載公開至客戶網路，因此需要明確的網路政策，允許外部流量傳送至工作負載通訊埠，例如 8080。

    指定外部 CIDR 位址，允許流量傳送至這個 ELB 的工作負載：

    kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT
  name: allow-inbound-traffic-from-external
spec:
  policyType: Ingress
  subject:
    subjectType: UserWorkload
  ingress:
  - from:
    - ipBlock:
        cidr: CIDR
    ports:
    - protocol: TCP
      port: PORT
EOF

    更改下列內容：

    • GLOBAL_API_SERVER：全域 API 伺服器的 kubeconfig 路徑。如果您尚未為全域 API 伺服器產生 kubeconfig 檔案，請參閱「手動產生 kubeconfig 檔案」一文。
    • PROJECT：專案名稱。
    • CIDR：ELB 必須從這個外部 CIDR 存取。外部負載平衡器會使用直接伺服器回傳 (DSR)，保留來源外部 IP 位址，並在傳回路徑上略過負載平衡器，因此必須採用這項政策。詳情請參閱「為組織外部流量建立全域輸入防火牆規則」。
    • PORT：負載平衡器後方 Pod 的後端通訊埠。這個值位於 Service 資源資訊清單的 .spec.ports[].targetPortfield 欄位中。這是選填欄位。

    這項設定可讓專案內的所有資源存取指定的 CIDR 範圍。

  2. 在每個可用區中建立 Backend 資源，定義 ELB 的端點：

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

    更改下列內容：

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

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

  3. 建立全域 BackendService 資源：

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

    更改下列內容：

    • BACKEND_SERVICE_NAME：為這項後端服務選擇的名稱。
    • PROJECT：專案名稱。
    • TARGET_PORTS：以半形逗號分隔的清單，列出這項後端服務轉譯的目標通訊埠，其中每個目標通訊埠都會指定通訊協定、轉送規則的通訊埠，以及後端執行個體的通訊埠。您可以指定多個目標通訊埠。這個欄位必須採用 protocol:port:targetport 格式，例如 TCP:80:8080。這是選填欄位。
    • HEALTH_CHECK_NAME：健康狀態檢查資源的名稱。這是選填欄位。

  4. 將全域 BackendService 資源新增至先前建立的可用區 Backend 資源：

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

    請為先前建立的每個可用區後端完成這個步驟。

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

    gdcloud compute forwarding-rules create FORWARDING_RULE_EXTERNAL_NAME \
  --backend-service=BACKEND_SERVICE_NAME \
  --cidr=CIDR \
  --ip-protocol-port=PROTOCOL_PORT \
  --load-balancing-scheme=EXTERNAL \
  --project=PROJECT \
  --global

    更改下列內容：

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

  6. 如要驗證設定的 ELB，請確認每個建立的物件是否符合 Ready 條件。向 VIP 傳送 curl 要求，驗證流量：

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

      gdcloud compute forwarding-rules describe FORWARDING_RULE_EXTERNAL_NAME

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

      curl http://FORWARDING_RULE_VIP:PORT

      更改下列內容：

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

API

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

  1. 如要使用 ELB 服務，您必須設定並套用自訂的 ProjectNetworkPolicy 資料移入政策，允許流量傳送至這項 ELB 服務的工作負載。網路政策會控管工作負載的存取權，而非負載平衡器本身。ELB 會將工作負載公開至客戶網路，因此需要明確的網路政策，允許外部流量傳送至工作負載通訊埠，例如 8080。

    指定外部 CIDR 位址，允許流量傳送至這個 ELB 的工作負載：

    kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT
  name: allow-inbound-traffic-from-external
spec:
  policyType: Ingress
  subject:
    subjectType: UserWorkload
  ingress:
  - from:
    - ipBlock:
        cidr: CIDR
    ports:
    - protocol: TCP
      port: PORT
EOF

    更改下列內容：

    • GLOBAL_API_SERVER：全域 API 伺服器的 kubeconfig 路徑。如果您尚未為全域 API 伺服器產生 kubeconfig 檔案，請參閱「手動產生 kubeconfig 檔案」一文。
    • PROJECT：專案名稱。
    • CIDR：ELB 必須從這個外部 CIDR 存取。外部負載平衡器會使用直接伺服器回傳 (DSR)，保留來源外部 IP 位址，並在傳回路徑上略過負載平衡器，因此必須採用這項政策。詳情請參閱「為組織外部流量建立全域輸入防火牆規則」。
    • PORT：負載平衡器後方 Pod 的後端通訊埠。這個值位於 Service 資源資訊清單的 .spec.ports[].targetPortfield 欄位中。這是選填欄位。

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

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

    更改下列內容：

    • MANAGEMENT_API_SERVER：可用區 Management API 伺服器的 kubeconfig 路徑。如果您尚未為目標可用區中的 API 伺服器產生 kubeconfig 檔案，請參閱「手動產生 kubeconfig 檔案」一節，瞭解相關詳情。
    • PROJECT：專案名稱。
    • BACKEND_NAME：Backend 資源的名稱。
    • CLUSTER_NAME：定義的選取器範圍僅限於這個 Kubernetes 叢集。如未指定這個欄位，系統會選取所有具有指定標籤的端點。這是選填欄位。
    • APP_NAME：容器應用程式的名稱。

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

  3. 使用先前建立的 Backend 資源建立 BackendService 物件：

    kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: BackendService
metadata:
  namespace: PROJECT
  name: BACKEND_SERVICE_NAME
spec:
  backendRefs:
  - name: BACKEND_NAME
    zone: ZONE
  healthCheckName: HEALTH_CHECK_NAME
EOF

    更改下列內容：

    • BACKEND_SERVICE_NAME：您為 BackendService 資源選擇的名稱。
    • HEALTH_CHECK_NAME：先前建立的 HealthCheck 資源名稱。如果您要為 Pod 工作負載設定 ELB，請勿加入這個欄位。
    • ZONE：Backend 資源所在的可用區。您可以在 backendRefs 欄位中指定多個後端。例如：
    - name: my-backend-1
  zone: us-east1-a
- name: my-backend-2
  zone: us-east1-b

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

    kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: ForwardingRuleExternal
metadata:
  namespace: PROJECT
  name: FORWARDING_RULE_EXTERNAL_NAME
spec:
  cidrRef:
    name: CIDR_NAME
  ports:
  - port: PORT
    protocol: PROTOCOL
  backendServiceRef:
    name: BACKEND_SERVICE_NAME
EOF

    更改下列內容：

    • FORWARDING_RULE_EXTERNAL_NAME：您為 ForwardingRuleExternal 資源選擇的名稱。
    • CIDR_NAME：轉送規則要使用的 CIDR 名稱。這是選填欄位。如未指定，系統會自動從全域 IP 位址集區保留 IPv4/32 CIDR。指定與這項轉送規則位於相同命名空間的 Subnet 資源名稱。Subnet 資源代表全域子網路的要求和分配資訊。如要進一步瞭解 Subnet 資源，請參閱「管理子網路」。
    • PORT：要在轉送規則上公開的通訊埠。請使用 ports 欄位指定 L4 通訊埠陣列，封包會轉送至使用這項轉送規則設定的後端。至少須指定一個通訊埠。使用 port 欄位指定通訊埠編號。公開的通訊埠必須與實際應用程式在容器內公開的通訊埠相同。
    • PROTOCOL：轉送規則使用的通訊協定，例如 TCP。ports 陣列中的項目必須如下所示：
    ports:
- port: 80
  protocol: TCP

  5. 如要驗證設定的 ELB，請確認每個建立的物件是否符合 Ready 條件。請嘗試使用 curl 要求測試傳送至 VIP 的流量。

    1. 擷取專案的 VIP：

      kubectl get forwardingruleexternal -n PROJECT

      輸出內容如下：

      NAME           BACKENDSERVICE                  CIDR              READY
elb-name       BACKEND_SERVICE_NAME            192.0.2.0/32      True

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

      curl http://FORWARDING_RULE_VIP:PORT

      將 FORWARDING_RULE_VIP:PORT 替換為轉送規則的 VIP 和通訊埠，例如 192.0.2.0:80。

將容器工作負載部署至各可用區叢集

容器工作負載並非全域資源，因此您必須將每個容器應用程式分別部署至可用區 Kubernetes 叢集。

  1. 登入託管 Kubernetes 叢集的可用區：

    gdcloud config set core/zone ZONE

  2. 確認代管 Harbor 登錄檔中有容器映像檔。詳情請參閱「部署容器應用程式」教學課程。

  3. 為容器工作負載建立資訊清單檔案，並部署至可用區 Kubernetes 叢集：

    kubectl --kubeconfig KUBERNETES_CLUSTER -n PROJECT apply -f - <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: DEPLOYMENT_NAME
spec:
  replicas: NUMBER_OF_REPLICAS
  selector:
    matchLabels:
      run: APP_NAME
  template:
    metadata:
      labels:
        run: APP_NAME
    spec:
      containers:
      - name: CONTAINER_NAME
        image: HARBOR_INSTANCE_URL/HARBOR_PROJECT_NAME/IMAGE:TAG
EOF

    更改下列內容：

    • KUBERNETES_CLUSTER：可用於部署容器工作負載的可用區 Kubernetes 叢集 kubeconfig 檔案。如果您尚未為可用區 Kubernetes 叢集產生 kubeconfig 檔案，請參閱「手動產生 kubeconfig 檔案」一節，瞭解相關詳情。
    • PROJECT：要部署容器工作負載的專案命名空間。
    • DEPLOYMENT_NAME：容器部署作業的名稱。
    • NUMBER_OF_REPLICAS：Deployment 管理的 Pod 物件副本數量。
    • APP_NAME：要在部署作業中執行的應用程式名稱。
    • CONTAINER_NAME：容器名稱。
    • HARBOR_INSTANCE_URL：Harbor 執行個體的網址，例如 harbor-1.org-1.zone1.google.gdc.test.。如要擷取 Harbor 執行個體的網址，請參閱「查看 Harbor 登錄檔執行個體」。
    • HARBOR_PROJECT_NAME：Harbor 專案的名稱，例如 my-project。
    • IMAGE：映文件名稱，例如 nginx。
    • TAG：要提取的映像檔版本標記，例如 1.0。

  4. 針對 GDC universe 中的每個可用區，重複執行上述步驟。請確認容器應用程式位於高可用性策略所需的每個可用區。

使用 Kubernetes 公開容器應用程式

您必須公開容器應用程式，才能允許 GDC 宇宙中的其他資源存取。

  1. 建立 type: LoadBalancer 的 Service 資源。這項資源會透過網路公開應用程式的 Pod。

    kubectl --kubeconfig KUBERNETES_CLUSTER -n PROJECT apply -f - <<EOF
apiVersion: v1
kind: Service
metadata:
  name: SERVICE_NAME
spec:
  selector:
    app: APP_NAME
  ports:
    - port: 80
      protocol: TCP
  type: LoadBalancer
EOF

    更改下列內容：

    • KUBERNETES_CLUSTER：可用於部署容器工作負載的可用區 Kubernetes 叢集 kubeconfig 檔案。
    • PROJECT：容器工作負載所在的專案命名空間。
    • SERVICE_NAME：負載平衡器服務的名稱。
    • APP_NAME：您為容器應用程式套用的標籤。

  2. 建立 NetworkPolicy 自訂資源，允許所有網路流量傳送至預設命名空間：

    kubectl --kubeconfig KUBERNETES_CLUSTER -n PROJECT apply -f - <<EOF
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  annotations:
  name: allow-all
spec:
  ingress:
  - from:
    - ipBlock:
        cidr: 0.0.0.0/0
  podSelector: {}
  policyTypes:
  - Ingress
EOF

為 Pod 佈建永久儲存空間

您必須建立 PersistentVolumeClaim 資源 (PVC)，為應用程式 Pod 提供永久儲存空間。

下列操作說明說明如何使用 GDC standard-rwo StorageClass 建立磁碟區。

  1. 建立 PersistentVolumeClaim 資源。例如，使用 ReadWriteOnce 存取模式和 standard-rwo 儲存空間級別進行設定：

    kubectl --kubeconfig KUBERNETES_CLUSTER -n PROJECT apply -f - <<EOF
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: PVC_NAME
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: standard-rwo
EOF

    更改下列內容：

    • KUBERNETES_CLUSTER：Kubernetes 叢集的 kubeconfig 檔案。
    • PROJECT：要在其中建立 PVC 的專案命名空間。
    • PVC_NAME：PersistentVolumeClaim 物件的名稱。

  2. PersistentVolume (PV) 物件會動態佈建。檢查 Kubernetes 叢集中新 PV 的狀態：

    kubectl get pv --kubeconfig KUBERNETES_CLUSTER

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

    NAME       CAPACITY   ACCESS MODES   STATUS      CLAIM     STORAGECLASS   AGE
pvc-uuidd  10Gi       RWO            Bound       pvc-name  standard-rwo   60s

  3. 設定容器工作負載，以便使用 PVC。以下是使用 standard-rwo PVC 的 Pod 資訊清單範例：

    kubectl --kubeconfig KUBERNETES_CLUSTER -n PROJECT apply -f - <<EOF
apiVersion: apps/v1
kind: Pod
metadata:
  name: web-server-deployment
  labels:
    app: APP_LABEL
spec:
  containers:
  - name: CONTAINER_NAME
    image: HARBOR_INSTANCE_URL/HARBOR_PROJECT_NAME/IMAGE:TAG
    volumeMounts:
    - mountPath: MOUNT_PATH
      name: data
  volumes:
  - name: data
    persistentVolumeClaim:
      claimName: PVC_NAME
EOF

    更改下列內容：

    • KUBERNETES_CLUSTER：Kubernetes 叢集的 kubeconfig 檔案，用於部署容器工作負載。
    • PROJECT：PVC 所在的專案命名空間。
    • APP_LABEL：您為容器應用程式套用的標籤。
    • CONTAINER_NAME：容器名稱。
    • HARBOR_INSTANCE_URL：Harbor 執行個體的網址，例如 harbor-1.org-1.zone1.google.gdc.test.。如要擷取 Harbor 執行個體的網址，請參閱「查看 Harbor 登錄檔執行個體」。
    • HARBOR_PROJECT_NAME：Harbor 專案的名稱，例如 my-project。
    • IMAGE：映文件名稱，例如 nginx。
    • TAG：要提取的映像檔版本標記，例如 1.0。
    • MOUNT_PATH：Pod 內要掛接磁碟區的路徑。
    • PVC_NAME：您建立的 PVC。

設定儲存空間複製功能

GDC 多可用區 universe 支援儲存空間複製功能，可用於災難復原。這項策略可在同一區域的任兩個可用區之間複製資料，確保即使某個可用區無法使用，應用程式資料仍可存取。

為容器應用程式選擇下列其中一種儲存空間複製類型：

建立雙可用區 bucket 來儲存物件儲存庫

物件儲存庫資料會寫入單一 bucket，其資料會儲存在兩個可用區中。與磁碟區複製不同，複製的 bucket 在可用區失聯期間可寫入。每次寫入物件都會產生不同版本，連線能力恢復後，兩個可用區中的最新版本會成為最終狀態。

  1. 確認基礎架構運作人員 (IO) 已建立 BucketLocationConfig 自訂資源，這是物件儲存庫跨可用區複製的必要資源。這項資源必須部署至根層級全域 API 伺服器。

  2. 建立雙可用區 Bucket 自訂資源：

    kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: object.global.gdc.goog/v1
kind: Bucket
metadata:
  name: BUCKET_NAME
  namespace: PROJECT
spec:
  location: LOCATION_NAME
  description: Sample DZ Bucket
  storageClass: Standard
EOF

    更改下列內容：

    • GLOBAL_API_SERVER：全域 API 伺服器的 kubeconfig 檔案。
    • BUCKET_NAME：Storage bucket 的名稱。
    • PROJECT：bucket 所在專案的名稱。
    • LOCATION_NAME：bucket 中物件資料所在的實體位置。這必須對應至現有 BucketLocation 資源的名稱。如要查詢貴組織的全域 API 伺服器，取得可用的 BucketLocation 資源清單，請執行 kubectl --kubeconfig GLOBAL_API_SERVER bucketlocations。如果沒有 BucketLocation 資源，請與 IO 聯絡，確認對方已啟用複製功能。

設定跨可用區非同步區塊儲存空間複製作業

複製的區塊儲存空間提供非同步複製的磁碟區 (PV)，可維持主要和次要磁碟區之間的區塊等效性。由於非同步特性，次要磁碟區會反映主要可用區在過去某個時間點的狀態 (非零 RPO)。次要磁碟區在仍是複製目標時無法掛接，需要手動介入才能終止關係並啟用寫入。

您必須設定跨可用區的儲存空間複製關係，才能建立複製資料，以便在來源可用區資料無法使用時進行容錯移轉。如果您為容器應用程式使用區塊儲存空間，則適用這項設定。

開始之前，請確認基礎架構運算子 (IO) 已建立並設定 StorageClusterPeering 和 StorageVirtualMachinePeering 自訂資源，允許跨可用區複製區塊儲存空間。這項資源必須部署至根層級全域 API 伺服器。

  1. 建立 VolumeReplicationRelationship 自訂資源 YAML 檔案，並部署至全域 API 伺服器：

    kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: storage.global.gdc.goog/v1
kind: VolumeReplicationRelationship
metadata:
  name: PVC_REPL_NAME
  namespace: PROJECT
spec:
  source:
    pvc:
      clusterRef: SOURCE_PVC_CLUSTER
      pvcRef: SOURCE_PVC
    zoneRef: SOURCE_ZONE
destination:
    pvc:
      clusterRef: DEST_PVC_CLUSTER
    zoneRef: DEST_ZONE
EOF

    更改下列內容：

    • GLOBAL_API_SERVER：全域 API 伺服器的 kubeconfig 檔案。
    • PVC_REPL_NAME：磁碟區複製關係的名稱。
    • PROJECT：儲存空間基礎架構所在的專案。
    • SOURCE_PVC_CLUSTER：託管 PVC 的 Kubernetes 叢集。
    • SOURCE_PVC：來源可用區中要複製的 PVC。
    • SOURCE_ZONE：託管 PVC 的來源可用區。
    • DEST_PVC_CLUSTER：要將 PVC 複製到的目的地 Kubernetes 叢集。
    • DEST_ZONE：要複製 PVC 的目的地可用區。

  2. 在目的地區建立 VolumeFailover 自訂資源，如果來源區因任何原因無法使用，就會停止複製到目的地區：

    kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: storage.gdc.goog/v1
kind: VolumeFailover
metadata:
  name: PVC_FAILOVER_NAME
  namespace: PROJECT
spec:
  volumeReplicationRelationshipRef: PVC_REPL_NAME
EOF

    更改下列內容：

    • MANAGEMENT_API_SERVER：可用區 Management API 伺服器的 kubeconfig 檔案。
    • PVC_FAILOVER_NAME：PVC 容錯移轉的名稱。
    • PROJECT：儲存空間基礎架構所在的專案。
    • PVC_REPL_NAME：磁碟區複製關係的名稱。

後續步驟