Administra balanceadores de cargas

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

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

Esta página está destinada a los administradores de red que pertenecen al grupo de administradores de la plataforma o a los desarrolladores que pertenecen al grupo de operadores de la aplicación, quienes son responsables de administrar el tráfico de red de su organización. Para obtener más información, consulta Audiences for GDC air-gapped documentation (Públicos para la documentación de GDC aislada del aire).

Arquitectura de balanceo de cargas

GDC proporciona balanceadores de cargas que permiten que las aplicaciones expongan servicios entre sí. Los balanceadores de cargas asignan una dirección IP virtual (VIP) estable que balancea el tráfico en un conjunto de cargas de trabajo de backend. Los balanceadores de cargas en GDC realizan el balanceo de cargas 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 cargas se configuran a nivel del proyecto.

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

  • Cargas de trabajo que se ejecutan en VMs
  • Cargas de trabajo alojadas en contenedores dentro del clúster de Kubernetes

Existen tres formas de configurar los balanceadores de cargas en GDC:

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

Componentes del balanceador de cargas

Cuando usas la API de KRM o la CLI de gdcloud para configurar el balanceador de cargas, usas un balanceador de cargas de transferencia de L4:

  • L4 significa que el protocolo es TCP o UDP.
  • El modo de transferencia significa que no hay proxy entre la carga de trabajo y el cliente.

El balanceador de cargas 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 acceda.
    • Admite protocolos TCP y UDP.
    • Ofrece reglas de reenvío internas y externas. Los clientes pueden acceder a las reglas de reenvío interno desde la nube privada virtual (VPC). Los clientes pueden acceder a las reglas de reenvío externas desde fuera de la plataforma de GDC o desde dentro por cargas de trabajo que tienen definido el valor EgressNAT.
    • Las reglas de reenvío se conectan a un servicio de backend. Puedes hacer que varias reglas de reenvío apunten al mismo servicio de backend.

  • Servicios de backend: Son el centro de balanceo de cargas que vincula las reglas de reenvío, las verificaciones de estado y los backends. Un servicio de backend hace referencia a un objeto de backend, que identifica las cargas de trabajo a las que el balanceador de cargas reenvía el tráfico. Existen limitaciones sobre los backends a los que puede hacer referencia un solo servicio de backend:

    • Un recurso de backend zonal por zona
    • Un recurso de backend del clúster por clúster. No se puede mezclar con los backends del proyecto.

  • Backends: Es un objeto zonal que especifica los extremos que actúan como backends para los servicios de backend creados. Los recursos de backend deben tener un alcance limitado a una zona. Selecciona extremos con etiquetas. Delimita 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 específico, en la VPC específica de una zona. Las etiquetas se aplican a las cargas de trabajo de VM y Pod en varios clústeres. Cuando un servicio de backend usa un backend del proyecto, no puedes hacer referencia a otro backend para 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 nombre en el proyecto especificado. Puedes especificar, como máximo, un backend por zona y por clúster en un solo servicio de backend.

  • Verificaciones de estado: Especifican los sondeos para determinar si un extremo de carga de trabajo determinado en el backend se encuentra en buen estado. El extremo en mal estado se quita del balanceador de cargas hasta que vuelve a estar en buen estado. Las verificaciones de estado solo se aplican a las cargas de trabajo de VM. Las cargas de trabajo de Pod pueden usar el mecanismo de sondeo integrado de Kubernetes para determinar si un extremo específico está en buen estado.

Cuando usas el servicio de Kubernetes directamente desde el clúster de usuario de Kubernetes, usas el objeto Service en lugar de los componentes que se mencionaron anteriormente. Solo puedes segmentar las cargas de trabajo en el clúster en el que se crea el objeto Service.

Balanceo de cargas interno y externo

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

  • Balanceador de cargas interno (ILB): Te permite exponer un servicio a otros clústeres dentro de la organización.
  • Balanceador de cargas externo (ELB): Asigna una dirección VIP desde un rango 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 ELB y asegúrate de que las solicitudes de un cliente se enruten de forma coherente al mismo backend.

Balanceadores de cargas globales y zonales

Puedes crear balanceadores de cargas globales o zonales. El alcance de los balanceadores de cargas globales abarca 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 verse de la siguiente manera: us-virginia1-a, us-virginia1-b, us-virginia1-c y eu-ams1-a, eu-ams1-b, eu-ams1-c.

El alcance de los balanceadores de cargas zonales se limita a las zonas especificadas en el momento de la creación. Cada zona es un dominio de desastre independiente. Una zona administra 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 zonales en un universo de GDC, consulta la Descripción general de varias zonas.

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

Puedes crear balanceadores de cargas zonales con los siguientes métodos:

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

Direcciones IP virtuales del servicio

Los ILB asignan direcciones VIP que son internas solo para la organización. No se puede acceder a estas direcciones VIP desde fuera de la organización. Por lo tanto, solo puedes usarlas para exponer servicios a otras aplicaciones dentro de una organización. Estas direcciones IP pueden superponerse entre organizaciones en la misma instancia.

Por otro lado, los ELB asignan direcciones VIP a las que se puede acceder externamente desde fuera de la organización. Por este motivo, las direcciones VIP de ELB deben ser únicas entre todas las organizaciones. Por lo general, la organización tiene menos direcciones VIP de ELB disponibles para su uso.

Limitaciones

  • El recurso BackendService no debe configurarse con un recurso HealthCheck para las cargas de trabajo de pods. Ten en cuenta que el HealthCheckName en la especificación de BackendService es opcional y se debe omitir cuando se configura un balanceador de cargas con Pods.

  • Una configuración del balanceador de cargas no puede segmentar cargas de trabajo mixtas que involucren pods y VMs. Por lo tanto, no se permiten los backends mixtos que involucran pods y VMs en un recurso BackendService.

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

    ¿Qué sigue?

  • Configura balanceadores de cargas internos

  • Configura balanceadores de cargas externos