Balanceo de cargas interno

En esta página se explica cómo crear un balanceador de cargas interno Compute Engine en Google Kubernetes Engine.

Descripción general

El Balanceo de cargas interno hace que los servicios de tu clúster sean accesibles para las aplicaciones fuera de tu clúster que usan la misma red de VPC y que se encuentran en la misma región de GCP. Por ejemplo, imagina que tienes un clúster en la región us-west1 y necesitas hacer que tus servicios sean accesibles para algunas instancias de VM de Compute Engine que se ejecutan en esa región en la misma red de VPC. Puedes hacerlo agregando un balanceador de cargas interno a uno de los recursos de Servicio de tus clústeres.

Sin el balanceo de cargas interno, tendrías que configurar balanceadores de cargas externos, crear reglas de firewall para limitar el acceso y configurar rutas de red que hagan que la dirección IP de la aplicación sea accesible fuera del clúster.

El balanceo de cargas interno crea una dirección IP privada (RFC 1918) LoadBalancer Ingress en el clúster para recibir tráfico en la red dentro de la misma región de procesamiento.

Puedes crear un balanceador de cargas interno usando kubectl para crear un recurso de Servicio con una anotación cloud.google.com/load-balancer-type: "Internal" y una especificación LoadBalancer.

Precios

Se te cobrará por el modelo de precios de Compute Engine. Consulta la página de precio de Balanceo de cargas interno para obtener más información.

Antes de comenzar

Lee acerca de las limitaciones del Balanceo de cargas interno.

Sigue estos pasos a fin de prepararte para esta tarea:

  • Asegúrate de habilitar la API de Google Kubernetes Engine.
  • Habilitar la API de Google Kubernetes Engine
  • Asegúrate de instalar el SDK de Cloud.
  • Configura el ID del proyecto predeterminado:
    gcloud config set project [PROJECT_ID]
  • Si trabajas con clústeres zonales, configura tu zona de procesamiento predeterminada:
    gcloud config set compute/zone [COMPUTE_ZONE]
  • Si trabajas con clústeres regionales, configura tu región de procesamiento predeterminada:
    gcloud config set compute/region [COMPUTE_REGION]
  • Actualiza gcloud a la versión más reciente:
    gcloud components update

Crea un balanceador de cargas interno

Las siguientes secciones explican cómo crear un balanceador de cargas interno con un Servicio. Parámetros de asistencia Service para el balanceador de cargas interno, como externalTrafficPolicy, sessionAffinity, y loadBalancerSourceRanges.

Escribe el archivo de configuración del servicio

El siguiente es un ejemplo de un Servicio service.yaml, que crea un balanceador de cargas interno:

apiVersion: v1
kind: Service
metadata:
  name: [SERVICE_NAME]
  annotations:
    cloud.google.com/load-balancer-type: "Internal"
  labels:
    [KEY]: [VALUE]
spec:
  type: LoadBalancer
  loadBalancerIP: [IP_ADDRESS] # if omitted, an IP is generated
  loadBalancerSourceRanges:
  - [IP_RANGE] # defaults to 0.0.0.0/0
  ports:
  - name: [PORT_NAME]
    port: 9000
    protocol: TCP # default; can also specify UDP
  selector:
    [KEY]: [VALUE] # label selector for Pods to target

El archivo de configuración de tu Servicio debe contener los siguientes puntos:

  • [SERVICE_NAME], el nombre que eliges para el Servicio
  • Una anotación, cloud.google.com/load-balancer-type: "Internal", que especifica que se debe configurar un balanceador de cargas interno
  • El tipo LoadBalancer y los campos de port.

También debes incluir lo siguiente:

  • Un arreglo spec: loadBalancerSourceRanges para especificar uno o más rangos RFC 1918 usados por tus redes de VPC, subredes o puertas de enlace VPN. loadBalancerSourceRanges restringe el tráfico a través del balanceador de cargas a las IP especificadas en este campo. Si no configuras este campo manualmente, el campo toma como valor predeterminado 0.0.0.0, lo que permite que todo el tráfico IPv4 llegue a los nodos.
  • Un campo spec: selector para especificar los pods que el servicio debe apuntar. Por ejemplo, el selector podría apuntar a pods etiquetados como app: web.

También puedes incluir los siguientes campos opcionales:

  • spec: loadBalancerIP habilita la opción de elegir una dirección IP específica para el balanceador de cargas. La dirección IP no debe estar en uso por otro balanceador de cargas interno o Servicio. Si se omite, se asigna una IP efímera. Para obtener más información sobre cómo reservar direcciones IP privadas dentro de subredes, consulta Reservar una dirección IP interna estática.
  • spec: ports: protocol define el protocolo de red que debe usar el puerto del balanceador de cargas interno. Si se omite, el puerto usa TCP.

Para obtener más información sobre la configuración loadBalancerSourceRanges a fin de restringir el acceso a tu balanceador de cargas interno, consulta Configuración de firewalls de tu proveedor de servicios en la nube. Para obtener más información sobre la especificación del servicio, consulta la Referencia de API de Servicio.

Cómo implementar el Servicio

Para crear el balanceador de cargas interno, ejecuta el siguiente comando en tu shell o ventana de terminal:

kubectl apply -f service.yaml

Cómo inspeccionar el Servicio

Después de la implementación, inspecciona el Servicio para verificar que se haya configurado correctamente.

gcloud

Para inspeccionar el balanceador de cargas interno, ejecuta el siguiente comando:

kubectl describe service [SERVICE_NAME]

La salida del comando es similar a la siguiente información:

Name:     [SERVICE_NAME]
Namespace:    default
Labels:     app=echo
Annotations:    cloud.google.com/load-balancer-type=Internal
Selector:   app=echo
Type:     LoadBalancer
IP:     10.0.146.226
LoadBalancer Ingress: 10.128.0.6
Port:       9000/TCP
NodePort:   30387/TCP
Endpoints:    10.100.1.10:80,10.100.2.10:80,10.100.3.8:80
Session Affinity: ClientIP

IP es la dirección IP del clúster del Servicio.

Console

Para inspeccionar el balanceador de cargas interno, realiza los siguientes pasos:

  1. Visita el menú de Servicios de Google Kubernetes Engine en la GCP Console.

    Visita el menú de Servicios.

  2. Selecciona el Servicio deseado.

El menú de detalles del Servicio incluye lo siguiente:

  • Extremos externos
  • IP del clúster
  • IP del balanceador de cargas
  • Una lista de pods entregados por el servicio

Cómo usar un balanceador de cargas interno

Puedes acceder al Servicio desde dentro del clúster con la dirección IP del clúster. Para acceder al Servicio desde fuera del clúster, usa la dirección IP LoadBalancer Ingress.

Consideraciones para los Ingress existentes

Si tu clúster tiene un recurso de Ingress existente, ese recurso debe usar el modo balanceo RATE. El modo balanceo UTILIZATION no es compatible con balanceadores de cargas internos.

Los recursos anteriores de BackendService creados por los objetos de recurso Ingress de Kubernetes se crearon sin un modo de balanceo especificado. Según la configuración predeterminada, la API usó el modo de balanceo UTILIZATION para los balanceadores de cargas de HTTP. Sin embargo, los balanceadores de cargas internos no se pueden apuntar a grupos de instancias con otros balanceadores de carga mediante UTILIZATION.

Para garantizar la compatibilidad con un balanceador de cargas interno y recursos de Ingress, es posible que debas realizar algunos pasos manuales.

Cómo determinar si tu Ingress es compatible

Para determinar si tu Ingress es compatible, ejecuta los siguientes comandos desde tu shell o ventana de terminal:

GROUPNAME=`kubectl get configmaps ingress-uid -o jsonpath='k8s-ig--{.data.uid}' --namespace=kube-system`
gcloud compute backend-services list --format="table(name,backends[].balancingMode,backends[].group)" | grep $GROUPNAME

Estos comandos exportan una variable de shell, GROUPNAME, que recupera el nombre del grupo de instancias de tu clúster. Luego, los recursos Compute Engine BackendService de tu proyecto se encuestan y los resultados se reducen en función de los contenidos de $GROUPNAME.

El resultado es similar al siguiente:

k8s-be-31210--...  [u'RATE']       us-central1-b/instanceGroups/k8s-ig--...
k8s-be-32125--...  [u'RATE']       us-central1-b/instanceGroups/k8s-ig--...

Si se muestran las entradas RATE de retorno de salida o las entradas cero, los balanceadores de cargas internos serán compatibles y no necesitarán trabajos adicionales.

Si las entradas de retorno de salida están marcadas con UTILIZATION, tus Ingress no serán compatibles.

Cómo actualizar tus Ingress existentes

El tipo de modo de balanceo de Ingress solo puede cambiar cuando no hay balanceadores de cargas HTTP(S) existentes que apunten al clúster.

Para actualizar tus recursos de Ingress y que sean compatibles con un balanceador de cargas interno, puedes crear un nuevo clúster que ejecute Kubernetes versión 1.7.2 o superior, y luego migrar tus servicios a ese clúster. La migración al nuevo clúster garantiza que no puedan existir Ingress con el modo de balanceo incompatible.

Restricciones para balanceadores de cargas internos

  • Tu instancia principal y los nodos deben ejecutar Kubernetes versión 1.7.2 o superior.
  • Los balanceadores de cargas internos solo son accesibles desde la misma red y región.
  • Los puertos internos del balanceador de cargas solo pueden entregar tráfico en un tipo de protocolo, TCP o UDP. El balanceador de cargas interno usa el protocolo del primer puerto especificado en la definición del Servicio.
  • Los balanceadores de cargas internos no admiten el uso de UDP y sessionAffinity: ClientIP juntos.
  • 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
  • Para clústeres que ejecutan Kubernetes 1.7.X, mientras el clusterIP permanece sin cambios, las direcciones IP del balanceador de cargas interno no se pueden reservar. Los cambios realizados en puertos, protocolos o afinidad de sesión pueden hacer que cambien estas direcciones IP.
  • La especificación de todos los puertos con una regla de reenvío del balanceador de cargas interno (en versión Beta) no es compatible actualmente con Google Kubernetes Engine (GKE).

Límites

El límite para el número de reglas de reenvío interno (ILB) es 50 por red de VPC y red de VPC compartida. Si una VPC intercambia tráfico con otra VPC, el límite se comparte entre todas las VPC de intercambio de tráfico.

Un Servicio Kubernetes con el tipo Loadbalancer y la anotación cloud.google.com/load-balancer-type: Internal crea un ILB que apunta al Servicio Kubernetes. Por lo tanto, GKE no admite la creación de más de 50 servicios de Kubernetes en una sola red de VPC o VPC compartida, incluidas las VPC de intercambio de tráfico.

En un clúster GKE, una regla de reenvío interno apunta a todos los nodos del clúster. Cada nodo en el clúster es un backend VM para el ILB. El número máximo de backend VM en un ILB es 250, independientemente de cómo se asocian las VM con los grupos de instancias. Por lo tanto, el número máximo de nodos en un clúster GKE con un ILB es 250. Si habilitaste el ajuste de escala automático para tu clúster, debes asegurarte de que el ajuste de escala automático no escala tu clúster más allá de los 250 nodos.

Para obtener más información sobre estos límites, consulta Cuotas de recursos de VPC.

Para obtener más información sobre las limitaciones de los balanceadores de cargas internos, consulta la sección Límites de la página de balanceo de cargas internas.

¿Qué sigue?

¿Te ha resultado útil esta página? Enviar comentarios:

Enviar comentarios sobre...