Se usó la API de Cloud Translation para traducir esta página.

Crea un balanceador de cargas interno

Autopilot estándar

En esta página, se explica cómo crear un balanceador de cargas de red de transferencia interno o un balanceador de cargas interno en Google Kubernetes Engine (GKE). Para crear un balanceador de cargas de red de transferencia externo, consulta Crea un Service de tipo LoadBalancer.

Antes de leer este documento, asegúrate de estar familiarizado con los siguientes conceptos:

Usa un balanceador de cargas de red de transferencia interno

Los balanceadores de cargas de red de transferencia internos permiten que los clientes ubicados en la red de VPC de tu clúster y los clientes en redes conectadas a la red de VPC de tu clúster puedan acceder a los Services del clúster. Los clientes en la red de VPC de tu clúster pueden ser nodos o Pods de tu clúster, o bien pueden ser VMs fuera de tu clúster. Para obtener más información sobre la conectividad de los clientes en redes conectadas, consulta Balanceadores de cargas de red de transferencia internos y redes conectadas.

Usa la subdivisión de GKE

La subdivisión de GKE mejora la escalabilidad de los objetos Service LoadBalancer internos porque usa grupos de extremos de red (NEG) de GCE_VM_IP como backends en lugar de grupos de instancias. Cuando la subdivisión de GKE está habilitada, GKE crea un NEG por zona de procesamiento por cada objeto Service LoadBalancer interno.

El externalTrafficPolicy del objeto Service controla la membresía del nodo en los backends de NEG GCE_VM_IP. Para obtener más información, consulta Membresía de nodos en backends de NEG de GCE_VM_IP.

Usa la afinidad zonal

Cuando habilitas la afinidad zonal en un balanceador de cargas de red de transferencia interno, GKE enruta el tráfico que se origina en una zona a los nodos y Pods dentro de esa misma zona. Si no hay Pods en buen estado en la zona, GKE enruta el tráfico a otra zona. Esta implementación se optimiza para la latencia y el costo.

Para habilitar la afinidad zonal en un clúster de GKE, debes tener habilitada la subdivisión de GKE.

Requisitos y limitaciones

A continuación, se indican los requisitos y las limitaciones de los balanceadores de cargas internos.

Requisitos

La subdivisión de GKE tiene los siguientes requisitos y limitaciones:

Puedes habilitar la subdivisión en clústeres estándar nuevos y existentes en la versión de GKE 1.18.19-gke.1400 y versiones posteriores. La subdivisión de GKE no se puede inhabilitar una vez habilitada.
La subdivisión de GKE está inhabilitada de forma predeterminada en los clústeres de Autopilot. Sin embargo, puedes habilitarlo después de crear el clúster.
La subdivisión de GKE requiere que el complemento HttpLoadBalancing esté habilitado. Este complemento está habilitado de forma predeterminada. En los clústeres de Autopilot, no puedes inhabilitar este complemento obligatorio.
Se aplican las cuotas para los grupos de extremos de red. Google Cloud crea un NEG GCE_VM_IP por Service de LoadBalancer interno por zona.
Se aplican cuotas para las reglas de reenvío, los servicios de backend y las verificaciones de estado. Para obtener más información, consulta Cuotas y límites.
La subdivisión de GKE no se puede usar con la anotación para compartir un servicio de backend entre varios balanceadores de cargas, alpha.cloud.google.com/load-balancer-backend-share.
Debes tener la versión 345.0.0 de Google Cloud CLI o una posterior.

La afinidad zonal tiene los siguientes requisitos:

Puedes habilitar la afinidad zonal en clústeres nuevos y existentes en la versión de GKE 1.33.3-gke.1392000 y versiones posteriores.
Debes tener habilitada la subdivisión de GKE.
Debes asegurarte de que el complemento HttpLoadBalancing esté habilitado para tu clúster. Este complemento está habilitado de forma predeterminada y permite que el clúster administre los balanceadores de cargas que usan servicios de backend.
Debes incluir spec.trafficDistribution: PreferClose en el manifiesto del Service LoadBalancer.

El manifiesto del Service LoadBalancer puede usar externalTrafficPolicy: Local o externalTrafficPolicy: Cluster.

Limitaciones

Balanceadores de cargas de red de transferencia internos

Para los clústeres que ejecutan Kubernetes versión 1.7.4 o superior, pueden usar balanceadores de cargas internos con subredes modo personalizado además de las subredes en modo automático
Los clústeres que ejecutan Kubernetes versión 1.7.X y posteriores admiten el uso de una dirección IP reservada para el balanceador de cargas de red de transferencia interno si creas la dirección IP reservada con la marca --purpose establecida en SHARED_LOADBALANCER_VIP. Para obtener instrucciones paso a paso, consulta Habilita IP compartida. GKE solo conserva la dirección IP de un balanceador de cargas de red de transferencia interno si el Service hace referencia a una dirección IP interna con ese propósito. De lo contrario, GKE podría cambiar la dirección IP del balanceador de cargas (spec.loadBalancerIP) si el servicio se actualiza (por ejemplo, si se cambian los puertos).
Incluso si la dirección IP del balanceador de cargas cambia (consulta el punto anterior), el spec.clusterIP permanece constante.
Los balanceadores de cargas UDP internos no son compatibles con sessionAffinity: ClientIP.

Antes de comenzar

Antes de comenzar, asegúrate de haber realizado las siguientes tareas:

Habilita la API de Google Kubernetes Engine.

Habilitar la API de Google Kubernetes Engine

Si deseas usar Google Cloud CLI para esta tarea, instala y, luego, inicializa gcloud CLI. Si ya instalaste gcloud CLI, ejecuta el comando gcloud components update para obtener la versión más reciente. Es posible que las versiones anteriores de gcloud CLI no admitan la ejecución de los comandos que se describen en este documento.
Nota: Para las instalaciones de gcloud CLI existentes, asegúrate de configurar la propiedad compute/region. Si usas principalmente clústeres zonales, configura compute/zone en su lugar. Cuando configuras una ubicación predeterminada, puedes evitar errores en gcloud CLI como el siguiente: One of [--zone, --region] must be supplied: Please specify location. Es posible que debas especificar la ubicación en ciertos comandos si la ubicación de tu clúster difiere de la predeterminada que estableciste.

Asegúrate de tener un clúster de Autopilot o Standard existente. Para crear un clúster nuevo, consulta Crea un clúster de Autopilot.

Habilita la subdivisión de GKE en un clúster

Puedes habilitar la subdivisión de GKE para un clúster existente con gcloud CLI o la Google Cloud consola. No puedes inhabilitar la subdivisión de GKE después de habilitarla.

Console

En la consola de Google Cloud , ve a la página Google Kubernetes Engine.

Ir a Google Kubernetes Engine
En la lista de clústeres, haz clic en el nombre del clúster que deseas modificar.
En Herramientas de redes, junto al campo Subdivisión de balanceadores de cargas internos L4, haz clic en Habilitar la subdivisión de balanceadores de cargas internos L4.
Selecciona la casilla de verificación Habilitar subconjunto para balanceadores de cargas internos L4.
Haz clic en Save Changes.

gcloud

gcloud container clusters update CLUSTER_NAME \
    --enable-l4-ilb-subsetting

Reemplaza lo siguiente:

CLUSTER_NAME: el nombre del clúster

La habilitación de la subdivisión de GKE no interrumpe los Services LoadBalancer internos existentes. Si deseas migrar los objetos Service LoadBalancer internos existentes para usar servicios de backend con NEG GCE_VM_IP como backends, debes implementar un manifiesto de Service de reemplazo. Para obtener más detalles, consulta Agrupación de nodos en la documentación de conceptos del objeto Service LoadBalancer.

Implementa una carga de trabajo

En el siguiente manifiesto, se describe una implementación que ejecuta una imagen de contenedor de aplicación web de muestra.

Guarda el manifiesto como ilb-deployment.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ilb-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: ilb-deployment
  template:
    metadata:
      labels:
        app: ilb-deployment
    spec:
      containers:
      - name: hello-app
        image: us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0

Aplica el manifiesto al clúster:
```
kubectl apply -f ilb-deployment.yaml
```

Crea un objeto Service LoadBalancer interno

(Opcional) Inhabilita la creación automática de reglas de firewall de VPC:

Si bien GKE crea automáticamente reglas de firewall de VPC para permitir el tráfico a tu balanceador de cargas interno, tienes la opción de inhabilitar la creación automática de reglas de firewall de VPC y administrar las reglas de firewall por tu cuenta. Solo puedes inhabilitar las reglas de firewall de VPC si habilitaste la subdivisión de GKE para tu objeto Service LoadBalancer interno. Sin embargo, administrar las reglas de firewall de VPC es opcional, y puedes confiar en las reglas automáticas.

Antes de inhabilitar la creación automática de reglas de firewall de VPC, asegúrate de definir reglas de permiso que permitan que el tráfico llegue a tu balanceador de cargas y a los Pods de la aplicación.

Para obtener más información sobre cómo administrar las reglas de firewall de VPC, consulta Administra la creación automática de reglas de firewall y, para saber cómo inhabilitar la creación automática de reglas de firewall, consulta Reglas de firewall administradas por el usuario para los servicios de LoadBalancer de GKE.
En el siguiente ejemplo, se crea un objeto Service LoadBalancer interno mediante el puerto TCP 80. GKE implementa un balanceador de cargas de red de transferencia interno cuya regla de reenvío usa el puerto 80, pero luego reenvía el tráfico a los Pods de backend en el puerto 8080:
1. Guarda el manifiesto como ilb-svc.yaml:
```
apiVersion: v1
kind: Service
metadata:
  name: ilb-svc
  # Request an internal load balancer.
  annotations:
    networking.gke.io/load-balancer-type: "Internal"
spec:
  type: LoadBalancer
  # Evenly route external traffic to all endpoints.
  externalTrafficPolicy: Cluster
  # Prioritize routing traffic to endpoints that are in the same zone.
  trafficDistribution: PreferClose
  selector:
    app: ilb-deployment
  # Forward traffic from TCP port 80 to port 8080 in backend Pods.
  ports:
  - name: tcp-port
    protocol: TCP
    port: 80
    targetPort: 8080
```
  El manifiesto debe contener las siguientes características:
  - Un name para el objeto Service LoadBalancer interno, en este caso ilb-svc.
  - Una anotación que especifica que necesitas un objeto Service LoadBalancer interno. Para las versiones de GKE 1.17 y posteriores, usa la anotación networking.gke.io/load-balancer-type: "Internal" como se muestra en el manifiesto de ejemplo. Para versiones anteriores, usa cloud.google.com/load-balancer-type: "Internal" en su lugar.
  - El tipo type: LoadBalancer.
  - Un campo spec: selector para especificar los pods a los que se orientará el servicio, por ejemplo, app: hello.
  - Información del puerto:
    - port representa el puerto de destino en el que la regla de reenvío del balanceador de cargas de red de transferencia interno recibe paquetes.
    - El targetPort debe coincidir con un containerPort definido en cada Pod de entrega.
    - No es necesario que los valores port y targetPort sean los mismos. Los nodos siempre realizan NAT de destino y cambian la dirección IP de la regla de reenvío del balanceador de cargas de destino y port a una dirección IP de Pod de destino y targetPort. Para obtener más detalles, consulta Traducción de direcciones de red de destino en nodos en la documentación de conceptos del objeto Service LoadBalancer.
  El manifiesto puede contener lo siguiente:
  - spec.ipFamilyPolicy y ipFamilies para definir cómo GKE asigna direcciones IP al Service. GKE admite Objetos Service LoadBalancer de IP de pila única (solo IPv4 o solo IPv6) o de pila doble. Un objeto Service LoadBalancer de doble pila se implementa con dos reglas de reenvío del balanceador de cargas de red de transferencia interno separadas: una para el tráfico IPv4 y otra para el tráfico IPv6. El objeto Service LoadBalancer de pila doble de GKE está disponible en la versión 1.29 o posterior. Para obtener más información, consulta Services de pila doble de IPv4/IPv6.
  - spec.trafficDistribution para definir cómo GKE enruta el tráfico entrante (vista previa). Si configuras este campo como PreferClose, GKE enruta el tráfico que se origina en una zona a los nodos y Pods dentro de esa misma zona. Si no hay Pods en buen estado en la zona, GKE enruta el tráfico a otra zona. Si incluyes este campo, debes tener habilitado el subconjunto de GKE.
    
    Nota: También puedes habilitar o inhabilitar la afinidad zonal en un servicio LoadBalancer interno existente con el comando kubectl edit svc service-name. El comando kubectl edit abre el manifiesto del servicio del balanceador de cargas existente en el editor de texto configurado, en el que puedes agregar o quitar el parámetro spec.trafficDistribution y guardar los cambios. Es posible que el tráfico se interrumpa brevemente cuando modifiques este parámetro.
  Para obtener más información, consulta los parámetros del objeto Service LoadBalancer.
2. Aplica el manifiesto al clúster:
```
kubectl apply -f ilb-svc.yaml
```

Obtén información detallada sobre el servicio:

kubectl get service ilb-svc --output yaml

El resultado es similar a este:

apiVersion: v1
kind: Service
metadata:
  annotations:
    cloud.google.com/neg: '{"ingress":true}'
    cloud.google.com/neg-status: '{"network_endpoint_groups":{"0":"k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r"},"zones":["ZONE_NAME","ZONE_NAME","ZONE_NAME"]}'
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"v1","kind":"Service","metadata":{"annotations":{"networking.gke.io/load-balancer-type":"Internal"},"name":"ilb-svc","namespace":"default"},"spec":{"externalTrafficPolicy":"Cluster","ports":[{"name":"tcp-port","port":80,"protocol":"TCP","targetPort":8080}],"selector":{"app":"ilb-deployment"},"type":"LoadBalancer"}}
    networking.gke.io/load-balancer-type: Internal
    service.kubernetes.io/backend-service: k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r
    service.kubernetes.io/firewall-rule: k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r
    service.kubernetes.io/firewall-rule-for-hc: k8s2-pn2h9n5f-l4-shared-hc-fw
    service.kubernetes.io/healthcheck: k8s2-pn2h9n5f-l4-shared-hc
    service.kubernetes.io/tcp-forwarding-rule: k8s2-tcp-pn2h9n5f-default-ilb-svc-3bei4n1r
  creationTimestamp: "2022-07-22T17:26:04Z"
  finalizers:
  - gke.networking.io/l4-ilb-v2
  - service.kubernetes.io/load-balancer-cleanup
  name: ilb-svc
  namespace: default
  resourceVersion: "51666"
  uid: d7a1a865-7972-44e1-aa9e-db5be23d6567
spec:
  allocateLoadBalancerNodePorts: true
  clusterIP: 10.88.2.141
  clusterIPs:
  - 10.88.2.141
  externalTrafficPolicy: Cluster
  internalTrafficPolicy: Cluster
  ipFamilies:
  - IPv4
  ipFamilyPolicy: SingleStack
  ports:
  - name: tcp-port
    # Kubernetes automatically allocates a port on the node during the
    # process of implementing a Service of type LoadBalancer.
    nodePort: 30521
    port: 80
    protocol: TCP
    targetPort: 8080
  selector:
    app: ilb-deployment
  sessionAffinity: None
  trafficDistribution: PreferClose
  type: LoadBalancer
status:
  # IP address of the load balancer forwarding rule.
  loadBalancer:
    ingress:
    - ip: 10.128.15.245

El resultado tiene los siguientes atributos:

La dirección IP de la regla de reenvío del balanceador de cargas de red de transferencia interno se incluye en status.loadBalancer.ingress. Esta dirección IP es diferente del valor de clusterIP. En este ejemplo, la dirección IP de la regla de reenvío del balanceador de cargas es 10.128.15.245.
Cualquier Pod que tenga la etiqueta app: ilb-deployment es un Pod de entrega para este Service. Estos son los Pods que reciben paquetes enrutados por el balanceador de cargas de red de transferencia interno.
Los clientes llaman al Service mediante esta dirección IP de loadBalancer y el puerto de destino TCP especificado en el campo port del manifiesto del Service. Para obtener detalles completos sobre cómo se enrutan los paquetes una vez que un nodo los recibe, consulta Procesamiento de paquetes.
GKE asignó un nodePort al objeto Service. En este ejemplo, se asigna el puerto 30521. El nodePort no es relevante para el balanceador de cargas de red de transferencia interno.

Inspecciona el grupo de extremos de red de Service:
```
kubectl get svc ilb-svc -o=jsonpath="{.metadata.annotations.cloud\.google\.com/neg-status}"
```
El resultado es similar a este:
```
{"network_endpoint_groups":{"0":"k8s2-knlc4c77-default-ilb-svc-ua5ugas0"},"zones":["ZONE_NAME"]}
```
La respuesta indica que GKE creó un grupo de extremos de red llamado k8s2-knlc4c77-default-ilb-svc-ua5ugas0. Esta anotación está presente en los servicios del tipo LoadBalancer que utilizan la subdivisión de GKE y no está presente en los Services que no usan la subdivisión de GKE.

Verifica los componentes del balanceador de cargas de red de transferencia interno

En esta sección, se muestra cómo verificar los componentes clave de tu balanceador de cargas de red de transferencia interno.

Verifica que el Service esté en ejecución:
```
kubectl get service SERVICE_NAME --output yaml
```
Reemplaza SERVICE_NAME por el nombre del manifiesto del servicio.

Si habilitaste la afinidad zonal, el resultado incluye el parámetro spec.trafficDistribution con el campo establecido en PreferClose.
Verifica la dirección IP de la regla de reenvío del balanceador de cargas de red de transferencia interno. La dirección IP de la regla de reenvío del balanceador de cargas de red de transferencia interno es 10.128.15.245 en el ejemplo incluido en la sección Crea un Service LoadBalancer interno. Verifica que esta regla de reenvío se incluya en la lista de reglas de reenvío del proyecto del clúster con Google Cloud CLI:
```
gcloud compute forwarding-rules list --filter="loadBalancingScheme=INTERNAL"
```
El resultado incluye la regla de reenvío del balanceador de cargas de red de transferencia interno relevante, su dirección IP y el servicio de backend al que hace referencia la regla de reenvío (en este ejemplo, k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r).
```
NAME                          ... IP_ADDRESS  ... TARGET
...
k8s2-tcp-pn2h9n5f-default-ilb-svc-3bei4n1r   10.128.15.245   ZONE_NAME/backendServices/k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r
```
Describe el servicio de backend del balanceador de cargas con Google Cloud CLI:
```
gcloud compute backend-services describe k8s2-tcp-pn2h9n5f-default-ilb-svc-3bei4n1r --region=COMPUTE_REGION
```
Reemplaza COMPUTE_REGION por la región de procesamiento del servicio de backend.

Si habilitaste la afinidad zonal, haz lo siguiente:
- El campo networkPassThroughLbTrafficPolicy.zonalAffinity.spillover debe establecerse en ZONAL_AFFINITY_SPILL_CROSS_ZONE.
- El campo networkPassThroughLbTrafficPolicy.zonalAffinity.spilloverRatio debe establecerse en 0 o no incluirse.
El resultado incluye el NEG GCE_VM_IP de backend o los NEGs para el Service (en este ejemplo, k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r).
```
backends:
- balancingMode: CONNECTION
  group: .../ZONE_NAME/networkEndpointGroups/k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r
...
kind: compute#backendService
loadBalancingScheme: INTERNAL
name: aae3e263abe0911e9b32a42010a80008
networkPassThroughLbTrafficPolicy:
  zonalAffinity:
    spillover: ZONAL_AFFINITY_SPILL_CROSS_ZONE
protocol: TCP
...
```
Si inhabilitaste la afinidad zonal, el campo networkPassThroughLbTrafficPolicy.zonalAffinity.spillover debe establecerse en ZONAL_AFFINITY_DISABLED o no incluirse. Ten en cuenta que la afinidad zonal se inhabilita automáticamente si tu clúster se encuentra en una versión anterior a la 1.33.3-gke.1392000.
Determina la lista de nodos en un subconjunto para un servicio:
```
gcloud compute network-endpoint-groups list-network-endpoints NEG_NAME \
    --zone=COMPUTE_ZONE
```
Reemplaza lo siguiente:
- NEG_NAME: el nombre del grupo de extremos de red que crea el controlador de GKE.
- COMPUTE_ZONE: La zona de procesamiento de extremos de red en la que se operará.
Determina la lista de nodos en buen estado para un balanceador de cargas de red de transferencia interno:
```
gcloud compute backend-services get-health SERVICE_NAME \
    --region=COMPUTE_REGION
```
Reemplaza lo siguiente:
- SERVICE_NAME: el nombre del servicio de backend. Este valor es el mismo que el nombre del grupo de extremos de red creado por el controlador de GKE.
- COMPUTE_REGION: es la región de procesamiento del servicio de backend en la que se operará.

Prueba la conectividad al balanceador de cargas de red de transferencia interno

Ejecuta el siguiente comando en la misma región que el clúster:

curl LOAD_BALANCER_IP:80

Reemplaza LOAD_BALANCER_IP por la dirección IP de la regla de reenvío del balanceador de cargas.

La respuesta muestra la salida de ilb-deployment:

Hello, world!
Version: 1.0.0
Hostname: ilb-deployment-77b45987f7-pw54n

Solo se puede acceder al balanceador de cargas de red de transferencia interno dentro de la misma red de VPC (o una red conectada). De forma predeterminada, la regla de reenvío del balanceador de cargas tiene inhabilitado el acceso global, por lo que las VMs de cliente, los túneles de Cloud VPN o los adjuntos de Cloud Interconnect (VLAN) deben estar ubicados en la misma región que el balanceador de cargas de red de transferencia interno. Para admitir clientes en todas las regiones, puedes habilitar el acceso global en la regla de reenvío del balanceador de cargas si incluyes la anotación de acceso global en el manifiesto del objeto Service.

Borra el objeto Service LoadBalancer interno y los recursos del balanceador de cargas

Puedes borrar el Deployment y el Service con kubectl delete o laGoogle Cloud consola.

kubectl

Borra la implementación

Para borrar la implementación, ejecuta el siguiente comando:

kubectl delete deployment ilb-deployment

Borra el servicio

Para borrar el servicio, ejecuta el siguiente comando:

kubectl delete service ilb-svc

Console

Borra la implementación

Para borrar la implementación, sigue estos pasos:

Accede a la página Cargas de trabajo de la consola de Google Cloud .

Ir a Cargas de trabajo
Selecciona la implementación que deseas borrar y, luego, haz clic en Borrar.
Cuando se le solicite que confirme la acción, seleccione la casilla de verificación Borrar el escalador automático horizontal del Pod asociado con la implementación seleccionada y, luego, haga clic en Borrar.

Borra el servicio

Para borrar el servicio, sigue estos pasos:

Ve a la página Ingress y Service en la consola de Google Cloud .

Ir a Ingress y Service
Selecciona el servicio que quieres borrar y, luego, haz clic en Borrar.
Cuando se te solicite confirmar, haz clic en Borrar.

IP compartida

El balanceador de cargas de red de transferencia interno permite el uso compartido de una dirección IP virtual entre varias reglas de reenvío. Esto es útil para expandir la cantidad de puertos simultáneos en la misma IP o aceptar tráfico de UDP y TCP en la misma IP. Permite un máximo de 50 puertos expuestos por dirección IP. Las IP compartidas se admiten de forma nativa en los clústeres de GKE con servicios de LoadBalancer internos. Cuando se implementa, el campo loadBalancerIP del servicio se usa para indicar qué IP se debe compartir entre los servicios.

Limitaciones

Una IP compartida para varios balanceadores de cargas tiene las siguientes limitaciones y capacidades:

Cada regla de reenvío puede tener hasta cinco puertos (contiguos o no contiguos) o se puede configurar para que coincida con el tráfico y lo reenvíe en todos los puertos. Si un objeto Service de tipo LoadBalancer interno define más de cinco puertos, la regla de reenvío se establecerá automáticamente para que coincida con todos los puertos.
Un máximo de diez servicios (reglas de reenvío) pueden compartir una dirección IP. Esto da como resultado un máximo de 50 puertos por IP compartida.
Cada regla de reenvío que comparte la misma dirección IP debe usar una combinación única de protocolos y puertos. Por lo tanto, cada objeto Service LoadBalancer interno debe usar un conjunto único de protocolos y puertos.
Se admite una combinación de servicios de solo TCP y de solo UDP en la misma IP compartida. Sin embargo, no puedes exponer ambos puertos de TCP y UDP en el mismo servicio.

Habilita la IP compartida

Si deseas habilitar que los servicios de LoadBalancer internos compartan una IP común, sigue estos pasos:

Crea una IP interna estática con --purpose SHARED_LOADBALANCER_VIP. Se debe crear una dirección IP con esta finalidad para habilitar su capacidad de ser compartida. Si creas la dirección IP interna estática en una VPC compartida, debes crear la dirección IP en el mismo proyecto de servicio que la instancia que usará la dirección IP, aunque el valor de la dirección IP vendrá del rango de IP disponibles en una subred compartida seleccionada de la red de VPC compartida. Consulta Reserva una IP interna estática en la página Aprovisiona la VPC compartida para obtener más información.
Implementa hasta diez servicios de LoadBalancer internos mediante esta IP estática en el campo loadBalancerIP. El controlador del servicio de GKE concilia los balanceadores de cargas de red de transferencia internos y estos se implementan mediante la misma IP de frontend.

En el siguiente ejemplo, se muestra cómo hacer esto con el fin de admitir varios puertos de TCP y UDP en la misma IP del balanceador de cargas interno.

Crea una IP estática en la misma región en la que se encuentra el clúster de GKE. La subred debe ser la misma que usa el balanceador de cargas. De forma predeterminada, es la misma subred que usan las IP del nodo del clúster de GKE.

Si tu clúster y la red de VPC están en el mismo proyecto, haz lo siguiente:
```
gcloud compute addresses create IP_ADDR_NAME \
    --project=PROJECT_ID \
    --subnet=SUBNET \
    --addresses=IP_ADDRESS \
    --region=COMPUTE_REGION \
    --purpose=SHARED_LOADBALANCER_VIP
```
Si tu clúster está en un proyecto de servicio de VPC compartida, pero usa una red de VPC compartida en un proyecto host, haz lo siguiente:
```
gcloud compute addresses create IP_ADDR_NAME \
    --project=SERVICE_PROJECT_ID \
    --subnet=projects/HOST_PROJECT_ID/regions/COMPUTE_REGION/subnetworks/SUBNET \
    --addresses=IP_ADDRESS \
    --region=COMPUTE_REGION \
    --purpose=SHARED_LOADBALANCER_VIP
```
Reemplaza lo siguiente:
- IP_ADDR_NAME: un nombre para el objeto de dirección IP
- SERVICE_PROJECT_ID: el ID del proyecto de servicio
- PROJECT_ID: el ID de tu proyecto (proyecto único)
- HOST_PROJECT_ID: el ID del proyecto host de la VPC compartida
- COMPUTE_REGION: es la región de procesamiento que contiene la subred compartida.
- IP_ADDRESS: una dirección IP interna sin usar del rango de direcciones IP principal de la subred seleccionada Si omites especificar una dirección IP, Google Cloud selecciona una dirección IP interna sin usar del rango de direcciones IP principal de la subred seleccionada. Para determinar una dirección seleccionada de forma automática, deberás ejecutar gcloud compute addresses describe.
- SUBNET: el nombre de la subred compartida

Guarda la siguiente configuración del servicio de TCP en un archivo llamado tcp-service.yaml y, luego, impleméntala en el clúster. Reemplaza IP_ADDRESS por la dirección IP que elegiste en el paso anterior.

apiVersion: v1
kind: Service
metadata:
  name: tcp-service
  namespace: default
  # Request an internal load balancer.
  annotations:
    networking.gke.io/load-balancer-type: "Internal"
spec:
  type: LoadBalancer
  # Use an IP address that you create.
  loadBalancerIP: IP_ADDRESS
  selector:
    app: myapp
  ports:
  - name: 8001-to-8001
    protocol: TCP
    port: 8001
    targetPort: 8001
  - name: 8002-to-8002
    protocol: TCP
    port: 8002
    targetPort: 8002
  - name: 8003-to-8003
    protocol: TCP
    port: 8003
    targetPort: 8003
  - name: 8004-to-8004
    protocol: TCP
    port: 8004
    targetPort: 8004
  - name: 8005-to-8005
    protocol: TCP
    port: 8005
    targetPort: 8005

Aplica esta definición de servicio en el clúster:
```
kubectl apply -f tcp-service.yaml
```

Guarda la siguiente configuración del servicio de UDP en un archivo llamado udp-service.yaml y, luego, impleméntala. También usa el IP_ADDRESS que especificaste en el paso anterior.

apiVersion: v1
kind: Service
metadata:
  name: udp-service
  namespace: default
  # Request an internal load balancer.
  annotations:
    networking.gke.io/load-balancer-type: "Internal"
spec:
  type: LoadBalancer
  # Use the same IP address that you used for the TCP Service.
  loadBalancerIP: IP_ADDRESS
  selector:
    app: my-udp-app
  ports:
  - name: 9001-to-9001
    protocol: UDP
    port: 9001
    targetPort: 9001
  - name: 9002-to-9002
    protocol: UDP
    port: 9002
    targetPort: 9002

Aplica este archivo en el clúster:
```
kubectl apply -f udp-service.yaml
```

Para validar que la VIP se comparta entre las reglas de reenvío del balanceador de cargas, enuméralas y filtra la IP estática. Esto muestra que hay una regla de reenvío de UDP y una de TCP que escuchan en siete puertos diferentes en el IP_ADDRESS compartido, que en este ejemplo es 10.128.2.98.

gcloud compute forwarding-rules list | grep 10.128.2.98
ab4d8205d655f4353a5cff5b224a0dde                         us-west1   10.128.2.98     UDP          us-west1/backendServices/ab4d8205d655f4353a5cff5b224a0dde
acd6eeaa00a35419c9530caeb6540435                         us-west1   10.128.2.98     TCP          us-west1/backendServices/acd6eeaa00a35419c9530caeb6540435

Problemas conocidos

Tiempo de espera de conexión cada 10 minutos

Los servicios LoadBalancer internos creados con subdivisión pueden observar interrupciones del tráfico cada 10 minutos, aproximadamente. Este error se corrigió en las siguientes versiones:

1.18.19-gke.1700 y posteriores
1.19.10-gke.1000 y posteriores
1.20.6-gke.1000 y posteriores

Error durante la creación del balanceador de cargas en el nivel Estándar

Cuando creas un balanceador de cargas de red de transferencia interno en un proyecto con el nivel de red predeterminado del proyecto configurado como Estándar, aparece el siguiente mensaje de error:

Error syncing load balancer: failed to ensure load balancer: googleapi: Error 400: STANDARD network tier (the project's default network tier) is not supported: Network tier other than PREMIUM is not supported for loadBalancingScheme=INTERNAL., badRequest

Para resolver este problema en las versiones de GKE anteriores a 1.23.3-gke.900, configura el nivel de red predeterminado del proyecto como Premium.

Este problema se resuelve en las versiones 1.23.3-gke.900 y posteriores de GKE cuando la subdivisión de GKE está habilitada.

El controlador de GKE crea balanceadores de cargas de red de transferencia internos en el nivel de red Premium, incluso si el nivel de red predeterminado del proyecto está configurado en Estándar.

¿Qué sigue?

Consulta la descripción general de la red GKE.
Más información sobre el balanceador de cargas de Compute Engine.
Obtén información para crear un clúster nativo de la VPC.
Soluciona problemas de balanceo de cargas en GKE.
Más información sobre el agente de enmascaramiento de IP.
Obtén información sobre cómo configurar redes autorizadas.