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

本文說明如何在 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 專案和容器映像檔。
  • 全域 PNP 管理員 (global-project-networkpolicy-admin)：在各區域建立及編輯專案網路政策。
  • 全域負載平衡器管理員 (global-load-balancer-admin)：建立及編輯全域負載平衡器。
  • 磁碟區複製全域管理員 (app-volume-replication-admin-global)： 管理區塊儲存空間資源的磁碟區複製關係。
  • Bucket 專案管理員 (global-project-bucket-admin)：建立及編輯雙區域儲存空間 bucket。

詳情請參閱角色說明。

準備環境

請確認您在無網路連線環境中具備下列工具和設定：

在多個區域中建立 Kubernetes 叢集

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

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

控制台

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

  2. 點選「建立叢集」。

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

  4. 選取叢集的 Kubernetes 版本。

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

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

  7. 點選「下一步」。

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

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

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

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

    4. 點選「下一步」。

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

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

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

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

      • 機型
      • CPU
      • 記憶體

    4. 按一下 [儲存]。

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

  11. 針對 GDC 宇宙中的每個區域重複執行上述步驟。請確保每個要納入高可用性策略的區域都有 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

    更改下列內容：

    • ：區域管理 API 伺服器的 kubeconfig 路徑。MANAGEMENT_API_SERVER詳情請參閱「切換至區域環境」。
    • 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：節點集區工作站節點的機型。如要查看可設定的項目，請參閱可用的機器類型。
    • 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 宇宙中的每個區域重複執行這個步驟。

  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 條件。使用 curl 要求向 VIP 驗證流量：

    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 條件。使用 curl 要求向 VIP 驗證流量：

    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 條件。使用 curl 要求向 VIP 驗證流量：

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

      gdcloud compute forwarding-rules describe FORWARDING_RULE_EXTERNAL_NAME

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

      curl http://FORWARDING_RULE_VIP:PORT

      更改下列內容：

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

API

使用 KRM API 建立以 Pod 工作負載為目標的 ELB。這個 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 宇宙中的每個區域重複上述步驟。請確認容器應用程式位於您希望用於高可用性策略的每個區域。

使用 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 多可用區宇宙支援儲存空間複製功能，可供災難復原。這項策略可在同一區域的任意兩個可用區之間複製資料，確保即使某個可用區無法使用，應用程式資料仍可存取。

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

建立雙區域 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：儲存空間 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：磁碟區副本關係的名稱。

後續步驟