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

部署高可用性 VM 應用程式

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

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

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

目標

在 GDC 宇宙中，建立一個 VM 執行個體，並在兩個以上的可用區中連接開機磁碟。
設定全域負載平衡。
使用區塊儲存空間或物件儲存庫，設定儲存空間複製作業。

事前準備

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

要求 IAM 角色和權限

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

專案 VirtualMachine 管理員 (project-vm-admin)：在專案命名空間中建立及編輯 VM。
專案網路政策管理員 (global-project-networkpolicy-admin)：建立及編輯各可用區的專案網路政策。
全域負載平衡器管理員 (global-load-balancer-admin)：建立及編輯全域負載平衡器。
Bucket 專案管理員 (global-project-bucket-admin)：建立及編輯雙可用區儲存空間 bucket。

詳情請參閱角色說明。

準備環境

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

安裝及設定 gdcloud CLI，並設定可用區和全域環境。詳情請參閱「使用工具存取區域」。
安裝 kubectl CLI，並為全域 API 伺服器和 Management API 伺服器設定適當的 kubeconfig 檔案。詳情請參閱「手動產生 kubeconfig 檔案」。
確認 GDC 宇宙有多個可用可用區。詳情請參閱「列出宇宙中的可用區」。

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

如要建立高可用性 VM 應用程式，您必須在 GDC 宇宙的每個可用區中建立獨立的 VM 執行個體。

下列步驟會使用 GDC 提供的 OS 映像檔，並將開機磁碟附加至 VM。如要進一步瞭解如何建立 VM 執行個體及使用自訂映像檔，請參閱「建立及啟動 VM」。

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

控制台

在導覽選單中，依序選取「Virtual Machines」>「Instances」。
點選「建立執行個體」。
在「Name」(名稱) 欄位中，指定 VM 的名稱。
選取要建立 VM 的可用區。
按一下「Add Labels」(新增標籤)，為 VM 指派任何標籤，以便整理 VM 執行個體。
選取要用於 VM 的機器設定。請根據需求，確認機器類型符合工作負載。
點選「下一步」。
為 VM 執行個體啟用外部存取權。
點選「下一步」。
選取「新增磁碟」。
為 VM 磁碟命名。
設定磁碟大小和連接設定。
按一下 [儲存]。
按一下「建立」，建立 VM 執行個體。
針對 GDC universe 中的每個可用區，重複執行上述步驟。請確保高可用性策略中的每個可用區都有 VM 執行個體。

gdcloud

登入要託管 VM 執行個體的可用區：
```
gdcloud config set core/zone ZONE
```
使用 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 執行個體刪除時，是否自動刪除開機磁碟。
針對 GDC universe 中的每個可用區，重複執行上述步驟。請確認高可用性策略中的每個可用區都有 VM 執行個體。

API

使用 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：Management API 伺服器 kubeconfig 檔案，用於建立 VM 執行個體的可用區。如果您尚未為 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 執行個體刪除時，是否自動刪除開機磁碟。
確認 VM 可用，並等待 VM 顯示 Running 狀態。Running 狀態並不表示 OS 已完全就緒且可供存取。
```
kubectl --kubeconfig MANAGEMENT_API_SERVER \
    get virtualmachine.virtualmachine.gdc.goog VM_NAME -n PROJECT
```
將 VM_NAME 和 PROJECT 替換為 VM 的名稱和專案。
針對 GDC universe 中的每個可用區，重複執行上述步驟。請確認高可用性策略中的每個可用區都有 VM 執行個體。

設定負載平衡器

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

建立全域內部負載平衡器

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

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

gdcloud

使用 gdcloud CLI 建立 ILB，並指定 VM 工作負載為目標。

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

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

在 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 universe 中的每個可用區，重複執行這個步驟。
為 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。這是選填欄位。
建立全域 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：健康狀態檢查資源的名稱。這是選填欄位。
將 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：專案名稱。
請為先前建立的每個可用區後端完成這個步驟。
建立內部 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 內公開的通訊埠相同。
如要驗證設定的 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，請按照下列步驟操作：

建立 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：可用區 Management API 伺服器的 kubeconfig 路徑。詳情請參閱「切換至可用區環境」。
- PROJECT：專案名稱。
- BACKEND_NAME：Backend 資源的名稱。
- APP_NAME：VM 應用程式的名稱。
您可以為每個可用區使用相同的 Backend 資源，或為每個可用區建立具有不同標籤集的 Backend 資源。
為 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。
使用先前建立的 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
```
建立內部 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
```
如要驗證設定的 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 自訂資源必須限定在可用區範圍內。

如要讓 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：負載平衡器後方 VM 的後端通訊埠。這個值位於 Service 資源資訊清單的 .spec.ports[].targetPortfield 欄位中。這是選填欄位。
這項設定可讓專案內的所有資源存取指定的 CIDR 範圍。

注意： gdcloud CLI 不支援建立全域專案網路政策的指令，因此您必須改用 KRM API。
在每個可用區中建立 Backend 資源，定義 ELB 的端點：
```
gdcloud compute backends create BACKEND_NAME \
  --labels=LABELS \
  --project=PROJECT
```
更改下列內容：
- BACKEND_NAME：後端資源的名稱，例如 my-backend。
- LABELS：定義要為這個後端資源使用 VM 之間哪些端點的選取器，例如 app=web。
- PROJECT：專案名稱。
您可以為每個可用區使用相同的 Backend 資源，或為每個可用區建立具有不同標籤集的 Backend 資源。
為 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。這是選填欄位。
建立全域 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：健康狀態檢查資源的名稱。這是選填欄位。

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

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

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

建立外部 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：專案名稱。
如要驗證設定的 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，並指定 VM 工作負載為目標。這個 ELB 會指定專案中符合 Backend 物件定義標籤的所有工作負載。如要使用 KRM API 建立可用區 ELB，請按照下列步驟操作：

如要使用 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：負載平衡器後方 VM 的後端通訊埠。這個值位於 Service 資源資訊清單的 .spec.ports[].targetPortfield 欄位中。這是選填欄位。
注意： 這項設定會為專案中的所有資源提供指定 CIDR 範圍的存取權。
建立 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：可用區 Management API 伺服器的 kubeconfig 路徑。如果您尚未為目標可用區中的 API 伺服器產生 kubeconfig 檔案，請參閱「手動產生 kubeconfig 檔案」一節，瞭解相關詳情。
- PROJECT：專案名稱。
- BACKEND_NAME：Backend 資源的名稱。
您可以為每個可用區使用相同的 Backend 資源，或為每個可用區建立具有不同標籤集的 Backend 資源。
為 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 中建立健康狀態檢查。

使用先前建立的 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

建立外部 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
```
如要驗證設定的 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 多可用區 universe 支援儲存空間複製功能，可用於災難復原。這項策略可在同一區域的任兩個可用區之間複製資料，確保即使某個可用區無法使用，應用程式資料仍可存取。

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

物件複製
非同步區塊複製

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

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

請向基礎架構營運商 (IO) 確認，宇宙中的所有可用區都已上線且可連線。
確認基礎架構運作人員 (IO) 已建立 BucketLocationConfig 自訂資源，這是物件儲存庫跨可用區複製的必要條件。這項資源必須部署至根層級全域 API 伺服器。
建立雙可用區 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)。次要磁碟區在仍是複製目標時無法掛接，需要手動介入才能終止關係並啟用寫入。

您必須將 VolumeReplicationRelationship 自訂資源部署至全域 API 伺服器，建立複製資料，以便在來源可用區資料無法使用時，用於容錯移轉。

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

gdcloud

設定主要可用區和次要可用區之間的非同步複製磁碟區關係：
```
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：次要磁碟必須所在的可用區。
在目的地區建立 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：Management API 伺服器的 kubeconfig 檔案。
- FAILOVER_NAME：容錯移轉的名稱。
- PROJECT：儲存空間基礎架構所在的專案。
- REPL_NAME：磁碟區複製關係的名稱。
注意： gdcloud CLI 不支援建立磁碟區容錯移轉，因此您必須使用 kubectl CLI 建立。

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

API

建立 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：全域 Management API 伺服器的 kubeconfig 檔案。
- VRR_NAME：磁碟區複製關係的名稱。停止非同步複製時，必須使用相同名稱。
- PROJECT：主要磁碟的 GDC 專案。
- PRIMARY_DISK_NAME：要複製的來源磁碟名稱。
- PRIMARY_ZONE：主要磁碟所在的可用區。
- SECONDARY_DISK_NAME：要複製到的目的地磁碟名稱。
- SECONDARY_ZONE：次要磁碟必須所在的可用區。
在目的地區建立 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：Management API 伺服器的 kubeconfig 檔案。
- FAILOVER_NAME：容錯移轉的名稱。
- PROJECT：儲存體基礎架構所在的專案。
- REPL_NAME：磁碟區複製關係的名稱。

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

部署高可用性 VM 應用程式 透過集合功能整理內容 你可以依據偏好儲存及分類內容。

目標

事前準備

要求 IAM 角色和權限

準備環境

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

控制台

gdcloud

API

設定負載平衡器

建立全域內部負載平衡器

gdcloud

API

建立全域外部負載平衡器

gdcloud

API

設定儲存空間複製功能

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

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

gdcloud

API

後續步驟

部署高可用性 VM 應用程式