Gestionar balanceadores de carga

El dispositivo air-gapped de Google Distributed Cloud (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:

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.

Si usas el servicio de Kubernetes directamente, debes usar el objeto Service en lugar de los componentes que se han indicado 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.

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 tendrá menos direcciones VIP de ELB disponibles.

Siguientes pasos