Gestionar balanceadores de carga

En esta página de descripción general se explica cómo configurar balanceadores de carga internos y externos en Google Distributed Cloud (GDC) con air gap para configuraciones de red zonales y globales.

El balanceo de carga de GDC asegura una distribución eficiente del tráfico entre las cargas de trabajo backend, lo que mejora la disponibilidad y el rendimiento de las aplicaciones.

Esta página está dirigida a los administradores de redes que pertenecen al grupo de administradores de la plataforma o a los desarrolladores que pertenecen al grupo de operadores de aplicaciones, que son los responsables de gestionar el tráfico de red de su organización. Para obtener más información, consulta la documentación sobre audiencias de GDC en entornos aislados.

Arquitectura de balanceo de carga

GDC proporciona balanceadores de carga que permiten que las aplicaciones expongan servicios entre sí. Los balanceadores de carga asignan una dirección IP virtual (VIP) estable que balancea el tráfico entre un conjunto de cargas de trabajo de backend. Los balanceadores de carga de GDC realizan el balanceo de carga de capa cuatro (L4), lo que significa que asignan un conjunto de puertos TCP o UDP de frontend configurados a los puertos de backend correspondientes. Los balanceadores de carga se configuran a nivel de proyecto.

Los balanceadores de carga se configuran para los siguientes tipos de cargas de trabajo:

  • Cargas de trabajo que se ejecutan en máquinas virtuales.
  • Cargas de trabajo en contenedores dentro del clúster de Kubernetes.

Hay tres formas de configurar balanceadores de carga en GDC:

  • Usa la API del modelo de recursos de Kubernetes (KRM) de redes. Puedes usar esta API para crear balanceadores de carga globales o zonales.
  • Usa la CLI de gdcloud. Puedes usar esta API para crear balanceadores de carga globales o zonales.
  • Usa el servicio de Kubernetes directamente desde el clúster de Kubernetes. Este método solo crea balanceadores de carga zonales.

Componentes del balanceador de carga

Cuando usas la API KRM o la CLI gdcloud para configurar el balanceador de carga, usas un balanceador de carga de transferencia de nivel 4:

  • L4 significa que el protocolo es TCP o UDP.
  • Passthrough significa que no hay ningún proxy entre la carga de trabajo y el cliente.

El balanceador de carga consta de los siguientes componentes configurables:

  • Reglas de reenvío: especifican qué tráfico se reenvía y a qué servicio de backend. Las reglas de reenvío tienen las siguientes especificaciones:

    • Consta de tres tuplas: CIDR, puerto y protocolo, para que el cliente pueda acceder.
    • Admite los protocolos TCP y UDP.
    • Ofrece reglas de reenvío internas y externas. Los clientes pueden acceder a las reglas de reenvío internas desde la nube privada virtual (VPC). Los clientes pueden acceder a reglas de reenvío externas desde fuera de la plataforma de GDC o desde dentro mediante cargas de trabajo que tengan definido el valor EgressNAT.
    • Las reglas de reenvío se conectan a un servicio de backend. Puede hacer que varias reglas de reenvío apunten al mismo servicio de backend.

  • Servicios de backend: son el centro de balanceo de carga que vincula reglas de reenvío, comprobaciones del estado y backends. Un servicio de backend hace referencia a un objeto de backend, que identifica las cargas de trabajo a las que el balanceador de carga reenvía el tráfico. Hay limitaciones en cuanto a los backends a los que puede hacer referencia un servicio de backend:

    • Un recurso de backend de zona por zona.
    • Un recurso de backend de clúster por clúster. No se puede mezclar con los back-ends del proyecto.

  • Backends: un objeto zonal que especifica los endpoints que actúan como backends de los servicios de backend creados. Los recursos de backend deben limitarse a una zona. Selecciona endpoints mediante etiquetas. Limita el selector a un proyecto o clúster:

    • Un backend de proyecto es un backend que no tiene especificado el campo ClusterName. En este caso, las etiquetas especificadas se aplican a todas las cargas de trabajo del proyecto concreto, en la VPC específica de una zona. Las etiquetas se aplican a las cargas de trabajo de VMs y pods en varios clústeres. Cuando un servicio de backend usa un backend de proyecto, no puedes hacer referencia a otro backend de esa zona en ese servicio de backend.

    • Un backend de clúster es un backend que tiene especificado el campo ClusterName. En este caso, las etiquetas especificadas se aplican a todas las cargas de trabajo del clúster con el nombre indicado en el proyecto especificado. Puedes especificar como máximo un backend por zona y por clúster en un solo servicio de backend.

  • Comprobaciones del estado: especifica las sondas para determinar si el endpoint de una carga de trabajo determinada del backend está en buen estado. El endpoint en mal estado se retira del balanceador de carga hasta que vuelve a estar en buen estado. Las comprobaciones de estado solo se aplican a las cargas de trabajo de las máquinas virtuales. Las cargas de trabajo de pods pueden usar el mecanismo de comprobación de Kubernetes integrado para determinar si un endpoint específico está en buen estado.

Cuando se usa el servicio de Kubernetes directamente desde el clúster de usuario de Kubernetes, se usa el objeto Service en lugar de los componentes indicados anteriormente. Solo puedes orientar cargas de trabajo en el clúster en el que se crea el objeto Service.

Balanceo de carga interno y externo

Las aplicaciones de GDC tienen acceso a los siguientes tipos de servicios de red:

  • Balanceador de carga interno (ILB): te permite exponer un servicio a otros clústeres de la organización.
  • Balanceador de carga externo (ELB): asigna una dirección IP virtual de un intervalo que se puede enrutar desde cargas de trabajo externas y expone servicios fuera de la organización de GDC, como otras organizaciones dentro o fuera de la instancia de GDC. Usa la afinidad de sesión para los ELBs para asegurarte de que las solicitudes de un cliente se dirijan de forma coherente al mismo backend.

Balanceadores de carga globales y de zona

Puedes crear balanceadores de carga globales o zonales. El ámbito de los balanceadores de carga globales abarca todo un universo de GDC. Cada universo de GDC puede constar de varias zonas de GDC organizadas en regiones interconectadas que comparten un plano de control. Por ejemplo, un universo que consta de dos regiones con tres zonas cada una podría tener este aspecto: us-virginia1-a, us-virginia1-b, us-virginia1-c y eu-ams1-a, eu-ams1-b, eu-ams1-c.

El ámbito de los balanceadores de carga zonales se limita a las zonas especificadas en el momento de la creación. Cada zona es un dominio de desastre independiente. Una zona gestiona la infraestructura, los servicios, las APIs y las herramientas que usan un plano de control local.

Para obtener más información sobre los recursos globales y de zona en un universo de GDC, consulta la descripción general de las multizonas.

Puedes crear balanceadores de carga globales con los siguientes métodos:

Puede crear balanceadores de carga zonales con los siguientes métodos:

  • Usa la API del modelo de recursos de Kubernetes (KRM) de redes. Usa la versión networking.gdc.goog de la API para crear recursos zonales.
  • Usa la CLI de gdcloud. Usa la marca --zone al usar los comandos de la CLI de gdcloud para especificar en qué zonas se van a crear los balanceadores de carga.
  • Usa el servicio de Kubernetes directamente desde el clúster de Kubernetes.

Direcciones IP virtuales de servicio

Los balanceadores de carga internos asignan direcciones VIP que son internas a la organización. No se puede acceder a estas direcciones VIP desde fuera de la organización, por lo que solo puedes usarlas para exponer servicios a otras aplicaciones de la organización. Estas direcciones IP pueden superponerse entre organizaciones de la misma instancia.

Por otro lado, los ELBs asignan direcciones VIP a las que se puede acceder desde fuera de la organización. Por este motivo, las direcciones VIP de ELB deben ser únicas en todas las organizaciones. Normalmente, la organización tiene menos direcciones VIP de ELB disponibles.

Limitaciones

  • El recurso BackendService no debe configurarse con un recurso HealthCheck para cargas de trabajo de pods. Ten en cuenta que el HealthCheckName de la especificación BackendService es opcional y debe omitirse al configurar un balanceador de carga con pods.

  • Una configuración de balanceador de carga no puede dirigirse a cargas de trabajo mixtas que incluyan pods y VMs. Por lo tanto, no se permiten back-ends mixtos que incluyan pods y VMs en un mismo recurso BackendService.

  • Un recurso personalizado de balanceador de carga global (ForwardingRuleExternal, ForwardingRuleInternal, BackendService o HealthCheck) no debe tener el mismo nombre que estos recursos personalizados de balanceador de carga zonal.

    Siguientes pasos

  • Configurar balanceadores de carga internos

  • Configurar balanceadores de carga externos