部署高可用性 VM 應用程式

本頁面提供建議的部署策略,協助您在 Google Distributed Cloud (GDC) 氣隙環境中,建構穩健的高可用性 (HA) 虛擬機器 (VM) 應用程式。您必須在多個 GDC 區域部署 VM 應用程式,並設定非同步儲存空間複製功能,這樣一來,如果發生非預期的停機或區域性災害,應用程式及其資料就能復原。

本頁內容適用於應用程式運算子群組中的開發人員,他們負責為所屬機構建立應用程式工作負載。詳情請參閱 GDC air-gapped 說明文件適用對象

目標

  • 在 GDC 宇宙的兩個或多個可用區中,建立附加開機磁碟的 VM 執行個體。
  • 設定全域負載平衡。
  • 使用區塊儲存空間或物件儲存空間,設定非同步儲存空間複製作業。

事前準備

  • 確認您在 GDC 宇宙中工作,且有多個可用區域。執行 gdcloud zones list,列出您宇宙中可用的可用區。詳情請參閱「列出宇宙中的區域」。

  • 請機構 IAM 管理員授予下列角色:

    • 建立及管理 VM 工作負載的 VM 角色
    • 負載平衡器管理員 (load-balancer-admin) 和全域負載平衡器管理員 (global-load-balancer-admin) 角色。您必須具備這些角色,才能建立及管理負載平衡器。
    • 磁碟區複製全域管理員角色 (app-volume-replication-admin-global)。您必須具備這個角色,才能管理磁碟區複製作業。
    • 全球 PNP 管理員 () 角色。global-project-networkpolicy-admin您必須具備這個角色,才能跨區域建立及管理專案網路政策。
    • 磁碟區副本全域管理員 (app-volume-replication-admin-global) 角色,可管理區塊儲存空間資源的磁碟區副本關係。
    • 專案值區物件管理員 (project-bucket-object-admin) 和專案值區管理員 (project-bucket-admin) 角色,可建立及管理儲存空間值區。

    詳情請參閱角色說明

  • 安裝並設定 gdcloud CLI,然後設定區域和全域環境。詳情請參閱跨區域管理資源

  • 安裝及設定 kubectl CLI,並為全域 API 伺服器和 Management API 伺服器設定適當的 kubeconfig 檔案。詳情請參閱「手動產生 kubeconfig 檔案」一節。

在多個可用區中建立 VM 執行個體

VM 執行個體是區域性資源,因此您必須在每個區域中分別建立 VM。在本範例中,您將使用 GDC 提供的 OS 映像檔建立 VM 執行個體,並將開機磁碟連接至 VM。如要進一步瞭解如何建立 VM 執行個體及使用自訂映像檔,請參閱「建立及啟動 VM」。

根據預設,所有 GDC 專案都可以使用 GDC 提供的 OS 映像檔建立 VM。

主控台

  1. 在導覽選單中,依序選取「Virtual Machines」>「Instances」(虛擬機器 > 執行個體)
  2. 點選「建立執行個體」
  3. 在「Name」(名稱) 欄位中,指定 VM 的名稱。
  4. 選取要建立 VM 的可用區。
  5. 按一下「新增標籤」,將標籤指派給 VM,方便管理 VM 執行個體。
  6. 選取要用於 VM 的機器設定。視需求而定,確認機器類型符合工作負載。
  7. 點選「下一步」
  8. 啟用 VM 執行個體的外部存取權。
  9. 點選「下一步」
  10. 選取「新增磁碟」
  11. 為 VM 磁碟指派名稱。
  12. 設定磁碟大小和附加設定。
  13. 按一下 [儲存]
  14. 按一下「建立」,建立 VM 執行個體。
  15. 針對 GDC 宇宙中的每個區域重複上述步驟。請確保每個可用區都有 VM 執行個體,以符合高可用性策略的需求。

gdcloud

  1. 登入要代管 VM 執行個體的區域:

    gdcloud config set core/zone ZONE
    
  2. 使用 GDC 提供的映像檔,在可用區中建立 VM 執行個體:

    gdcloud compute instances create VM_NAME \
        --machine-type=MACHINE_TYPE \
        --image=BOOT_DISK_IMAGE_NAME
        --image-project=vm-system \
        --boot-disk-size=BOOT_DISK_SIZE \
        --no-boot-disk-auto-delete=NO_BOOT_DISK_AUTO_DELETE
    

    更改下列內容:

    • VM_NAME:新 VM 的名稱。名稱只能包含英數字元和破折號,且不得超過 53 個字元。
    • MACHINE_TYPE:新 VM 的預先定義機器類型。如要選取可用的機器類型,請執行 gdcloud compute machine-types list
    • BOOT_DISK_IMAGE_NAME:新 VM 開機磁碟要使用的映像檔名稱。
    • BOOT_DISK_SIZE:開機磁碟大小,例如 20GB。這個值一律必須大於或等於開機磁碟映像檔的 minimumDiskSize
    • NO_BOOT_DISK_AUTO_DELETE:是否要在刪除 VM 執行個體時自動刪除開機磁碟。
  3. 針對 GDC 宇宙中的每個區域重複上述步驟。請確保每個可用區都有 VM 執行個體,以符合高可用性策略的需求。

API

  1. 使用 GDC 提供的映像檔,在可用區中建立 VM 執行個體:

    kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
    apiVersion: virtualmachine.gdc.goog/v1
    kind: VirtualMachineDisk
    metadata:
      name: VM_BOOT_DISK_NAME
      namespace: PROJECT
    spec:
      source:
        image:
          name: BOOT_DISK_IMAGE_NAME
          namespace: vm-system
      size: BOOT_DISK_SIZE
    ---
    apiVersion: virtualmachine.gdc.goog/v1
    kind: VirtualMachine
    metadata:
      name: VM_NAME
      namespace: PROJECT
    spec:
      compute:
        virtualMachineType: MACHINE_TYPE
      disks:
        - virtualMachineDiskRef:
            name: VM_BOOT_DISK_NAME
          boot: true
          autoDelete: BOOT_DISK_AUTO_DELETE
    ---
    apiVersion: virtualmachine.gdc.goog/v1
    kind: VirtualMachineExternalAccess
    metadata:
      name: VM_NAME
      namespace: PROJECT
    spec:
      enabled: true
      ports:
      - name: port-80
        port: 80
        protocol: TCP
    EOF
    

    更改下列內容:

    • MANAGEMENT_API_SERVER:用於建立 VM 執行個體的可用區管理 API 伺服器 kubeconfig 檔案。如果尚未為 Management API 伺服器產生 kubeconfig 檔案,請參閱「手動產生 kubeconfig 檔案」一文瞭解詳情。
    • VM_BOOT_DISK_NAME:新 VM 開機磁碟的名稱。
    • PROJECT:用於建立 VM 的 GDC 專案。
    • BOOT_DISK_IMAGE_NAME:新 VM 開機磁碟要使用的映像檔名稱。
    • BOOT_DISK_SIZE:開機磁碟大小,例如 20Gi。這個值一律必須大於或等於開機磁碟映像檔的 minimumDiskSize
    • VM_NAME:新 VM 的名稱。名稱只能包含英數字元和破折號,且不得超過 53 個字元。
    • MACHINE_TYPE:新 VM 的預先定義機器類型。如要選取可用的機器類型,請執行 gdcloud compute machine-types list
    • BOOT_DISK_AUTO_DELETE:是否要在刪除 VM 執行個體時自動刪除開機磁碟。
  2. 確認 VM 可用,並等待 VM 顯示 Running 狀態。Running 狀態並不表示作業系統已完全就緒且可供存取。

    kubectl --kubeconfig MANAGEMENT_API_SERVER \
        get virtualmachine.virtualmachine.gdc.goog VM_NAME -n PROJECT
    

    VM_NAMEPROJECT 替換為 VM 的名稱和專案。

  3. 針對 GDC 宇宙中的每個區域重複上述步驟。請確保每個可用區都有 VM 執行個體,以符合高可用性策略的需求。

設定負載平衡器

如要在不同區域的 VM 之間分配流量,請建立負載平衡器。您可以選擇建立外部負載平衡器 (ELB) 和內部負載平衡器 (ILB),這兩種負載平衡器都可以區域或全域設定。在本範例中,請為 VM 應用程式設定全域 ILB 和全域 ELB。

建立全域內部負載平衡器

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

如要為 VM 工作負載建立全域 ILB,請完成下列步驟。

gdcloud

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

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

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

  1. 在 VM 執行的每個區域中,建立區域 Backend 資源,定義 ILB 的端點:

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

    更改下列內容:

    • BACKEND_NAME:後端資源的所選名稱,例如 my-backend
    • LABELS:定義要用於這個後端資源的 VM 間端點,例如 app=web
    • PROJECT:專案名稱。
    • ZONE:這次呼叫要使用的區域。如要為所有需要區域旗標的指令預設區域旗標,請執行 gdcloud config set core/zone ZONE。可用區旗標僅適用於多可用區環境。這是選填欄位。

    針對 GDC 宇宙中的每個區域重複執行這個步驟。

  2. 定義 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 資源:

    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-zone=ZONE \
        --backend=BACKEND_NAME \
        --project=PROJECT \
        --global
    

    更改下列內容:

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

    針對先前建立的每個區域後端,完成這個步驟。

  5. 建立內部 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。公開的通訊埠必須與 VM 內實際公開的應用程式相同。
  6. 如要驗證設定的 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 建立以 VM 工作負載為目標的 ILB。這個 ILB 會以專案中符合 Backend 物件所定義標籤的所有工作負載為目標。如要使用 KRM API 建立全域 ILB,請按照下列步驟操作:

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

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

    更改下列內容:

    • MANAGEMENT_API_SERVER:區域管理 API 伺服器的 kubeconfig 路徑。詳情請參閱「切換至區域環境」。
    • PROJECT:專案名稱。
    • BACKEND_NAME:資源的名稱。Backend
    • APP_NAME:VM 應用程式的名稱。

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

  2. 定義 ILB 的全域健康狀態檢查:

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

    更改下列內容:

    • GLOBAL_API_SERVER:全域 API 伺服器的 kubeconfig 路徑。詳情請參閱「切換至全域環境」。
    • PROJECT:專案名稱。
    • HEALTH_CHECK_NAME:健康狀態檢查資源的名稱,例如 my-health-check
    • PORT:執行健康檢查的通訊埠。預設值為 80
    • TIMEOUT:宣告失敗前的等待時間 (以秒為單位)。預設值為 5
    • CHECK_INTERVAL:從某次探測作業開始到下一次探測作業開始之間的時間長度 (以秒為單位)。預設值為 5
    • HEALTHY_THRESHOLD:端點必須通過的連續探測次數,才能判定為健康狀態良好。預設值為 2
    • UNHEALTHY_THRESHOLD:端點必須連續探測失敗的次數,才會被視為健康狀態不良。預設值為 2
  3. 使用先前建立的 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
    • ZONEBackend 資源所在的可用區。您可以在 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
      
  4. 建立內部 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: CIDR
      ports:
      - port: PORT
        protocol: PROTOCOL
      backendServiceRef:
        name: BACKEND_SERVICE_NAME
    EOF
    

    更改下列內容:

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

      ports:
      - port: 80
        protocol: TCP
      
  5. 如要驗證設定的 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 位址集區存取服務。

如要為 VM 工作負載建立全域 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 位址,並略過回傳路徑上的負載平衡器,因此必須採用這項政策。詳情請參閱「為跨機構流量建立全域 Ingress 防火牆規則」。
    • PORT:負載平衡器後方 VM 的後端通訊埠。這個值位於 Service 資源資訊清單的 .spec.ports[].targetPortfield 欄位中。這是選填欄位。

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

  2. 在每個可用區建立 Backend 資源,定義 ELB 的端點:

    gdcloud compute backends create BACKEND_NAME \
      --labels=LABELS \
      --project=PROJECT
    

    更改下列內容:

    • BACKEND_NAME:後端資源的名稱,例如 my-backend
    • LABELS:定義要用於這個後端資源的 VM 端點 (例如 app=web) 的選取器。
    • PROJECT:專案名稱。

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

  3. 為 ELB 定義全域健康狀態檢查:

    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。這是選填欄位。
  4. 建立全域 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:健康狀態檢查資源的名稱。這是選填欄位。
  5. 將全域 BackendService 資源新增至先前建立的區域 Backend 資源:

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

    針對先前建立的每個區域後端,完成這個步驟。

  6. 建立外部 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。 公開的通訊埠必須與 VM 內實際應用程式公開的通訊埠相同。
    • PROJECT:專案名稱。
  7. 如要驗證設定的 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 建立以 VM 工作負載為目標的 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 位址,並略過回傳路徑上的負載平衡器,因此必須採用這項政策。詳情請參閱「為跨機構流量建立全域 Ingress 防火牆規則」。
    • PORT:負載平衡器後方 VM 的後端通訊埠。這個值位於 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:
      endpointsLabels:
        matchLabels:
          app: server
    EOF
    

    更改下列內容:

    • MANAGEMENT_API_SERVER:區域管理 API 伺服器的 kubeconfig 路徑。如果尚未為目標區域中的 API 伺服器產生 kubeconfig 檔案,請參閱「手動產生 kubeconfig 檔案」一文瞭解詳情。
    • PROJECT:專案名稱。
    • BACKEND_NAMEBackend資源的名稱。

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

  3. 為 ELB 定義全域健康狀態檢查:

    kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
    apiVersion: networking.global.gdc.goog/v1
    kind: HealthCheck
    metadata:
      namespace: PROJECT
      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

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

  4. 使用先前建立的 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,請勿加入這個欄位。
    • ZONEBackend 資源所在的可用區。您可以在 backendRefs 欄位中指定多個後端。例如:
    - name: my-backend-1
      zone: us-east1-a
    - name: my-backend-2
      zone: us-east1-b
    
  5. 建立外部 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: CIDR
      ports:
      - port: PORT
        protocol: PROTOCOL
      backendServiceRef:
        name: BACKEND_SERVICE_NAME
    EOF
    

    更改下列內容:

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

設定非同步儲存空間複製

在災難復原情境中,GDC 多區域宇宙可讓您以非同步模式使用複製的儲存空間資源,例如磁碟區和 bucket。這些儲存空間資源選項可在同一區域的任意兩個可用區之間,提供非同步資料複製功能。非同步複製會在背景執行,因此發生災難時,復原點目標 (RPO) 雖然很低,但不會是零。所有複製的資料都會處於線上狀態,且可立即存取,但可能需要手動執行容錯移轉程序,才能在次要區域啟用寫入作業。

您可以為 VM 應用程式選擇下列其中一種非同步儲存空間複製類型:

建立雙區域 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:儲存空間值區的名稱。
    • PROJECT:bucket 所在的專案名稱。
    • LOCATION_NAME:值區中物件資料所在的實體位置。這必須對應至現有 BucketLocation 資源的名稱。如要查詢貴機構的全球 API 伺服器,取得可用 BucketLocation 資源清單,請執行 kubectl --kubeconfig GLOBAL_API_SERVER bucketlocations。如果沒有 BucketLocation 資源,請與 IO 聯絡,確認他們是否已啟用非同步複製功能。

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

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

您必須將 VolumeReplicationRelationship 自訂資源部署至全域 API 伺服器,才能建立可供容錯移轉的複製資料,以防來源區域資料無法使用。

開始前,請先確認基礎架構運算子 (IO) 已建立並設定 StorageClusterPeeringStorageVirtualMachinePeering 自訂資源,允許跨區域的區塊儲存空間複製作業。這項資源必須部署至根層級的全球 API 伺服器。

gdcloud

  1. 在主要區域和次要區域之間設定非同步複製磁碟區關係:

    gdcloud compute disks start-async-replication PRIMARY_DISK_NAME \
        --project PROJECT \
        --zone PRIMARY_ZONE \
        --secondary-disk SECONDARY_DISK_NAME \
        --secondary-zone SECONDARY_ZONE
    

    更改下列內容:

    • PRIMARY_DISK_NAME:要複製的來源磁碟名稱。
    • PROJECT:主要磁碟的 GDC 專案。
    • PRIMARY_ZONE:主要磁碟所在的區域。
    • SECONDARY_DISK_NAME:要複製到的目的地磁碟名稱。
    • SECONDARY_ZONE:次要磁碟所在的區域。
  2. 在目的地區域建立 VolumeFailover 自訂資源,如果來源區域因任何原因無法使用,系統會停止複製到目的地區域:

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

    更改下列內容:

    • MANAGEMENT_API_SERVER:管理 API 伺服器的 kubeconfig 檔案。
    • FAILOVER_NAME:容錯移轉的名稱。
    • PROJECT:儲存空間基礎架構所在的專案。
    • REPL_NAME:磁碟區複製關係的名稱。

    如要進一步瞭解如何管理 VM 工作負載的非同步複製功能,請參閱「非同步複製磁碟區」。

API

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

    kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
    apiVersion: storage.global.gdc.goog/v1
    kind: VolumeReplicationRelationship
    metadata:
      name: VRR_NAME
      namespace: PROJECT
    spec:
      source:
        virtualMachineDisk:
          virtualMachineDiskRef: PRIMARY_DISK_NAME
        zoneRef: PRIMARY_ZONE
      destination:
        volumeOverrideName: SECONDARY_DISK_NAME
        zoneRef: SECONDARY_ZONE
    EOF
    

    更改下列內容:

    • GLOBAL_API_SERVER:全域管理 API 伺服器的 kubeconfig 檔案。
    • VRR_NAME:磁碟區複製關係的名稱。停止非同步複製時,必須使用相同的名稱。
    • PROJECT:主要磁碟的 GDC 專案。
    • PRIMARY_DISK_NAME:要複製的來源磁碟名稱。
    • PRIMARY_ZONE:主要磁碟所在的區域。
    • SECONDARY_DISK_NAME:要複製到的目的地磁碟名稱。
    • SECONDARY_ZONE:次要磁碟必須所在的區域。
  2. 在目的地區域建立 VolumeFailover 自訂資源,如果來源區域因任何原因無法使用,系統會停止複製到目的地區域:

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

    更改下列內容:

    • MANAGEMENT_API_SERVER:管理 API 伺服器的 kubeconfig 檔案。
    • FAILOVER_NAME:容錯移轉的名稱。
    • PROJECT:儲存空間基礎架構所在的專案。
    • REPL_NAME:磁碟區複製關係的名稱。

如要進一步瞭解如何管理 VM 工作負載的非同步複製功能,請參閱「非同步複製磁碟區」。

後續步驟