Esta página se ha traducido con Cloud Translation API.

Configurar balanceadores de carga internos

Los balanceadores de carga internos (ILBs) exponen servicios dentro de la organización desde un pool de IPs internas asignado a la organización. Nunca se puede acceder a un servicio de ILB desde ningún punto final que no pertenezca a la organización.

De forma predeterminada, puedes acceder a los servicios de ILB del mismo proyecto desde cualquier clúster de la organización. La política de red de proyecto predeterminada no te permite acceder a ningún recurso del proyecto desde fuera de él, y esta restricción también se aplica a los servicios ILB. Si el administrador de la plataforma configura políticas de red de proyectos que permiten acceder a tu proyecto desde otros proyectos, el servicio ILB también será accesible desde esos otros proyectos de la misma organización.

Antes de empezar

Para configurar ILBs, debe tener lo siguiente:

Ser propietario del proyecto en el que vas a configurar el balanceador de carga. Para obtener más información, consulta Crear un proyecto.
Los roles de identidad y acceso necesarios:
- Pide al administrador de gestión de identidades y accesos de tu organización que te conceda el rol Administrador de balanceadores de carga (load-balancer-admin).
- En el caso de los ILBs globales, pide a tu administrador de gestión de identidades y accesos de la organización que te conceda el rol de administrador de balanceadores de carga globales (global-load-balancer-admin). Para obtener más información, consulta Descripciones de los roles predefinidos.

Crear un balanceador de carga interno

Puedes crear ILBs globales o zonales. El ámbito de los ILBs globales abarca todo un universo de GDC. El ámbito de los ILBs zonales se limita a la zona especificada en el momento de la creación. Para obtener más información, consulta Balanceadores de carga globales y zonales.

Crea balanceadores de carga internos mediante tres métodos diferentes en GDC:

Usa la CLI de gdcloud para crear ILBs globales o zonales.
Usa la API Networking Kubernetes Resource Model (KRM) para crear ILBs globales o zonales.
Usa el servicio de Kubernetes directamente en el clúster de Kubernetes. Este método solo está disponible para los ILBs zonales.

Puedes orientar las cargas de trabajo de pods o de máquinas virtuales mediante la API de KRM y la CLI de gdcloud. Solo puedes orientar las cargas de trabajo del clúster en el que se crea el objeto Service cuando usas el servicio de Kubernetes directamente desde el clúster de Kubernetes.

Crear un ILB zonal

Crea un ILB zonal mediante la CLI de gdcloud, la API de KRM o el servicio de Kubernetes en el clúster de Kubernetes:

gdcloud

Crea un ILB que tenga como destino cargas de trabajo de pods o de VMs mediante la CLI de gcloud.

Este balanceador de carga interno se dirige a todas las cargas de trabajo del proyecto que coincidan con la etiqueta definida en el objeto Backend.

Para crear un ILB con la CLI de gdcloud, sigue estos pasos:

Crea un recurso Backend para definir el endpoint del ILB:
```
gdcloud compute backends create BACKEND_NAME \
  --labels=LABELS \
  --project=PROJECT_NAME \
  --zone=ZONE \
  --cluster=CLUSTER_NAME
```
Haz los cambios siguientes:
- BACKEND_NAME: el nombre que elijas para el recurso de backend, como my-backend.
- LABELS: un selector que define qué endpoints entre pods y VMs se deben usar para este recurso de backend. Por ejemplo, app=web.
- PROJECT_NAME: el nombre de tu proyecto.
- ZONE: la zona que se va a usar en esta invocación. Para predefinir la marca de zona en todos los comandos que la requieran, ejecute gdcloud config set core/zone ZONE. La marca de zona solo está disponible en entornos multizona. Este campo es opcional.
- CLUSTER_NAME: el clúster al que se limita el ámbito de los selectores definidos. Si no se especifica este campo, se seleccionarán todos los endpoints con la etiqueta indicada. Este campo es opcional.
Sáltate este paso si este ILB es para cargas de trabajo de pods. Si vas a configurar un balanceador de carga interno para cargas de trabajo de VMs, define una comprobación de estado para el balanceador de carga interno:
```
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
```
Haz los cambios siguientes:
- HEALTH_CHECK_NAME: el nombre que elijas para el recurso de comprobación de estado, como my-health-check.
- CHECK_INTERVAL: la cantidad de tiempo en segundos que transcurre desde el inicio de una comprobación hasta el inicio de la siguiente. El valor predeterminado es 5. Este campo es opcional.
- HEALTHY_THRESHOLD: el tiempo que se debe esperar antes de declarar un error. El valor predeterminado es 5. Este campo es opcional.
- TIMEOUT: tiempo en segundos que se debe esperar antes de declarar un error. El valor predeterminado es 5. Este campo es opcional.
- UNHEALTHY_THRESHOLD: número de sondeos secuenciales que deben fallar para que el endpoint se considere en mal estado. El valor predeterminado es 2. Este campo es opcional.
- PORT: el puerto en el que se realiza la comprobación del estado. El valor predeterminado es 80. Este campo es opcional.
- ZONE: la zona en la que vas a crear este ILB.
Crea un recurso BackendService y añádele el recurso Backend que has creado anteriormente:
```
gdcloud compute backend-services create BACKEND_SERVICE_NAME \
  --project=PROJECT_NAME \
  --target-ports=TARGET_PORTS \
  --zone=ZONE \
  --health-check=HEALTH_CHECK_NAME
```
Haz los cambios siguientes:
- BACKEND_SERVICE_NAME: el nombre elegido para este servicio de backend.
- TARGET_PORTS: lista separada por comas de los puertos de destino que traduce este servicio de backend. Cada puerto de destino especifica el protocolo, el puerto de la regla de reenvío y el puerto de la instancia de backend. Puede especificar varios puertos de destino. Este campo debe tener el formato protocol:port:targetport, como TCP:80:8080. Este campo es opcional.
- HEALTH_CHECK_NAME: el nombre del recurso de comprobación de estado. Este campo es opcional. Incluye este campo solo si vas a configurar un ILB para cargas de trabajo de máquinas virtuales.

Añade el recurso BackendService al recurso Backend que has creado anteriormente:

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

Crea un recurso ForwardingRule interno que defina la IP virtual en la que está disponible el servicio:
```
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
```
Haz los cambios siguientes:
- BACKEND_SERVICE_NAME: el nombre de tu servicio de backend.
- FORWARDING_RULE_INTERNAL_NAME con el nombre que hayas elegido para la regla de reenvío.
- CIDR: este campo es opcional. Si no se especifica, se reserva automáticamente un CIDR IPv4/32 del pool de IPs zonales. Especifica el nombre de un recurso Subnet en el mismo espacio de nombres que esta regla de reenvío. Un recurso Subnet representa la información de solicitud y asignación de una subred zonal. Para obtener más información sobre los recursos Subnet, consulta Ejemplos de recursos personalizados.
- PROTOCOL_PORT: el protocolo y el puerto que se expondrán en la regla de reenvío. Este campo debe tener el formato ip-protocol=TCP:80. El puerto expuesto debe ser el mismo que el que expone la aplicación real dentro del contenedor.
Para validar el ILB configurado, confirma la condición Ready en cada uno de los objetos creados. Verifica el tráfico con una curl solicitud a la dirección IP virtual:
1. Para obtener la VIP asignada, describe la regla de reenvío:
```
gdcloud compute forwarding-rules describe FORWARDING_RULE_INTERNAL_NAME
```
2. Verifica el tráfico con una solicitud curl a la IP virtual en el puerto especificado en el campo PROTOCOL_PORT de la regla de reenvío:
```
curl http://FORWARDING_RULE_VIP:PORT
```
  Haz los cambios siguientes:
  - FORWARDING_RULE_VIP: el VIP de la regla de reenvío.
  - PORT: número de puerto del campo PROTOCOL_PORT de la regla de reenvío.

API

Crea un ILB que tenga como destino cargas de trabajo de pods o VMs mediante la API de KRM. Este balanceador de carga interno se dirige a todas las cargas de trabajo del proyecto que coincidan con la etiqueta definida en el objeto Backend.

Para crear un ILB zonal con la API KRM, sigue estos pasos:

Crea un recurso Backend para definir los endpoints del ILB. Crea recursos Backend para cada zona en la que se coloquen las cargas de trabajo:
```
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
```
Haz los cambios siguientes:
- MANAGEMENT_API_SERVER: la ruta de kubeconfig del servidor de la API Management zonal. Para obtener más información, consulta Cambiar a un contexto zonal.
- PROJECT_NAME: el nombre de tu proyecto.
- BACKEND_NAME: el nombre del recurso Backend.
- CLUSTER_NAME: este campo es opcional. Este campo especifica el clúster al que se limita el ámbito de los selectores definidos. Este campo no se aplica a las cargas de trabajo de máquinas virtuales. Si un recurso Backend no incluye el campo clusterName, las etiquetas especificadas se aplican a todas las cargas de trabajo del proyecto.
Puede usar el mismo recurso Backend para cada zona o crear recursos Backend con conjuntos de etiquetas diferentes para cada zona.
Sáltate este paso si este ILB es para cargas de trabajo de pods. Si vas a configurar un balanceador de carga interno para cargas de trabajo de VMs, define una comprobación de estado para el balanceador de carga interno:
```
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
```
Haz los cambios siguientes:
- HEALTH_CHECK_NAME: el nombre que elijas para el recurso de comprobación de estado, como my-health-check.
- PORT: el puerto en el que se realiza la comprobación del estado. El valor predeterminado es 80.
- TIMEOUT: tiempo en segundos que se debe esperar antes de declarar un error. El valor predeterminado es 5.
- CHECK_INTERVAL: la cantidad de tiempo en segundos que transcurre desde el inicio de una comprobación hasta el inicio de la siguiente. El valor predeterminado es 5.
- HEALTHY_THRESHOLD: número de sondeos secuenciales que deben superarse para que el endpoint se considere correcto. El valor predeterminado es 2.
- UNHEALTHY_THRESHOLD: número de sondeos secuenciales que deben fallar para que el endpoint se considere en mal estado. El valor predeterminado es 2.
Crea un objeto BackendService usando el recurso Backend que has creado anteriormente. Si vas a configurar un ILB para cargas de trabajo de máquinas virtuales, incluye el recurso 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
```
Haz los cambios siguientes:
- BACKEND_SERVICE_NAME: el nombre que elijas para tu recurso BackendService.
- HEALTH_CHECK_NAME: el nombre del recurso HealthCheck que has creado anteriormente. No incluyas este campo si vas a configurar un balanceador de carga interno para cargas de trabajo de pods.
Crea un recurso ForwardingRule interno que defina la IP virtual en la que está disponible el servicio.
```
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
```
Haz los cambios siguientes:
- FORWARDING_RULE_INTERNAL_NAME: el nombre que elijas para tu recurso ForwardingRuleInternal.
- CIDR: este campo es opcional. Si no se especifica, se reserva automáticamente un CIDR IPv4/32 del pool de IPs zonales. Especifica el nombre de un recurso Subnet en el mismo espacio de nombres que esta regla de reenvío. Un recurso Subnet representa la información de solicitud y asignación de una subred zonal. Para obtener más información sobre los recursos Subnet, consulta Ejemplos de recursos personalizados.
- PORT: use el campo ports para especificar una matriz de puertos de nivel 4 para los que se reenvían paquetes a los backends configurados con esta regla de reenvío. Se debe especificar al menos un puerto. Utilice el campo port para especificar un número de puerto. El puerto expuesto debe ser el mismo que el que expone la aplicación real dentro del contenedor.
- PROTOCOL: el protocolo que se va a usar en la regla de reenvío, como TCP. Una entrada del array ports debe tener el siguiente formato:
```
ports:
- port: 80
  protocol: TCP
```
Para validar el ILB configurado, confirma la condición Ready en cada uno de los objetos creados. Verifica el tráfico con una curl solicitud a la dirección IP virtual:
1. Para obtener la insignia VIP, usa kubectl get:
```
kubectl get forwardingruleinternal -n PROJECT_NAME
```
  La salida tiene este aspecto:
```
NAME           BACKENDSERVICE                               CIDR              READY
ilb-name       BACKEND_SERVICE_NAME        10.200.32.59/32   True
```
2. Verifica el tráfico con una solicitud curl a la IP virtual en el puerto especificado en el campo PORT de la regla de reenvío:
```
curl http://FORWARDING_RULE_VIP:PORT
```
  Sustituye FORWARDING_RULE_VIP por la IP virtual de la regla de reenvío.

Servicio de Kubernetes

Puedes crear ILBs en GDC creando un objeto de Kubernetes Service de tipo LoadBalancer en un clúster de Kubernetes. Este ILB solo se dirige a las cargas de trabajo del clúster en el que se crea el objeto Service.

Para crear un ILB con el objeto Service, siga estos pasos:

Crea un archivo YAML para la Service definición de tipo LoadBalancer. Debes diseñar el servicio de ILB como interno mediante la anotación networking.gke.io/load-balancer-type: internal.

Nota: El valor internal distingue entre mayúsculas y minúsculas, y debe estar en minúsculas.

El siguiente objeto Service es un ejemplo de un servicio de 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
```
Haz los cambios siguientes:
- ILB_SERVICE_NAME: el nombre del servicio de ILB.
- PROJECT_NAME: el espacio de nombres de tu proyecto que contiene las cargas de trabajo del backend.
El campo port configura el puerto frontend que expones en la dirección VIP. El campo targetPort configura el puerto de backend al que quieres reenviar el tráfico de las cargas de trabajo de backend. El balanceador de carga admite la traducción de direcciones de red (NAT). Los puertos de frontend y backend pueden ser diferentes.
En el campo selector de la definición de Service, especifica pods o máquinas virtuales como cargas de trabajo de backend.

El selector define qué cargas de trabajo se tomarán como cargas de trabajo de backend para este servicio, en función de las etiquetas que especifiques en las cargas de trabajo. El Service solo puede seleccionar cargas de trabajo de backend en el mismo proyecto y clúster en el que definas el Service.

Para obtener más información sobre la selección de servicios, consulta https://kubernetes.io/docs/concepts/services-networking/service/.
Guarda el archivo de definición Service en el mismo proyecto que las cargas de trabajo del backend. El servicio ILB solo puede seleccionar cargas de trabajo que estén en el mismo clúster que la definición de Service.
Aplica el archivo de definición Service al clúster:
```
kubectl apply -f ILB_FILE
```
Sustituye ILB_FILE por el nombre del archivo de definición Service del servicio ILB.

Cuando creas un servicio ILB, este obtiene una dirección IP. Para obtener la dirección IP del servicio ILB, consulta el estado del servicio:
```
kubectl -n PROJECT_NAME get svc ILB_SERVICE_NAME
```
Haz los cambios siguientes:
- PROJECT_NAME: el espacio de nombres de tu proyecto que contiene las cargas de trabajo del backend.
- ILB_SERVICE_NAME: el nombre del servicio de ILB.
Debes obtener un resultado similar al siguiente ejemplo:
```
NAME                    TYPE           CLUSTER-IP    EXTERNAL-IP     PORT(S)          AGE
ilb-service             LoadBalancer   10.0.0.1      10.0.0.1        1234:31930/TCP   22h
```
Los campos CLUSTER-IP y EXTERNAL-IP deben mostrar el mismo valor, que es la dirección IP del servicio ILB. Ahora se puede acceder a esta dirección IP desde otros clústeres de la organización, de acuerdo con las políticas de red del proyecto.

Si no obtienes ningún resultado, asegúrate de haber creado el servicio ILB correctamente.

GDC admite nombres del sistema de nombres de dominio (DNS) para los servicios. Sin embargo, esos nombres solo funcionan en el mismo clúster para los servicios de ILB. Desde otros clústeres, debes usar la dirección IP para acceder al servicio ILB.

Importante: Si los valores de CLUSTER-IP y EXTERNAL-IP no son iguales, significa que has configurado el servicio como un servicio de balanceador de carga externo (ELB). Asegúrate de que la anotación networking.gke.io/load-balancer-type: internal sea correcta en la definición de Service. Las claves y los valores de las anotaciones distinguen entre mayúsculas y minúsculas.

Crear un ILB global

Crea un ILB global mediante la CLI de gdcloud o la API de KRM.