部署高可用性容器应用

控制台

1. 在导航菜单中，依次选择 Kubernetes Engine > 集群。

2. 点击创建集群。

3. 在名称字段中，指定集群的名称。

4. 选择集群的 Kubernetes 版本。

5. 选择要在其中创建集群的可用区。

6. 点击关联项目，然后选择要关联到集群的现有项目。然后，点击保存。创建集群后，您可以在项目详情页面中附加或分离项目。您必须先将项目附加到集群，然后才能在集群中部署容器工作负载。

7. 点击下一步。

8. 为集群配置投放网络设置。创建集群后，您将无法更改这些投放网络设置。Kubernetes 集群默认且唯一支持的互联网协议是互联网协议版本 4 (IPv4)。

   1. 指定负载均衡器 IP 地址池大小，例如 20。

   2. 选择要使用的服务 CIDR（无类别域间路由）。系统会从此范围为已部署的服务（例如负载均衡器）分配 IP 地址。

   3. 选择要使用的 Pod CIDR。集群会从此范围中为您的 Pod 和虚拟机分配 IP 地址。

   4. 点击下一步。

9. 查看为集群自动生成的默认节点池的详细信息。点击 edit 修改以修改默认节点池。

10. 如需创建其他节点池，请选择添加节点池。修改默认节点池或添加新节点池时，您可以使用以下选项对其进行自定义：

    1. 为节点池分配名称。创建节点池后，您将无法修改名称。
    2. 指定要在节点池中创建的工作器节点数。

    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
   

   替换以下内容：

   • 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：节点池的工作器节点的机器类型。查看可用的机器类型，了解可配置的类型。
   • NODE_POOL_NAME：节点池的名称。
   • NUMBER_OF_WORKER_NODES：要在节点池中预配的工作器节点数。
   • TAINTS：要应用于此节点池的节点的污点。此为可选字段。
   • LABELS：要应用于此节点池的节点的标签。它包含一个键值对列表。此为可选字段。
   • GPU_PARTITION_SCHEME：GPU 分区方案（如果您运行的是 GPU 工作负载），例如 mixed-2。如果未设置此字段，则不会对 GPU 进行分区。如需了解可用的多实例 GPU (MIG) 配置文件，请参阅支持的 MIG 配置文件。

2. 针对您希望托管容器应用以实现高可用性策略的每个可用区，重复执行上一步。

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 条件。通过向 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，请按照以下步骤操作：

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. 通过向转发规则字段中指定的端口上的 VIP 发送 curl 请求来测试流量：

      curl http://FORWARDING_RULE_VIP:PORT
      

      替换以下内容：

      • FORWARDING_RULE_VIP：转发规则的 VIP。
      • PORT：转发规则中字段的端口号。

gdcloud

使用 gdcloud CLI 创建一个全局 ELB，该 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 字段中指定的端口上的 VIP 发送 curl 请求来验证流量：

      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 条件。尝试通过向 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。