Google 会使用 AI 技术将内容翻译成您偏好的语言。AI 翻译可能包含错误。

部署高可用性虚拟机应用

本文档介绍了如何在 Google Distributed Cloud (GDC) 网闸隔离配置中部署高可用性 (HA) 虚拟机 (VM) 应用。为确保弹性，您必须跨多个可用区部署应用并配置存储复制，以便在发生意外停机或本地灾难时可以恢复应用及其数据。

本文档适用于负责创建弹性虚拟机工作负载的应用开发者。

如需了解详情，请参阅适用于 GDC 网闸隔离配置文档的受众群体。

目标

在 GDC Universe 中的两个或更多可用区中创建挂接了启动磁盘的虚拟机实例。
配置全球负载均衡。
使用块存储或对象存储区配置存储复制。

准备工作

如需为本文档中的任务做好准备，您必须获取必要的权限并验证您的环境。

请求 IAM 角色和权限

请与您的 IAM 组织管理员联系，申请获得以下角色：

Project VirtualMachine Admin (project-vm-admin)：在项目命名空间中创建和修改虚拟机。
Project Network Policy Admin (global-project-networkpolicy-admin)：跨可用区创建和修改项目网络政策。
Global Load Balancer Admin (global-load-balancer-admin)：创建和修改全球负载均衡器。
Bucket Project Admin (global-project-bucket-admin)：创建和修改双区域存储桶。

如需了解详情，请参阅角色说明。

准备环境

确认您的经过网闸隔离环境中具有以下工具和配置：

安装并配置 gdcloud CLI，然后设置可用区级和全局上下文。如需了解详情，请参阅使用工具访问可用区。
安装 kubectl CLI，并为全局 API 服务器和管理 API 服务器设置适当的 kubeconfig 文件。如需了解详情，请参阅手动生成 kubeconfig 文件。
验证您的 GDC Universe 是否有多个可用可用区。如需了解详情，请参阅列出 Universe 中的可用区。

在多个可用区中创建虚拟机实例

如需创建高可用性虚拟机应用，您必须在 GDC 范围内的每个可用区中创建一个单独的虚拟机实例。

以下步骤使用 GDC 提供的操作系统映像，并将启动磁盘挂接到虚拟机。如需详细了解如何创建虚拟机实例和使用自定义映像，请参阅创建并启动虚拟机。

默认情况下，所有 GDC 项目都可以通过 GDC 提供的操作系统映像创建虚拟机。

控制台

在导航菜单中，依次选择虚拟机 > 实例。
点击创建实例。
在名称字段中，为虚拟机指定名称。
选择要在其中创建虚拟机的可用区。
点击添加标签，为虚拟机分配标签，以便整理虚拟机实例。
选择要用于虚拟机的机器配置。根据您的要求，验证机器类型是否与您的工作负载相符。
点击下一步。
为虚拟机实例启用外部访问权限。
点击下一步。
选择添加新磁盘。
为虚拟机磁盘指定一个名称。
配置磁盘大小和挂接设置。
点击保存。
点击创建以创建虚拟机实例。
对 GDC Universe 中的每个可用区重复上述步骤。确保高可用性策略所需的每个可用区中都有一个虚拟机实例。

gdcloud

登录到您要托管虚拟机实例的可用区：
```
gdcloud config set core/zone ZONE
```
使用 GDC 提供的映像在可用区中创建虚拟机实例：
```
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：新虚拟机的名称。名称只能包含字母数字字符和短划线，且长度不得超过 53 个字符。
- MACHINE_TYPE：新虚拟机的预定义机器类型。如需选择可用的机器类型，请运行 gdcloud compute machine-types list。
- BOOT_DISK_IMAGE_NAME：要用于新虚拟机启动磁盘的映像的名称。
- BOOT_DISK_SIZE：启动磁盘的大小，例如 20GB。此值必须始终大于或等于启动磁盘映像的 minimumDiskSize。
- NO_BOOT_DISK_AUTO_DELETE：删除虚拟机实例时是否自动删除启动磁盘。
对 GDC Universe 中的每个可用区重复上述步骤。确保每个可用区中都有一个虚拟机实例，以满足高可用性策略的要求。

API

使用 GDC 提供的映像在可用区中创建虚拟机实例：
```
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 文件。如果您尚未为 Management API 服务器生成 kubeconfig 文件，请参阅手动生成 kubeconfig 文件了解详情。
- VM_BOOT_DISK_NAME：新虚拟机启动磁盘的名称。
- PROJECT：用于创建虚拟机的 GDC 项目。
- BOOT_DISK_IMAGE_NAME：要用于新虚拟机启动磁盘的映像的名称。
- BOOT_DISK_SIZE：启动磁盘的大小，例如 20Gi。此值必须始终大于或等于启动磁盘映像的 minimumDiskSize。
- VM_NAME：新虚拟机的名称。名称只能包含字母数字字符和短划线，且长度不得超过 53 个字符。
- MACHINE_TYPE：新虚拟机的预定义机器类型。如需选择可用的机器类型，请运行 gdcloud compute machine-types list。
- BOOT_DISK_AUTO_DELETE：删除虚拟机实例时是否自动删除启动磁盘。
验证虚拟机是否可用，并等待虚拟机显示 Running 状态。Running 状态并不表示操作系统已完全准备就绪且可供访问。
```
kubectl --kubeconfig MANAGEMENT_API_SERVER \
    get virtualmachine.virtualmachine.gdc.goog VM_NAME -n PROJECT
```
将 VM_NAME 和 PROJECT 分别替换为虚拟机的名称和项目。
对 GDC 领域中的每个可用区重复上述步骤。确保每个可用区中都有一个虚拟机实例，以满足高可用性策略的要求。

配置负载均衡器

如需在不同可用区中的虚拟机之间分配流量，请创建负载均衡器。您可以在全球范围内配置内部和外部负载均衡器，以确保将客户端请求路由到运行状况良好的可用区。

创建全球内部负载均衡器

内部负载均衡器 (ILB) 通过分配给组织的内部 IP 地址池公开组织内的服务。组织外部的任何端点都无法访问 ILB 服务。

请完成以下步骤，为虚拟机工作负载创建全球 ILB。

gdcloud

使用 gdcloud CLI 创建一个指向虚拟机工作负载的 ILB。

此 ILB 针对项目中与 Backend 对象中定义的标签匹配的所有工作负载。Backend 自定义资源必须限定在可用区范围内。

如需使用 gdcloud CLI 创建 ILB，请按照以下步骤操作：

在运行虚拟机的每个可用区中创建一个可用区级 Backend 资源，以定义 ILB 的端点：
```
gdcloud compute backends create BACKEND_NAME \
    --labels=LABELS \
    --project=PROJECT \
    --zone=ZONE
```
替换以下内容：
- BACKEND_NAME：为后端资源选择的名称，例如 my-backend。
- LABELS：选择器，用于定义要为此后端资源使用的虚拟机之间的端点，例如 app=web。
- PROJECT：您的项目的名称。
- ZONE：要用于此调用的可用区。如需为需要可用区标志的所有命令预设该标志，请运行 gdcloud config set core/zone ZONE。可用区标志仅在多可用区环境中可用。此字段是可选字段。
对 GDC 领域中的每个可用区重复此步骤。
为 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 格式。公开的端口必须与实际应用在虚拟机内公开的端口相同。
如需验证配置的 ILB，请确认每个已创建对象的 Ready 条件。通过向 VIP 发送 curl 请求来验证流量：
1. 如需获取分配的 VIP，请描述转发规则：
```
gdcloud compute forwarding-rules describe FORWARDING_RULE_INTERNAL_NAME --global
```
2. 通过向转发规则中字段指定的端口上的 VIP 发送 curl 请求来验证流量：
```
curl http://FORWARDING_RULE_VIP:PORT
```
替换以下内容：
- FORWARDING_RULE_VIP：转发规则的 VIP。
- PORT：转发规则的端口号。

API

使用 KRM API 创建一个以虚拟机工作负载为目标的 ILB。此 ILB 针对项目中与 Backend 对象中定义的标签匹配的所有工作负载。如需使用 KRM API 创建全球 ILB，请按照以下步骤操作：

创建 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:
  endpointsLabels:
    matchLabels:
      app: APP_NAME
EOF
```
替换以下内容：
- MANAGEMENT_API_SERVER：可用区级 Management API 服务器的 kubeconfig 路径。如需了解详情，请参阅切换到可用区级上下文。
- PROJECT：您的项目的名称。
- BACKEND_NAME：Backend 资源的名称。
- APP_NAME：虚拟机应用的名称。
您可以为每个可用区使用相同的 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. 通过向转发规则字段中指定的端口上的 VIP 发送 curl 请求来测试流量：
```
curl http://FORWARDING_RULE_VIP:PORT
```
  替换以下内容：
  - FORWARDING_RULE_VIP：转发规则的 VIP。
  - PORT：转发规则中字段的端口号。

创建全球外部负载均衡器

外部负载均衡器 (ELB) 会公开服务，以便从组织外部通过从较大的实例外部 IP 地址池分配给组织的池 IP 地址进行访问。

请完成以下步骤，为虚拟机工作负载创建全球 ELB。

gdcloud

使用 gdcloud CLI 创建一个全局 ELB，该 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：负载均衡器后端的虚拟机上的后端端口。此值位于 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：一个选择器，用于定义要为此后端资源使用虚拟机之间的哪些端点，例如 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 格式。公开的端口必须与实际应用在虚拟机内公开的端口相同。
- PROJECT：您的项目的名称。
如需验证配置的 ELB，请确认每个已创建对象的 Ready 条件。通过向 VIP 发送 curl 请求来验证流量：
1. 如需获取分配的 VIP，请描述转发规则：
```
gdcloud compute forwarding-rules describe FORWARDING_RULE_EXTERNAL_NAME
```
2. 通过向转发规则的 PROTOCOL_PORT 字段中指定的端口上的 VIP 发送 curl 请求来验证流量：
```
curl http://FORWARDING_RULE_VIP:PORT
```
  替换以下内容：
  - FORWARDING_RULE_VIP：转发规则的 VIP。
  - PORT：转发规则中 PROTOCOL_PORT 字段的端口号。

API

使用 KRM API 创建一个以虚拟机工作负载为目标的 ELB。此 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：负载均衡器后端的虚拟机上的后端端口。此值位于 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 条件。尝试通过向 VIP 发送 curl 请求来测试流量。
1. 检索项目的 VIP：
```
kubectl get forwardingruleexternal -n PROJECT
```
  输出如下所示：
```
NAME           BACKENDSERVICE                  CIDR              READY
elb-name       BACKEND_SERVICE_NAME            192.0.2.0/32      True
```
2. 通过向转发规则中 PORT 字段指定的端口上的 VIP 发送 curl 请求来验证流量：
```
curl http://FORWARDING_RULE_VIP:PORT
```
  将 FORWARDING_RULE_VIP:PORT 替换为转发规则的 VIP 和端口，例如 192.0.2.0:80。

配置存储空间复制

GDC 多可用区 Universe 支持存储复制，以实现灾难恢复。此策略可在同一区域中的任意两个可用区之间进行数据复制，确保即使某个可用区不可用，您的应用数据仍可访问。

为虚拟机应用选择以下存储复制类型之一：

对象复制
异步块复制

创建用于对象存储区的双可用区存储桶

对象存储数据会写入单个存储桶，其数据存储在两个可用区中。与卷复制不同，复制的存储桶在可用区隔离期间可写入。每次对对象的写入都会产生一个不同的版本，连接性恢复后，两个可用区中的最新版本将成为最终状态。

请与您的基础架构运营商 (IO) 确认，Universe 中的所有可用区都处于在线状态且可访问。
验证您的基础设施运维人员 (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：存储桶的名称。
- PROJECT：存储桶所在项目的名称。
- LOCATION_NAME：存储桶中的对象数据所在的物理位置。此名称必须映射到现有 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 创建。

如需详细了解如何管理虚拟机工作负载的异步复制，请参阅异步复制卷。

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：卷复制关系的名称。

如需详细了解如何管理虚拟机工作负载的异步复制，请参阅异步复制卷。

部署高可用性虚拟机应用 使用集合让一切井井有条 根据您的偏好保存内容并对其进行分类。

目标

准备工作

请求 IAM 角色和权限

准备环境

在多个可用区中创建虚拟机实例

控制台

gdcloud

API

配置负载均衡器

创建全球内部负载均衡器

gdcloud

API

创建全球外部负载均衡器

gdcloud

API

配置存储空间复制

创建用于对象存储区的双可用区存储桶

配置跨可用区的异步块存储复制

gdcloud

API

后续步骤

部署高可用性虚拟机应用