Crear un balanceador de carga interno

En esta página se explica cómo crear un balanceador de carga de red interno de tipo pasarela o un balanceador de carga interno en Google Kubernetes Engine (GKE). Para crear un balanceador de carga de red de paso a través externo, consulta Crear un servicio de tipo LoadBalancer.

Antes de leer esta página, asegúrate de que conoces los siguientes conceptos:

Usar un balanceador de carga de red de paso a través interno

Los balanceadores de carga de red internos de tipo pasarela permiten que los clientes ubicados en la red de VPC de tu clúster y en las redes conectadas a la red de VPC de tu clúster accedan a los servicios de tu clúster. Los clientes de la red VPC de tu clúster pueden ser nodos o pods de tu clúster, o bien máquinas virtuales fuera de tu clúster. Para obtener más información sobre la conectividad de los clientes en redes conectadas, consulta Balanceadores de carga de red internos de tipo pasarela y redes conectadas.

Usar el subconjunto de GKE

La subselección de GKE mejora la escalabilidad de los servicios LoadBalancer internos porque usa GCE_VM_IP grupos de puntos finales de red (NEGs) como backends en lugar de grupos de instancias. Cuando la creación de subconjuntos de GKE está habilitada, GKE crea un NEG por zona de cálculo por servicio de balanceador de carga interno.

El externalTrafficPolicy del servicio controla la pertenencia de los nodos a los backends de GCE_VM_IP NEG. Para obtener más información, consulta Pertenencia de nodos a back-ends de GCE_VM_IP NEG.

Usar la afinidad zonal

Cuando habilitas la afinidad zonal en un balanceador de carga de red con paso a través interno, GKE dirige el tráfico que procede de una zona a los nodos y pods de esa misma zona. Si no hay pods en buen estado en la zona, GKE dirige el tráfico a otra zona. Esta implementación se optimiza para la latencia y el coste.

Para habilitar la afinidad zonal en un clúster de GKE, debes tener habilitado el subconjunto de GKE.

Requisitos y limitaciones

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

Requisitos

El subconjunto de GKE tiene los siguientes requisitos y limitaciones:

  • Puedes habilitar la creación de subconjuntos de GKE en clústeres Standard nuevos y ya creados en las versiones 1.18.19-gke.1400 y posteriores de GKE. El subconjunto de GKE no se puede inhabilitar una vez que se ha habilitado.
  • El subconjunto de GKE está inhabilitado de forma predeterminada en los clústeres de Autopilot. Sin embargo, puedes habilitarlo después de crear el clúster.
  • Para usar el subconjunto de GKE, debes habilitar el complemento HttpLoadBalancing. Este complemento está habilitado de forma predeterminada. En los clústeres de Autopilot, no puedes inhabilitar este complemento obligatorio.
  • Se aplican las cuotas de los grupos de puntos finales de red. Google Cloud crea un NEG GCE_VM_IP por cada servicio de balanceador de carga interno por zona.
  • Se aplican cuotas a las reglas de reenvío, los servicios de backend y las comprobaciones del estado. Para obtener más información, consulta la página Cuotas y límites.
  • No se puede usar el subconjunto de GKE con la anotación para compartir un servicio de backend entre varios balanceadores de carga. alpha.cloud.google.com/load-balancer-backend-share
  • Debes tener la versión 345.0.0 o una posterior de Google Cloud CLI.

La afinidad zonal tiene los siguientes requisitos:

  • Puedes habilitar la afinidad zonal en clústeres nuevos y ya creados con la versión 1.33.3-gke.1392000 de GKE o una posterior.
  • Debes tener habilitado el subconjunto de GKE.
  • Debes asegurarte de que el complemento HttpLoadBalancing esté habilitado en tu clúster. Este complemento está habilitado de forma predeterminada y permite que el clúster gestione balanceadores de carga que usan servicios de backend.
  • Debes incluir spec.trafficDistribution: PreferClose en el manifiesto de LoadBalancer Service.

El manifiesto de servicio LoadBalancer puede usar externalTrafficPolicy: Local o externalTrafficPolicy: Cluster.

Limitaciones

Balanceadores de carga de red de paso a través internos

  • En los clústeres que ejecutan la versión 1.7.4 de Kubernetes o una posterior, puede usar balanceadores de carga internos con subredes en modo personalizado, además de con subredes en modo automático.
  • Los clústeres que ejecutan la versión 1.7.X de Kubernetes o una posterior admiten el uso de una dirección IP reservada para el balanceador de carga de red interno de pases si creas la dirección IP reservada con la marca --purpose definida en SHARED_LOADBALANCER_VIP. Consulta las instrucciones detalladas para habilitar la IP compartida. GKE solo conserva la dirección IP de un balanceador de carga de red interno de transferencia si el servicio hace referencia a una dirección IP interna con ese fin. De lo contrario, GKE podría cambiar la dirección IP del balanceador de carga (spec.loadBalancerIP) si se actualiza el servicio (por ejemplo, si se cambian los puertos).
  • Aunque cambie la dirección IP del balanceador de carga (consulta el punto anterior), el spec.clusterIP se mantiene constante.
  • Los balanceadores de carga UDP internos no admiten el uso de sessionAffinity: ClientIP.

Antes de empezar

Antes de empezar, asegúrate de que has realizado las siguientes tareas:

  • Habilita la API de Google Kubernetes Engine.
    • Habilitar la API de Google Kubernetes Engine
  • Si quieres usar Google Cloud CLI para esta tarea, instálala y, a continuación, inicialízala. Si ya has instalado la gcloud CLI, obtén la versión más reciente ejecutando gcloud components update.

Habilitar la creación de subconjuntos de GKE en un clúster

Puedes habilitar la creación de subconjuntos de GKE en un clúster que ya tengas mediante la CLI de gcloud o la Google Cloud consola. No puedes inhabilitar la creación de subconjuntos de GKE después de haberla habilitado.

Consola

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

    Ir a Google Kubernetes Engine

  2. En la lista de clústeres, haga clic en el nombre del clúster que quiera modificar.

  3. En Redes, junto al campo Subconjunto de balanceadores de carga internos L4, haz clic en Habilitar subconjunto de balanceadores de carga internos L4.

  4. Marca la casilla Habilitar el subconjunto de balanceadores de carga internos de nivel 4.

  5. Haz clic en Guardar cambios.

gcloud

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

Haz los cambios siguientes:

  • CLUSTER_NAME: el nombre del clúster.

Habilitar el subconjunto de GKE no interrumpe los servicios de balanceadores de carga internos. Si quieres migrar los servicios LoadBalancer internos que ya tengas para que usen servicios de backend con NEGs de GCE_VM_IP como backends, debes implementar un manifiesto de servicio de sustitución. Para obtener más información, consulta el artículo Agrupación de nodos de la documentación sobre los conceptos del servicio LoadBalancer.

Desplegar una carga de trabajo

El siguiente manifiesto describe un Deployment que ejecuta una imagen de contenedor de una aplicación web de ejemplo.

  1. Guarda el archivo de 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

  2. Aplica el manifiesto a tu clúster:

    kubectl apply -f ilb-deployment.yaml

Crear un servicio LoadBalancer interno

  1. (Opcional) Inhabilita la creación automática de reglas de cortafuegos de VPC:

    Aunque GKE crea automáticamente reglas de cortafuegos de VPC para permitir el tráfico a tu balanceador de carga interno, puedes inhabilitar la creación automática de reglas de cortafuegos de VPC y gestionar las reglas de cortafuegos por tu cuenta. Solo puedes inhabilitar las reglas de cortafuegos de VPC si has habilitado la subred de GKE en tu servicio LoadBalancer interno. Sin embargo, gestionar las reglas de cortafuegos de VPC es opcional y puedes usar las reglas automáticas.

    Antes de inhabilitar la creación automática de reglas de cortafuegos de VPC, asegúrate de definir reglas que permitan que el tráfico llegue a tu balanceador de carga y a tus pods de aplicación.

    Para obtener más información sobre cómo gestionar las reglas de cortafuegos de VPC, consulta Gestionar la creación automática de reglas de cortafuegos. Para saber cómo inhabilitar la creación automática de reglas de cortafuegos, consulta Reglas de cortafuegos gestionadas por el usuario para servicios LoadBalancer de GKE.

  2. En el siguiente ejemplo, se crea un servicio LoadBalancer interno mediante el puerto TCP 80. GKE implementa un balanceador de carga de red de paso a través 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 archivo de 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 lo siguiente:

      • Un name para el servicio LoadBalancer interno, en este caso ilb-svc.
      • Anotación que especifica que necesitas un servicio LoadBalancer interno. En las versiones 1.17 y posteriores de GKE, usa la anotación networking.gke.io/load-balancer-type: "Internal", tal como se muestra en el manifiesto de ejemplo. En versiones anteriores, usa cloud.google.com/load-balancer-type: "Internal".
      • El type: LoadBalancer.
      • Un campo spec: selector para especificar los pods a los que debe dirigirse el servicio, como app: hello.
      • Información del puerto:
        • port representa el puerto de destino en el que la regla de reenvío del balanceador de carga de red de paso a través interno recibe paquetes.
        • El valor de targetPort debe coincidir con un valor de containerPort definido en cada Pod de servicio.
        • Los valores de port y targetPort no tienen por qué ser iguales. Los nodos siempre realizan NAT de destino, cambiando la dirección IP y el port de la regla de reenvío del balanceador de carga de destino por una dirección IP y un targetPort de Pod de destino. Para obtener más información, consulta el artículo Traducción de direcciones de red de destino en nodos de la documentación sobre los conceptos del servicio LoadBalancer.

      El manifiesto puede contener lo siguiente:

      • spec.ipFamilyPolicy y ipFamilies para definir cómo asigna GKE direcciones IP al servicio. GKE admite servicios de balanceador de carga de IP de pila única (solo IPv4 o solo IPv6) o de pila dual. Un servicio LoadBalancer de doble pila se implementa con dos reglas de reenvío de balanceador de carga de red de paso a través internas independientes: una para el tráfico IPv4 y otra para el tráfico IPv6. El servicio LoadBalancer de doble pila de GKE está disponible en la versión 1.29 o posterior. Para obtener más información, consulta Servicios de pila dual IPv4/IPv6.

      • spec.trafficDistribution para definir cómo enruta GKE el tráfico entrante (vista previa). Si asignas el valor PreferClose a este campo, GKE enruta el tráfico que procede de una zona a los nodos y pods de esa misma zona. Si no hay pods en buen estado en la zona, GKE dirige el tráfico a otra zona. Si incluye este campo, debe tener habilitado el subconjunto de GKE.

      Para obtener más información, consulta los parámetros del servicio LoadBalancer.

    2. Aplica el manifiesto a tu clúster:

      kubectl apply -f ilb-svc.yaml

  3. Obtén información detallada sobre el Servicio:

    kubectl get service ilb-svc --output yaml

    El resultado debería ser similar al siguiente:

    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

    La salida tiene los siguientes atributos:

    • La dirección IP de la regla de reenvío del balanceador de carga de red de paso a través 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 carga es 10.128.15.245.
    • Cualquier pod que tenga la etiqueta app: ilb-deployment es un pod de servicio de este servicio. Estos son los pods que reciben los paquetes enrutados por el balanceador de carga de red de paso a través interno.
    • Los clientes llaman al servicio mediante esta dirección IP loadBalancer y el puerto de destino TCP especificado en el campo port del manifiesto del servicio. Para obtener información completa sobre cómo se enrutan los paquetes una vez que los recibe un nodo, consulta Procesamiento de paquetes.
    • GKE ha asignado un nodePort al servicio. En este ejemplo, se ha asignado el puerto 30521 . El nodePort no es relevante para el balanceador de carga de red de paso a través interno.

  4. Inspecciona el grupo de endpoints de red del servicio:

    kubectl get svc ilb-svc -o=jsonpath="{.metadata.annotations.cloud\.google\.com/neg-status}"

    El resultado debería ser similar al siguiente:

    {"network_endpoint_groups":{"0":"k8s2-knlc4c77-default-ilb-svc-ua5ugas0"},"zones":["ZONE_NAME"]}

    La respuesta indica que GKE ha creado un grupo de endpoints de red llamado k8s2-knlc4c77-default-ilb-svc-ua5ugas0. Esta anotación está presente en los servicios de tipo LoadBalancer que usan subconjuntos de GKE y no está presente en los servicios que no usan subconjuntos de GKE.

Verificar los componentes del balanceador de carga de red de paso a través interno

En esta sección se explica cómo verificar los componentes clave de tu balanceador de carga de red interno de tipo pasarela.

  • Comprueba que tu servicio se esté ejecutando:

    kubectl get service SERVICE_NAME --output yaml

    Sustituye SERVICE_NAME por el nombre del manifiesto de servicio.

    Si ha habilitado la afinidad zonal, la salida incluye el parámetro spec.trafficDistribution con el campo definido como PreferClose.

  • Verifica la dirección IP de la regla de reenvío del balanceador de carga de red de paso a través interno. La dirección IP de la regla de reenvío del balanceador de carga de red de paso a través interno es 10.128.15.245 en el ejemplo incluido en la sección Crear un servicio LoadBalancer interno. Verifica que esta regla de reenvío se incluye en la lista de reglas de reenvío del proyecto del clúster mediante la CLI de Google Cloud:

    gcloud compute forwarding-rules list --filter="loadBalancingScheme=INTERNAL"

    El resultado incluye la regla de reenvío del balanceador de carga de red de paso a través interno pertinente, su dirección IP y el servicio de backend al que hace referencia la regla de reenvío (k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r en este ejemplo).

    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 carga con la CLI de Google Cloud:

    gcloud compute backend-services describe k8s2-tcp-pn2h9n5f-default-ilb-svc-3bei4n1r --region=COMPUTE_REGION

    Sustituye COMPUTE_REGION por la región de computación del servicio de backend.

    Si has habilitado la afinidad zonal:

    • El campo networkPassThroughLbTrafficPolicy.zonalAffinity.spillover debe tener el valor ZONAL_AFFINITY_SPILL_CROSS_ZONE.
    • El campo networkPassThroughLbTrafficPolicy.zonalAffinity.spilloverRatio debe tener el valor 0 o no incluirse.

    El resultado incluye el backend GCE_VM_IP NEG o los NEGs del servicio (k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r en este ejemplo).

    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 has inhabilitado la afinidad zonal, el campo networkPassThroughLbTrafficPolicy.zonalAffinity.spillover debe tener el valor ZONAL_AFFINITY_DISABLED o no incluirse. Ten en cuenta que la afinidad zonal se inhabilita automáticamente si tu clúster tiene una versión anterior a la 1.33.3-gke.1392000.

  • Determina la lista de nodos de un subconjunto de un servicio:

    gcloud compute network-endpoint-groups list-network-endpoints NEG_NAME \
    --zone=COMPUTE_ZONE

    Haz los cambios siguientes:

    • NEG_NAME: el nombre del grupo de endpoints de red creado por el controlador de GKE.
    • COMPUTE_ZONE: la zona de cálculo del grupo de puntos finales de red en el que se va a operar.

  • Determina la lista de nodos en buen estado de un balanceador de carga de red de paso a través interno:

    gcloud compute backend-services get-health SERVICE_NAME \
    --region=COMPUTE_REGION

    Haz los cambios siguientes:

    • SERVICE_NAME: el nombre del servicio de backend. Este valor es el mismo que el nombre del grupo de endpoints de red creado por el controlador de GKE.
    • COMPUTE_REGION: la región de cálculo del servicio backend en la que se va a operar.

Probar la conectividad con el balanceador de carga de red de paso a través interno

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

curl LOAD_BALANCER_IP:80

Sustituye LOAD_BALANCER_IP por la dirección IP de la regla de reenvío del balanceador de carga.

La respuesta muestra el resultado de ilb-deployment:

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

Solo se puede acceder al balanceador de carga de red de paso a través interno desde la misma red de VPC (o desde una red conectada). De forma predeterminada, la regla de reenvío del balanceador de carga tiene inhabilitado el acceso global, por lo que las VMs cliente, los túneles de Cloud VPN o las vinculaciones de Cloud Interconnect (VLANs) deben estar ubicados en la misma región que el balanceador de carga de red con paso a través interno. Para admitir clientes de todas las regiones, puedes habilitar el acceso global en la regla de reenvío del balanceador de carga. Para ello, incluye la anotación globalAccess en el manifiesto de Service.

Eliminar el servicio LoadBalancer interno y los recursos del balanceador de carga

Puedes eliminar la implementación y el servicio con kubectl delete o con la consolaGoogle Cloud .

kubectl

Eliminar el despliegue

Para eliminar el Deployment, ejecuta el siguiente comando:

kubectl delete deployment ilb-deployment

Eliminar el servicio

Para eliminar el servicio, ejecuta el siguiente comando:

kubectl delete service ilb-svc

Consola

Eliminar el despliegue

Para eliminar la implementación, sigue estos pasos:

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

    Ve a Cargas de trabajo.

  2. Selecciona la implementación que quieras eliminar y haz clic en Eliminar.

  3. Cuando se te pida que confirmes la acción, selecciona la casilla Eliminar el escalado automático horizontal de pods asociado a la implementación seleccionada y haz clic en Eliminar.

Eliminar el servicio

Para eliminar el Servicio, sigue estos pasos:

  1. Ve a la página Servicios y entrada de la Google Cloud consola.

    Ir a Servicios e Ingress

  2. Selecciona el servicio que quieras eliminar y haz clic en Eliminar.

  3. Cuando se te pida que confirmes la acción, haz clic en Eliminar.

IP compartida

El balanceador de carga de red de paso a través interno permite compartir una dirección IP virtual entre varias reglas de reenvío. Esto resulta útil para aumentar el número de puertos simultáneos en la misma IP o para aceptar tráfico UDP y TCP en la misma IP. Permite un máximo de 50 puertos expuestos por dirección IP. Las IPs compartidas se admiten de forma nativa en los clústeres de GKE con servicios de tipo LoadBalancer internos. Durante la implementación, 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 carga tiene las siguientes limitaciones y funciones:

  • Cada regla de reenvío puede tener hasta cinco puertos (contiguos o no contiguos) o configurarse para que coincida con el tráfico y lo reenvíe en todos los puertos. Si un servicio de balanceador de carga interno define más de cinco puertos, la regla de reenvío se configurará 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 comparta la misma dirección IP debe usar una combinación única de protocolos y puertos. Por lo tanto, cada servicio LoadBalancer interno debe usar un conjunto único de protocolos y puertos.
  • Se admite una combinación de servicios solo TCP y solo UDP en la misma IP compartida, pero no puedes exponer puertos TCP y UDP en el mismo servicio.

Habilitar IP compartida

Para habilitar que los servicios de balanceador de carga interno compartan una IP común, sigue estos pasos:

  1. Crea una IP interna estática con --purpose SHARED_LOADBALANCER_VIP. Para poder compartir una dirección IP, se debe crear con este fin. Si creas la dirección IP interna estática en una VPC compartida, debes crearla en el mismo proyecto de servicio que la instancia que la va a usar, aunque el valor de la dirección IP proceda del intervalo de IPs disponibles de una subred compartida seleccionada de la red de VPC compartida. Para obtener más información, consulta la sección sobre cómo reservar una IP interna estática de la página Aprovisionar una VPC compartida.

  2. Implementa hasta diez servicios LoadBalancer internos con esta IP estática en el campo loadBalancerIP. Los balanceadores de carga de red de paso a través internos se reconcilian mediante el controlador de servicio de GKE y se implementan con la misma IP de frontend.

En el siguiente ejemplo se muestra cómo se hace para admitir varios puertos TCP y UDP en la misma IP de balanceador de carga interno.

  1. Crea una IP estática en la misma región que tu clúster de GKE. La subred debe ser la misma que usa el balanceador de carga, que, de forma predeterminada, es la misma que usan las IPs de los nodos del clúster de GKE.

    Si el clúster y la red 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 del 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

    Haz los cambios siguientes:

    • 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 (un solo proyecto).
    • HOST_PROJECT_ID: el ID del proyecto host de la VPC compartida.
    • COMPUTE_REGION: la región de cálculo que contiene la subred compartida.
    • IP_ADDRESS: una dirección IP interna sin usar del intervalo de direcciones IP principal de la subred seleccionada. Si no especificas una dirección IP, Google Cloud selecciona una dirección IP interna que no se haya usado del intervalo de direcciones IP principal de la subred seleccionada. Para determinar una dirección seleccionada automáticamente, debes ejecutar gcloud compute addresses describe.
    • SUBNET: el nombre de la subred compartida.

  2. Guarda la siguiente configuración de servicio TCP en un archivo llamado tcp-service.yaml y, a continuación, implementa el archivo en tu clúster. Sustituye IP_ADDRESS por la dirección IP que has elegido 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

  3. Aplica esta definición de servicio a tu clúster:

    kubectl apply -f tcp-service.yaml

  4. Guarda la siguiente configuración de servicio UDP en un archivo llamado udp-service.yaml y, a continuación, implementa el archivo. 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

  5. Aplica este archivo a tu clúster:

    kubectl apply -f udp-service.yaml

  6. Valida que la IP virtual se comparte entre las reglas de reenvío del balanceador de carga. Para ello, enuméralas y filtra por la IP estática. Esto muestra que hay una regla de reenvío de UDP y otra 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 de balanceador de carga interno creados con Subsetting pueden experimentar interrupciones del tráfico aproximadamente cada 10 minutos. Este error se ha corregido en las versiones:

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

Error al crear un balanceador de carga en el nivel Estándar

Cuando creas un balanceador de carga de red de paso a través interno en un proyecto con el nivel de red predeterminado del proyecto definido 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 solucionar este problema en versiones de GKE anteriores a la 1.23.3-gke.900, configura el nivel de red predeterminado del proyecto como Premium.

Este problema se ha resuelto en las versiones 1.23.3-gke.900 y posteriores de GKE cuando se habilita la creación de subconjuntos de GKE.

El controlador de GKE crea balanceadores de carga de red de transferencia internos en el nivel de red Premium, aunque el nivel de red predeterminado del proyecto sea Estándar.

Siguientes pasos