配置内部负载平衡器

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

默认情况下，您可以从组织中的任何集群访问同一项目中的 ILB 服务。默认的项目网络政策不允许您从项目外部访问任何项目资源，此限制也适用于 ILB 服务。如果平台管理员 (PA) 配置的项目网络政策允许从其他项目访问您的项目，则同一组织中的其他项目也可以访问 ILB 服务。

准备工作

如需配置 ILB，您必须具备以下条件：

  • 拥有您要配置负载均衡器的项目。如需了解详情，请参阅创建项目。

  • 必要的身份和访问权限角色：

    • 请让您的组织 IAM 管理员向您授予 Load Balancer Admin (load-balancer-admin) 角色。
    • 对于全球 ILB，请让您的组织 IAM 管理员为您授予 Global Load Balancer Admin (global-load-balancer-admin) 角色。如需了解详情，请参阅预定义角色说明。

创建内部负载均衡器

您可以创建全球级或可用区级 ILB。全球 ILB 的范围涵盖整个 GDC 宇宙。可用区级 ILB 的范围仅限于创建时指定的可用区。如需了解详情，请参阅全球和可用区级负载平衡器。

在 GDC 中使用三种不同的方法创建 ILB：

您可以使用 KRM API 和 gdcloud CLI 定位 Pod 或虚拟机工作负载。直接从 Kubernetes 集群使用 Kubernetes 服务时，您只能以创建 Service 对象的集群中的工作负载为目标。

创建可用区级 ILB

使用 gcloud CLI、KRM API 或 Kubernetes 集群中的 Kubernetes 服务创建区域级 ILB：

gdcloud

使用 gcloud CLI 创建以 Pod 或虚拟机工作负载为目标的 ILB。

此 ILB 会以项目中与 Backend 对象中定义的标签匹配的所有工作负载为目标。

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

  1. 创建 Backend 资源以定义 ILB 的端点：

    gdcloud compute backends create BACKEND_NAME \
  --labels=LABELS \
  --project=PROJECT_NAME \
  --zone=ZONE \
  --cluster=CLUSTER_NAME

    替换以下内容：

    • BACKEND_NAME：您为后端资源选择的名称，例如 my-backend。
    • LABELS：一种选择器，用于定义要为此后端资源使用哪些 Pod 与虚拟机之间的端点。例如 app=web。
    • PROJECT_NAME：您的项目的名称。
    • ZONE：要用于此调用的可用区。如需为所有需要可用区标志的命令预设该标志，请运行：gdcloud config set core/zone ZONE。可用区标志仅在多可用区环境中可用。此字段是可选字段。
    • CLUSTER_NAME：定义的选择器的范围所限定到的集群。如果未指定此字段，则会选择具有指定标签的所有端点。此字段是可选字段。

  2. 如果此 ILB 适用于 Pod 工作负载，请跳过此步骤。如果您要为虚拟机工作负载配置 ILB，请为 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 \
  --zone=ZONE

    替换以下内容：

    • HEALTH_CHECK_NAME：您为健康检查资源选择的名称，例如 my-health-check。
    • CHECK_INTERVAL：从一次探测开始到下一次探测开始之间的时间量（以秒为单位）。默认值为 5。此字段是可选字段。
    • HEALTHY_THRESHOLD：在声明失败之前等待的时间。默认值为 5。此字段是可选字段。
    • TIMEOUT：在声明失败之前等待的时间量（以秒为单位）。默认值为 5。此字段是可选字段。
    • UNHEALTHY_THRESHOLD：要将端点视为运行状况不佳所必须失败的连续探测次数。默认值为 2。此字段是可选字段。
    • PORT：执行健康检查的端口。默认值为 80。此字段是可选字段。
    • ZONE：您要在其中创建此 ILB 的可用区。

  3. 创建 BackendService 资源，并将之前创建的 Backend 资源添加到其中：

    gdcloud compute backend-services create BACKEND_SERVICE_NAME \
  --project=PROJECT_NAME \
  --target-ports=TARGET_PORTS \
  --zone=ZONE \
  --health-check=HEALTH_CHECK_NAME

    替换以下内容：

    • BACKEND_SERVICE_NAME：相应后端服务的所选名称。
    • TARGET_PORTS：此后端服务转换的目标端口的英文逗号分隔列表，其中每个目标端口都指定了协议、转发规则中的端口和后端实例中的端口。您可以指定多个目标端口。此字段必须采用 protocol:port:targetport 格式，例如 TCP:80:8080。此字段是可选字段。
    • HEALTH_CHECK_NAME：健康检查资源的名称。此字段是可选字段。仅当您为虚拟机工作负载配置 ILB 时，才添加此字段。

  4. 将 BackendService 资源添加到之前创建的 Backend 资源：

    gdcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
  --backend=BACKEND_NAME \
  --project=PROJECT_NAME \
  --zone=ZONE

  5. 创建内部 ForwardingRule 资源，用于定义服务可用的 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 \
  --zone=ZONE \
  --project=PROJECT_NAME

    替换以下内容：

    • BACKEND_SERVICE_NAME：后端服务的名称。
    • 将 FORWARDING_RULE_INTERNAL_NAME 替换为您为转发规则选择的名称。
    • CIDR：此字段是可选字段。如果未指定，系统会自动从可用区 IP 池中预留一个 IPv4/32 CIDR。指定与相应转发规则位于同一命名空间中的 Subnet 资源的名称。Subnet 资源表示区域子网的请求和分配信息。如需详细了解 Subnet 资源，请参阅自定义资源示例。
    • PROTOCOL_PORT：要在转发规则中公开的协议和端口。此字段必须采用 ip-protocol=TCP:80 格式。公开的端口必须与实际应用在容器内公开的端口相同。

  6. 如需验证配置的 ILB，请确认每个已创建对象上的 Ready 条件。通过向 VIP 发送 curl 请求来验证流量：

    1. 如需获取分配的 VIP，请描述转发规则：

      gdcloud compute forwarding-rules describe FORWARDING_RULE_INTERNAL_NAME

    2. 通过向转发规则中 PROTOCOL_PORT 字段指定的端口上的 VIP 发送 curl 请求来验证流量：

      curl http://FORWARDING_RULE_VIP:PORT

      替换以下内容：

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

API

使用 KRM API 创建以 Pod 或虚拟机工作负载为目标的 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
  name: BACKEND_NAME
spec:
  clusterName: CLUSTER_NAME
  endpointsLabels:
    matchLabels:
      app: server
EOF

    替换以下内容：

    • MANAGEMENT_API_SERVER：区域管理 API 服务器的 kubeconfig 路径。如需了解详情，请参阅切换到可用区级上下文。
    • PROJECT_NAME：您的项目的名称。
    • BACKEND_NAME：Backend 资源的名称。
    • CLUSTER_NAME：此字段为可选字段。此字段用于指定所定义选择器的范围所限定到的集群。此字段不适用于虚拟机工作负载。如果 Backend 资源未包含 clusterName 字段，则指定的标签会应用于项目中的所有工作负载。

    您可以为每个可用区使用相同的 Backend 资源，也可以为每个可用区创建具有不同标签集的 Backend 资源。

  2. 如果此 ILB 适用于 Pod 工作负载，请跳过此步骤。如果您要为虚拟机工作负载配置 ILB，请为 ILB 定义健康检查：

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

  3. 使用之前创建的 Backend 资源创建一个 BackendService 对象。如果您要为虚拟机工作负载配置 ILB，请添加 HealthCheck 资源。

    kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.gdc.goog/v1
kind: BackendService
metadata:
  namespace: PROJECT_NAME
  name: BACKEND_SERVICE_NAME
spec:
  backendRefs:
  - name: BACKEND_NAME
  healthCheckName: HEALTH_CHECK_NAME
EOF

    替换以下内容：

    • BACKEND_SERVICE_NAME：为 BackendService 资源选择的名称。
    • HEALTH_CHECK_NAME：您之前创建的 HealthCheck 资源的名称。如果您要为 Pod 工作负载配置 ILB，请勿添加此字段。

  4. 创建内部 ForwardingRule 资源，用于定义服务可用的 VIP。

    kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.gdc.goog/v1
kind: ForwardingRuleInternal
metadata:
  namespace: PROJECT_NAME
  Name: FORWARDING_RULE_INTERNAL_NAME
spec:
  cidrRef: CIDR
  ports:
  - port: PORT
    Protocol: PROTOCOL
  backendServiceRef:
    name: BACKEND_SERVICE_NAME
EOF

    替换以下内容：

    • FORWARDING_RULE_INTERNAL_NAME：为 ForwardingRuleInternal 资源选择的名称。
    • CIDR：此字段是可选字段。如果未指定，系统会自动从可用区 IP 池中预留一个 IPv4/32 CIDR。指定与相应转发规则位于同一命名空间中的 Subnet 资源的名称。Subnet 资源表示区域子网的请求和分配信息。如需详细了解 Subnet 资源，请参阅自定义资源示例。
    • PORT：使用 ports 字段指定一个 L4 端口数组，数据包将转发到使用此转发规则配置的后端。必须至少指定一个端口。使用 port 字段指定端口号。公开的端口必须与实际应用在容器内公开的端口相同。

    • PROTOCOL：用于转发规则的协议，例如 TCP。ports 数组中的条目必须如下所示：

      ports:
- port: 80
  protocol: TCP

  5. 如需验证配置的 ILB，请确认每个已创建对象上的 Ready 条件。通过向 VIP 发送 curl 请求来验证流量：

    1. 如需获取 VIP，请使用 kubectl get：

      kubectl get forwardingruleinternal -n PROJECT_NAME

      输出如下所示：

      NAME           BACKENDSERVICE                               CIDR              READY
ilb-name       BACKEND_SERVICE_NAME        10.200.32.59/32   True

    2. 通过向转发规则中 PORT 字段指定的端口上的 VIP 发送 curl 请求来验证流量：

      curl http://FORWARDING_RULE_VIP:PORT

      将 FORWARDING_RULE_VIP 替换为转发规则的 VIP。

Kubernetes Service

您可以在 GDC 中通过在 Kubernetes 集群中创建类型为 LoadBalancer 的 Kubernetes Service 对象来创建 ILB。此 ILB 仅以创建 Service 对象的集群中的工作负载为目标。

如需使用 Service 对象创建 ILB，请按以下步骤操作：

  1. 为 LoadBalancer 类型的 Service 定义创建一个 YAML 文件。您必须使用 networking.gke.io/load-balancer-type: internal 注解将 ILB 服务设计为内部服务。

    以下 Service 对象是 ILB 服务的示例：

    apiVersion: v1
kind: Service
metadata:
  annotations:
    networking.gke.io/load-balancer-type: internal
  name: ILB_SERVICE_NAME
  namespace: PROJECT_NAME
spec:
  ports:
  - port: 1234
    protocol: TCP
    targetPort: 1234
  selector:
    k8s-app: my-app
  type: LoadBalancer

    替换以下内容：

    • ILB_SERVICE_NAME：ILB 服务的名称。
    • PROJECT_NAME：包含后端工作负载的项目的命名空间。

    port 字段用于配置您在 VIP 地址上公开的前端端口。targetPort 字段用于配置您希望将后端工作负载上的流量转发到的后端端口。负载均衡器支持网络地址转换 (NAT)。前端端口和后端端口可以不同。

  2. 在 Service 定义的 selector 字段中，将 pod 或虚拟机指定为后端工作负载。

    选择器用于根据您指定的标签与工作负载上的标签的匹配情况，定义要将哪些工作负载作为此服务的后端工作负载。Service 只能选择您定义 Service 的同一项目和同一集群中的后端工作负载。

    如需详细了解服务选择，请参阅 https://kubernetes.io/docs/concepts/services-networking/service/。

  3. 将 Service 定义文件保存在与后端工作负载相同的项目中。ILB 服务只能选择与 Service 定义位于同一集群中的工作负载。

  4. 将 Service 定义文件应用于集群：

    kubectl apply -f ILB_FILE

    将 ILB_FILE 替换为 ILB 服务的 Service 定义文件的名称。

    创建 ILB 服务时，该服务会获得一个 IP 地址。您可以通过查看服务状态来获取 ILB 服务的 IP 地址：

    kubectl -n PROJECT_NAME get svc ILB_SERVICE_NAME

    替换以下内容：

    • PROJECT_NAME：包含后端工作负载的项目的命名空间。
    • ILB_SERVICE_NAME：ILB 服务的名称。

    您必须获得类似于以下示例的输出：

    NAME                    TYPE           CLUSTER-IP    EXTERNAL-IP     PORT(S)          AGE
ilb-service             LoadBalancer   10.0.0.1      10.0.0.1        1234:31930/TCP   22h

    CLUSTER-IP 和 EXTERNAL-IP 字段必须显示相同的值，即 ILB 服务的 IP 地址。现在，组织中的其他集群可以根据项目所具有的项目网络政策访问此 IP 地址。

    如果您未获得输出，请确保您已成功创建 ILB 服务。

    GDC 支持服务的域名系统 (DNS) 名称。不过，这些名称仅适用于同一集群中的 ILB 服务。从其他集群中，您必须使用 IP 地址来访问 ILB 服务。

创建全局 ILB

使用 gdcloud CLI 或 KRM API 创建全球 ILB。

gdcloud

使用 gcloud CLI 创建以 Pod 或虚拟机工作负载为目标的 ILB。

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

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

  1. 创建 Backend 资源以定义 ILB 的端点：

    gdcloud compute backends create BACKEND_NAME \
  --labels=LABELS \
  --project=PROJECT_NAME \
  --cluster=CLUSTER_NAME \
  --zone=ZONE

    替换以下内容：

    • BACKEND_NAME：您为后端资源选择的名称，例如 my-backend。
    • LABELS：一种选择器，用于定义要为此后端资源使用哪些 Pod 与虚拟机之间的端点。例如 app=web。
    • PROJECT_NAME：您的项目的名称。
    • CLUSTER_NAME：定义的选择器的范围所限定到的集群。如果未指定此字段，则会选择具有指定标签的所有端点。此字段是可选字段。
    • ZONE：要用于此调用的可用区。如需为所有需要可用区标志的命令预设该标志，请运行：gdcloud config set core/zone ZONE。只有在多区域环境中，区域标志才可用。此字段是可选字段。

  2. 如果此 ILB 适用于 Pod 工作负载，请跳过此步骤。如果您要为虚拟机工作负载配置 ILB，请为 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 资源，并将之前创建的 Backend 资源添加到其中：

    gdcloud compute backend-services create BACKEND_SERVICE_NAME \
  --project=PROJECT_NAME \
  --target-ports=TARGET_PORTS \
  --health-check=HEALTH_CHECK_NAME \
  --global

    替换以下内容：

    • BACKEND_SERVICE_NAME：相应后端服务的所选名称。
    • TARGET_PORTS：此后端服务转换的目标端口的英文逗号分隔列表，其中每个目标端口都指定了协议、转发规则中的端口和后端实例中的端口。您可以指定多个目标端口。此字段必须采用 protocol:port:targetport 格式，例如 TCP:80:8080。此字段是可选字段。
    • HEALTH_CHECK_NAME：健康检查资源的名称。此字段是可选字段。仅当您为虚拟机工作负载配置 ILB 时，才添加此字段。

  4. 将 BackendService 资源添加到之前创建的 Backend 资源：

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

  5. 创建内部 ForwardingRule 资源，用于定义服务可用的 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_NAME \
  --global

    替换以下内容：

    • FORWARDING_RULE_INTERNAL_NAME：您为转发规则选择的名称。
    • CIDR：与此转发规则位于同一命名空间中的 Subnet 资源的名称。Subnet 资源表示全球子网的请求和分配信息。如需详细了解 Subnet 资源，请参阅自定义资源示例。如果未指定，系统会自动从全局 IP 池中预留一个 IPv4/32 CIDR。此字段是可选字段。
    • PROTOCOL_PORT：要在转发规则中公开的协议和端口。此字段必须采用 ip-protocol=TCP:80 格式。 公开的端口必须与实际应用在容器内公开的端口相同。

  6. 如需验证配置的 ILB，请确认每个已创建对象上的 Ready 条件。通过向 VIP 发送 curl 请求来验证流量：

    1. 如需获取分配的 VIP，请描述转发规则：

      gdcloud compute forwarding-rules describe FORWARDING_RULE_INTERNAL_NAME --global

    2. 通过向转发规则中 PROTOCOL_PORT 字段指定的端口上的 VIP 发送 curl 请求来验证流量：

      curl http://FORWARDING_RULE_VIP:PORT

      替换以下内容：

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

API

使用 KRM API 创建以 Pod 或虚拟机工作负载为目标对象的 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
  name: BACKEND_NAME
spec:
  clusterName: CLUSTER_NAME
  endpointsLabels:
    matchLabels:
      app: server
EOF

    替换以下内容：

    • MANAGEMENT_API_SERVER：全局管理 API 服务器的 kubeconfig 路径。如需了解详情，请参阅切换到全局上下文。
    • PROJECT_NAME：您的项目的名称。
    • BACKEND_NAME：Backend 资源的名称。
    • CLUSTER_NAME：此字段为可选字段。此字段用于指定所定义选择器的范围所限定到的集群。此字段不适用于虚拟机工作负载。如果 Backend 资源未包含 clusterName 字段，则指定的标签会应用于项目中的所有工作负载。

    您可以为每个可用区使用相同的 Backend 资源，也可以为每个可用区创建具有不同标签集的 Backend 资源。

  2. 如果此 ILB 适用于 Pod 工作负载，请跳过此步骤。如果您要为虚拟机工作负载配置 ILB，请为 ILB 定义健康检查：

    apiVersion: networking.global.gdc.goog/v1
kind: HealthCheck
metadata:
  namespace: PROJECT_NAME
  name: HEALTH_CHECK_NAME
spec:
  tcpHealthCheck:
    port: PORT
  timeoutSec: TIMEOUT
  checkIntervalSec: CHECK_INTERVAL
  healthyThreshold: HEALTHY_THRESHOLD
  unhealthyThreshold: UNHEALTHY_THRESHOLD

    替换以下内容：

    • HEALTH_CHECK_NAME：您为健康检查资源选择的名称，例如 my-health-check。
    • PORT：执行健康检查的端口。默认值为 80。
    • TIMEOUT：在声明失败之前等待的时间量（以秒为单位）。默认值为 5。
    • CHECK_INTERVAL：从一次探测开始到下一次探测开始之间的时间量（以秒为单位）。默认值为 5。
    • HEALTHY_THRESHOLD：要将端点视为运行状况良好必须通过的连续探测次数。默认值为 2。
    • UNHEALTHY_THRESHOLD：要将端点视为运行状况不佳所必须失败的连续探测次数。默认值为 2。

    由于这是全球 ILB，因此请在全局 API 中创建健康检查。

  3. 使用之前创建的 Backend 资源创建一个 BackendService 对象。如果您要为虚拟机工作负载配置 ILB，请添加 HealthCheck 资源。

    kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: BackendService
metadata:
  namespace: PROJECT_NAME
  name: BACKEND_SERVICE_NAME
spec:
  backendRefs:
  - name: BACKEND_NAME
    zone: ZONE
  healthCheckName: HEALTH_CHECK_NAME
  targetPorts:
  - port: PORT
    protocol: PROTOCOL
    targetPort: TARGET_PORT
EOF

    替换以下内容：

    • BACKEND_SERVICE_NAME：为 BackendService 资源选择的名称。
    • HEALTH_CHECK_NAME：您之前创建的 HealthCheck 资源的名称。如果您要为 Pod 工作负载配置 ILB，请勿添加此字段。

    • ZONE：创建 Backend 资源的可用区。您可以在 backendRefs 字段中指定多个后端。例如：

      - name: my-be
  zone: Zone-A
- name: my-be
  zone: Zone-B

    • targetPorts 字段为可选字段。此资源列出了 BackendService 资源转换的端口。如果您使用的是此对象，请为以下各项提供值：

      • PORT：服务公开的端口。
      • PROTOCOL：流量必须匹配的第 4 层协议。仅支持 TCP 和 UDP。

      • TARGET_PORT：PORT 值转换到的端口，例如 8080。TARGET_PORT 的值在给定对象中不能重复。targetPorts 的示例可能如下所示：

        targetPorts:
- port: 80
  protocol: TCP
  targetPort: 8080

  4. 创建内部 ForwardingRule 资源，用于定义服务可用的 VIP。

    kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: ForwardingRuleInternal
metadata:
  namespace: PROJECT_NAME
  Name: FORWARDING_RULE_INTERNAL_NAME
spec:
  cidrRef: CIDR
  ports:
  - port: PORT
    Protocol: PROTOCOL
  backendServiceRef:
    name: BACKEND_SERVICE_NAME
EOF

    替换以下内容：

    • FORWARDING_RULE_INTERNAL_NAME：为 ForwardingRuleInternal 资源选择的名称。
    • CIDR：与此转发规则位于同一命名空间中的 Subnet 资源的名称。Subnet 资源表示全球子网的请求和分配信息。如需详细了解 Subnet 资源，请参阅自定义资源示例。如果未指定，系统会自动从全局 IP 池中预留一个 IPv4/32 CIDR。此字段是可选字段。
    • PORT：使用 ports 字段指定一个 L4 端口数组，数据包将转发到使用此转发规则配置的后端。必须至少指定一个端口。使用 port 字段指定端口号。公开的端口必须与实际应用在容器内公开的端口相同。

    • PROTOCOL：用于转发规则的协议，例如 TCP。ports 数组中的条目必须如下所示：

      ports:
- port: 80
  protocol: TCP

  5. 如需验证配置的 ILB，请确认每个已创建对象上的 Ready 条件。通过向 VIP 发送 curl 请求来验证流量：

    1. 如需获取 VIP，请使用 kubectl get：

      kubectl get forwardingruleinternal -n PROJECT_NAME

      输出如下所示：

      NAME           BACKENDSERVICE                               CIDR              READY
ilb-name       BACKEND_SERVICE_NAME        10.200.32.59/32   True

    2. 通过向转发规则的 PORT 字段中指定的端口上的 VIP 发出 curl 请求来测试流量：

      curl http://FORWARDING_RULE_VIP:PORT

      将 FORWARDING_RULE_VIP 替换为转发规则的 VIP。