配置内部负载平衡器

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

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

准备工作

如需配置 ILB，您必须：

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

  • 拥有必要的身份和访问角色：

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

  • 了解托管工作负载的集群类型。共享集群和标准集群的 ILB 设置说明有所不同。

为共享集群创建内部负载均衡器

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

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

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

创建可用区级 ILB

使用 gdcloud CLI、KRM API 或 Kubernetes 集群中的 Kubernetes Service 创建可用区级 ILB：

gdcloud

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

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

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

  1. 创建 Backend 资源，为 ILB 定义端点：

    gdcloud compute backends create BACKEND_NAME \
  --labels=LABELS \
  --project=PROJECT_NAME \
  --zone=ZONE \
  --cluster-name=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 定义健康检查类型。例如，如需创建 TCP 健康检查，请按如下方式进行定义：

    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：从一次探测开始到下一次探测开始之间的时间量（以秒为单位）。如果省略或设置为 0，则默认为 5。不建议将超时时间设置为大于 checkInterval。
    • HEALTHY_THRESHOLD：端点被视为健康状况良好时必须通过的连续探测次数。如果省略或设置为 0，则默认为 5。
    • TIMEOUT：在声明失败之前等待的时间（以秒为单位）。如果省略或设置为 0，则默认为 5。不建议将超时时间设置为大于 checkInterval。
    • UNHEALTHY_THRESHOLD：要将端点视为运行状况不佳，必须失败的连续探测次数。如果省略或设置为 0，则默认为 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：可用区级 Management 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：在声明失败之前等待的时间（以秒为单位）。如果省略或设置为 0，则默认为 5。不建议将超时时间设置为大于 checkInterval。
    • CHECK_INTERVAL：从一次探测开始到下一次探测开始之间的时间量（以秒为单位）。如果省略或设置为 0，则默认为 5。不建议将超时时间设置为大于 checkInterval。
    • HEALTHY_THRESHOLD：端点被视为健康状况良好时必须通过的连续探测次数。如果省略或设置为 0，则默认为 2。
    • UNHEALTHY_THRESHOLD：要将端点视为运行状况不佳，必须失败的连续探测次数。如果省略或设置为 0，则默认为 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:
    name: CIDR_NAME
  ports:
  - port: PORT
    protocol: PROTOCOL
  backendServiceRef:
    name: BACKEND_SERVICE_NAME
EOF

    替换以下内容：

    • FORWARDING_RULE_INTERNAL_NAME：为 ForwardingRuleInternal 资源选择的名称。
    • CIDR_NAME：cidrRef 字段为可选字段。如果未指定，系统会自动从可用区级 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 服务

您可以通过在 Kubernetes 集群中创建类型为 LoadBalancer 的 Kubernetes Service 对象，在 GDC 中创建 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

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

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

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

  1. 创建 Backend 资源，为 ILB 定义端点：

    gdcloud compute backends create BACKEND_NAME \
  --labels=LABELS \
  --project=PROJECT_NAME \
  --cluster-name=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：从一次探测开始到下一次探测开始之间的时间量（以秒为单位）。如果省略或设置为 0，则默认为 5。不建议将超时时间设置为大于 checkInterval。
    • HEALTHY_THRESHOLD：在声明失败之前等待的时间。如果省略或设置为 0，则默认为 5。
    • TIMEOUT：在声明失败之前等待的时间（以秒为单位）。如果省略或设置为 0，则默认为 5。不建议将超时时间设置为大于 checkInterval。
    • UNHEALTHY_THRESHOLD：要将端点视为运行状况不佳，必须失败的连续探测次数。如果省略或设置为 0，则默认为 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.global.gdc.goog/v1
kind: Backend
metadata:
  namespace: PROJECT_NAME
  name: BACKEND_NAME
spec:
  clusterName: CLUSTER_NAME
  endpointsLabels:
    matchLabels:
      app: server
EOF

    替换以下内容：

    • MANAGEMENT_API_SERVER：全局 Management 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：在声明失败之前等待的时间（以秒为单位）。如果省略或设置为 0，则默认为 5。不建议将超时时间设置为大于 checkInterval。
    • CHECK_INTERVAL：从一次探测开始到下一次探测开始之间的时间量（以秒为单位）。如果省略或设置为 0，则默认为 5。不建议将超时时间设置为大于 checkInterval。
    • HEALTHY_THRESHOLD：端点被视为健康状况良好时必须通过的连续探测次数。如果省略或设置为 0，则默认为 2。
    • UNHEALTHY_THRESHOLD：要将端点视为运行状况不佳，必须失败的连续探测次数。如果省略或设置为 0，则默认为 2。

    由于这是全球 ILB，因此请在 Global 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:
    name: CIDR_NAME
  ports:
  - port: PORT
    protocol: PROTOCOL
  backendServiceRef:
    name: BACKEND_SERVICE_NAME
EOF

    替换以下内容：

    • FORWARDING_RULE_INTERNAL_NAME：为 ForwardingRuleInternal 资源选择的名称。
    • CIDR_NAME：与此转发规则位于同一命名空间中的 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。

为标准集群创建内部负载均衡器

您可以为标准集群创建可用区级 ILB；不支持全球级 ILB。 可用区级 ILB 的范围仅限于创建时指定的可用区。如需了解详情，请参阅全球和可用区级负载均衡器。

直接在 Kubernetes 集群中使用 Kubernetes Service 为标准集群创建可用区级 ILB。直接从 Kubernetes 集群使用 Kubernetes Service 时，您只能定位创建 Service 对象的集群中的工作负载。

为标准集群创建可用区级 ILB

您可以通过在 Kubernetes 集群中创建 LoadBalancer 类型的 Kubernetes Service 对象，在 GDC 中创建 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: ILB_SERVICE_NAMESPACE
spec:
  ports:
  - port: 1234
    protocol: TCP
    targetPort: 1234
  selector:
    k8s-app: my-app
  type: LoadBalancer

    替换以下内容：

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

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

  2. 在 Service 定义的 selector 字段中，指定将用作后端工作负载的 Pod。

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

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

  3. 将 Service 规范保存在 YAML 文件中。在以下命令中，将 ILB_FILE 替换为文件名。ILB 服务只能选择与 Service 定义位于同一集群中的工作负载。

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

    export KUBECONFIG=KUBECONFIG_PATH
kubectl apply -f ILB_FILE

    替换以下内容：

    • ILB_FILE：ILB 服务的 Service 定义文件的名称。
    • KUBECONFIG_PATH：标准集群的 kubeconfig 文件的路径。

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

    kubectl -n ILB_SERVICE_NAMESPACE get svc ILB_SERVICE_NAME

    替换以下内容：

    • ILB_SERVICE_NAMESPACE：包含后端工作负载的命名空间。
    • ILB_SERVICE_NAME：ILB 服务的名称。
    • KUBECONFIG_PATH：标准集群的 kubeconfig 文件的路径。

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

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

    现在，根据项目具有的项目网络政策，组织中的其他集群可以访问此 IP 地址。

选择虚拟机作为负载均衡器的后端

如需将虚拟机链接到负载均衡器，请执行以下操作：

  1. 确保虚拟机的标签与负载均衡器配置中使用的标签选择器匹配。

    例如，如果您的虚拟机没有适当的标签，您可以将相应可用区的后端对象中的指定标签添加到该虚拟机：

    kubectl --kubeconfig MANAGEMENT_API_SERVER label virtualmachine VM_NAME -n PROJECT_NAMELABEL

    替换以下内容：

    • LABEL：与负载均衡器配置中的 LabelSelector 匹配的标签，例如 app=server。
    • VM_NAME：要关联的虚拟机的名称。
    • PROJECT_NAME：您的项目的名称。

  2. 确保服务器正在监听 HealthCheck 对象中指定的同一端口。