Crea un balanceador de cargas interno (original) (raw)

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, aprende a Crear un Service de tipo LoadBalancer.

Usa la subdivisión del balanceador de cargas de red de transferencia interno

Los balanceadores de cargas de red de transferencia internos permiten que los clientes dentro de 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. No es necesario que los clientes estén ubicados en tu clúster. Por ejemplo, se puede acceder a un objeto Service LoadBalancer interno para las instancias de máquina virtual (VM) que se encuentran en la red de VPC del clúster.

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. Los extremos miembros en el NEG son las direcciones IP de los nodos que tienen al menos uno de los Pods de entrega del objeto Service. Para obtener más información sobre la subdivisión de GKE, consulta Agrupación de nodos.

Requisitos y limitaciones

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

Antes de comenzar

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

Habilita la subdivisión de GKE en un clúster estándar nuevo

Puedes crear un clúster Standard con la subdivisión de GKE habilitada a través de Google Cloud CLI, la consola de Google Cloud o Terraform. Un clúster creado con la subdivisión de GKE habilitada siempre usa la subdivisión de GKE.

Console

  1. Ve a la página de Google Kubernetes Engine en la consola de Google Cloud.
    Ir a Google Kubernetes Engine
  2. Haz clic en Crear.
  3. Configura tu clúster como desees.
  4. En el panel de navegación, en Clúster, haz clic en Redes.
  5. Selecciona la casilla de verificación Habilitar subconjunto para balanceadores de cargas internos L4.
  6. Haz clic en Crear.

gcloud

gcloud container clusters create CLUSTER_NAME \
    --cluster-version=VERSION \
    --enable-l4-ilb-subsetting \
    --location=COMPUTE_LOCATION

Reemplaza lo siguiente:

Para usar una red o subred no predeterminadas, ejecuta el siguiente comando:

  gcloud container clusters create CLUSTER_NAME \
      --cluster-version=VERSION \
      --network NETWORK_NAME \
      --subnetwork SUBNETWORK_NAME \
      --enable-l4-ilb-subsetting \
      --location=COMPUTE_LOCATION

Reemplaza lo siguiente:

Terraform

Para crear un clúster Standard con la subdivisión de GKE habilitada a través de Terraform, consulta el siguiente ejemplo:

Si deseas obtener más información sobre el uso de Terraform, consulta Compatibilidad con Terraform para GKE.

Habilita la subdivisión de GKE en un clúster estándar existente

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

Consola

  1. En la consola de Google Cloud, ve a la página Google Kubernetes Engine.
    Ir a Google Kubernetes Engine
  2. En la lista de clústeres, haz clic en el nombre del clúster que deseas modificar.
  3. 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.
  4. Selecciona la casilla de verificación Habilitar subconjunto para balanceadores de cargas internos L4.
  5. Haz clic en Save Changes.

gcloud

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

Reemplaza lo siguiente:

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.

  1. 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
  1. Aplica el manifiesto al clúster:
kubectl apply -f ilb-deployment.yaml

Crea un objeto Service LoadBalancer interno

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  
  annotations:  
    networking.gke.io/load-balancer-type: "Internal"  
spec:  
  type: LoadBalancer  
  externalTrafficPolicy: Cluster  
  selector:  
    app: ilb-deployment  
  ports:  
  - name: tcp-port  
    protocol: TCP  
    port: 80  
    targetPort: 8080

El manifiesto debe contener las siguientes características:

El manifiesto puede contener lo siguiente:

  1. Aplica el manifiesto al clúster:
kubectl apply -f ilb-svc.yaml
  1. 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  
    nodePort: 30521  
    port: 80  
    protocol: TCP  
    targetPort: 8080  
  selector:  
    app: ilb-deployment  
  sessionAffinity: None  
  type: LoadBalancer  
status:  
  loadBalancer:  
    ingress:  
    - ip: 10.128.15.245

El resultado tiene los siguientes atributos:

  1. 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

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. Puedes ver que esta regla de reenvío se incluye en la lista de reglas de reenvío del proyecto del clúster mediante 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

Puedes describir el servicio de backend del balanceador de cargas mediante 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.

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
...

A fin de determinar la lista de nodos en el subconjunto de un servicio, usa el siguiente comando:

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

Reemplaza lo siguiente:

Para determinar la lista de nodos en buen estado para un balanceador de cargas de red de transferencia interno, usa el siguiente comando:

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

Reemplaza lo siguiente:

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

Establece una conexión SSH a una instancia de VM en la misma red de VPC y en la misma región que el clúster, luego, ejecuta el siguiente comando:

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 los objetos Deployment y Service con kubectl delete o la consola de Google Cloud.

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

Consola

Borra la implementación

Para borrar la implementación, sigue estos pasos:

  1. Ve a la página Cargas de trabajo en la consola de Google Cloud.
    Ir a Cargas de trabajo
  2. Selecciona la implementación que deseas borrar y, luego, haz clic en Borrar.
  3. 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:

  1. Ve a la página Ingress y servicios en la consola de Google Cloud.
    Ir a Ingress y Service
  2. Selecciona el servicio que quieres borrar y, luego, haz clic en Borrar.
  3. 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:

Habilita la IP compartida

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

  1. 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.
  2. 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.

  1. 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:

  1. 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  
  annotations:  
    networking.gke.io/load-balancer-type: "Internal"  
spec:  
  type: LoadBalancer  
  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
  1. Aplica esta definición de servicio en el clúster:
kubectl apply -f tcp-service.yaml
  1. 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  
  annotations:  
    networking.gke.io/load-balancer-type: "Internal"  
spec:  
  type: LoadBalancer  
  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
  1. Aplica este archivo en el clúster:
kubectl apply -f udp-service.yaml
  1. 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

Restricciones y límites

Restricciones para los balanceadores de cargas de red de transferencia internos

Restricciones para balanceadores de cargas de UDP internos

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:

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?