此页面由 Cloud Translation API 翻译。

配置内部负载平衡器

内部负载平衡器 (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：

使用 gdcloud CLI 创建全球或可用区级 ILB。
使用 Networking Kubernetes 资源模型 (KRM) API 创建全球或区域级 ILB。
直接在 Kubernetes 集群中使用 Kubernetes 服务。此方法仅适用于可用区级 ILB。

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

创建可用区级 ILB

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

gdcloud

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

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

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

创建 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：将所定义选择器的范围限制到的集群。如果未指定此字段，则会选择具有指定标签的所有端点。此字段是可选字段。
如果此 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 的可用区。
创建 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 时，才添加此字段。

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

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

创建内部 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 格式。公开的端口必须与实际应用在容器内公开的端口相同。
如需验证配置的 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，请按以下步骤操作：

创建 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 资源。
如果此 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。
使用之前创建的 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，请勿添加此字段。
创建内部 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
```
如需验证配置的 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，请按以下步骤操作：

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

注意：值 internal 区分大小写，且必须采用小写字母。

以下 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)。前端端口和后端端口可以不同。
在 Service 定义的 selector 字段中，将 pod 或虚拟机指定为后端工作负载。

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

如需详细了解服务选择，请参阅 https://kubernetes.io/docs/concepts/services-networking/service/。
将 Service 定义文件保存在与后端工作负载相同的项目中。ILB 服务只能选择与 Service 定义位于同一集群中的工作负载。
将 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 服务。

重要提示：如果 CLUSTER-IP 和 EXTERNAL-IP 值不相同，则表示您已将服务配置为外部负载均衡器 (ELB) 服务。确保 Service 定义中的 networking.gke.io/load-balancer-type: internal 注解正确无误。注释键和值区分大小写。

创建全局 ILB

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