Descripción general de grupos de extremos de red por zonas

Un grupo de extremos de red (NEG) es un objeto de configuración que especifica un grupo de extremos o servicios de backend. Los NEG zonales son recursos zonales que representan conjuntos de direcciones IP o combinaciones de direcciones IP y puertos para recursos de Google Cloud dentro de una subred única.

Los NEG son útiles porque te permiten crear agrupaciones lógicas de direcciones IP y puertos que representan servicios de software, en lugar de VM completas. Las direcciones IP para microservicios (que se ejecutan en las VM de Google Cloud) administradas por otros organizadores como Apache Mesos o Cloud Foundry pueden ser extremos.

Para obtener información sobre otros tipos de NEG, consulta lo siguiente:

Existen dos tipos de NEG zonales, que se clasifican según el tipo de extremos de red que conforman el NEG. Los dos tipos de NEG zonales admiten diferentes casos de uso y tipos de balanceadores de cargas.

NEG con extremos GCE_VM_IP

Los balanceadores de cargas de red de transferencia admiten NEG zonales con extremos GCE_VM_IP. Estos NEG zonales contienen uno o más extremos representados mediante la dirección IPv4 interna principal de la interfaz de red de una VM de Compute Engine.

Aunque Google Cloud usa una dirección IP para representar el extremo, el propósito de un extremo GCE_VM_IP es identificar la interfaz de red. La interfaz de red debe estar en la subred del NEG.

Debido a que un extremo GCE_VM_IP identifica una interfaz de red, no puedes especificar un puerto con un extremo GCE_VM_IP.

Estos tipos de extremos solo se pueden usar como backends en servicios de backend para balanceadores de cargas de red de transferencia internos y balanceadores de cargas de red de transferencia externos.

NEG con extremos GCE_VM_IP_PORT

Estos NEG zonales contienen una o más de las siguientes combinaciones de dirección IP o dirección IP y puerto de destino:

  • La dirección IPv4 interna principal de una interfaz de red de VM
  • La dirección IPv4 interna principal de una interfaz de red de VM más un número de puerto de destino
  • Una dirección IPv4 interna del rango de direcciones IP de alias asignado a una interfaz de red de VM
  • Una dirección IPv4 interna del rango de direcciones IP de alias asignado a una interfaz de red de VM más un número de puerto de destino

La interfaz de red que contiene el extremo GCE_VM_IP_PORT debe estar en la subred del NEG. Cuando omites un número de puerto de un extremo GCE_VM_IP_PORT, Google Cloud usa el número de puerto predeterminado del NEG para el extremo.

Debido a que estos backends de NEG zonales te permiten especificar direcciones IP y puertos, puedes distribuir el tráfico de modo detallado entre aplicaciones o contenedores que se ejecutan dentro de las instancias de VM: balanceo de cargas nativo del contenedor. GKE usa extremos GCE_VM_IP_PORT para lo siguiente:

Puedes crear balanceadores de cargas autoadministrados que usen NEG zonales cuyos extremos GCE_VM_IP_PORT administren GKE. Para obtener más detalles, consulta Balanceo de cargas nativo del contenedor mediante NEG zonales independientes.

Los balanceadores de cargas de aplicaciones y los balanceadores de cargas de red de proxy admiten NEG zonales con extremos GCE_VM_IP_PORT.

Especificación de extremos

Cuando creas un NEG, debes seleccionar una zona, una red y una subred. Cada dirección IP de extremo debe estar en la misma subred que el NEG zonal.

Si la red que seleccionaste es una red de VPC de modo automático, puedes omitir la especificación de la subred. Sin embargo, una subred sigue estando asociada con el NEG zonal. Si especificas una red de modo automático, pero no especificas una subred cuando creas un NEG zonal, la subred que usa es la subred creada de manera automática en la región que contiene la zona que seleccionaste para el NEG zonal.

El tipo de NEG zonal se especifica cuando creas el NEG (ya sea GCE_VM_IP o GCE_VM_IP_PORT). Esto determina qué tipos de extremos admite el NEG.

NEG zonales de GCE_VM_IP_PORT

Lo siguiente debe ser verdadero para los NEG zonales de GCE_VM_IP_PORT:

  • Debes especificar el nombre para cada extremo de VM.

  • Cada VM de extremo debe estar en la misma zona que el NEG.

  • Cada extremo del NEG debe ser una combinación única de dirección IP y puerto. Una dirección IP de extremo única y una combinación de puertos pueden hacer referencia a más de un NEG.

  • Cada VM de extremo debe tener una interfaz de red (NIC) en la misma red de VPC que el NEG. Las direcciones IP de extremo deben estar asociadas a la misma subred especificada en el NEG.

  • Cada NEG admite la cantidad máxima de extremos por NEG. Los extremos se pueden distribuir entre esa cantidad máxima de VM únicas o pueden ubicarse todos en una sola VM.

Para los NEG de GCE_VM_IP_PORT, cuando agregas un extremo, puedes especificar una dirección IP y un puerto, solo una dirección IP, o bien ninguno de los dos:

  • Si especificas una dirección IP y un puerto, la dirección IP puede ser la dirección IP interna principal de la VM en la interfaz de red o un IP de alias en la interfaz de red. Tú eliges el puerto.

  • Si especificas solo una dirección IP, esta puede ser la dirección IP interna principal de la VM en la interfaz de red o una dirección IP de alias en la interfaz de red. El puerto usado es el puerto predeterminado del NEG.

  • Si omites ambos, Google Cloud selecciona la dirección IP interna principal de la NIC y usa el puerto predeterminado del NEG.

NEG zonales de GCE_VM_IP

Lo siguiente debe ser verdadero para los NEG zonales de GCE_VM_IP:

  • Debes especificar el nombre para cada extremo de VM.

  • Cada VM de extremo debe estar en la misma zona que el NEG.

  • Cada extremo de un NEG GCE_VM_IP debe ser una dirección IP única. Una dirección IP de extremo única puede hacer referencia a más de un NEG.

  • Cada NEG GCE_VM_IP siempre está asociado con una red y una subred. Cuando agregas un extremo, puedes elegir especificar una dirección IP o no. Si se especifica una dirección IP, se debe configurar como la dirección IP interna principal de la instancia de VM adjunta que coincide con la subred del NEG. La dirección IP interna principal de cualquier interfaz de red de una instancia de VM con varias NIC se puede agregar a un NEG, siempre que coincida con la subred de NEG.

  • Cada NEG admite la cantidad máxima de extremos por NEG. Los extremos deben distribuirse entre todas las VMs únicas. No se pueden ubicar varios extremos en una sola VM porque una VM no puede tener más de una interfaz de red asociada a la misma subred.

Balanceo de cargas con NEG zonales

Los NEG zonales se pueden usar como backends para servicios de backend en un balanceador de cargas. Cuando usas un NEG zonal como backend para un servicio de backend, todos los demás backends en ese servicio también deben ser NEG zonales del mismo tipo (todos GCE_VM_IP o GCE_VM_IP_PORT). No puedes usar grupos de instancias y NEG zonales como backends en el mismo servicio de backend.

Puedes agregar el mismo extremo de red a más de un NEG zonal. Puedes usar el mismo NEG zonal como backend para más de un servicio de backend.

Los NEG zonales de GCE_VM_IP_PORT pueden usar el modo de balanceo RATE o elmodo de balanceo CONNECTION, según el protocolo del servicio de backend. Los balanceadores de cargas admitidos requieren definir una capacidad objetivo.

Los NEG zonales de GCE_VM_IP deben usar el modo de balanceo CONNECTION. Además, los balanceadores de cargas de red de transferencia internos y los balanceadores de cargas de red de transferencia externos no admiten la configuración de capacidad de destino.

Balanceadores de cargas de red de transferencia

Los NEG zonales con extremos de GCE_VM_IP se pueden usar como backends para servicios de backend solo para balanceadores de cargas de red de transferencia internos y balanceadores de cargas de red de transferencia externos.

Consulta las siguientes secciones sobre los casos de uso principales de los NEG con extremos GCE_VM_IP.

Agrupación flexible de extremos

Al igual que los grupos de instancias, puedes usar el mismo NEG como un backend para varios balanceadores de cargas de red de transferencia. A diferencia de los grupos de instancias, un extremo de NEG puede ser miembro de varios NEG y cada uno de esos NEG se puede usar como backend para uno o más balanceadores de cargas de transferencia. En comparación con los grupos de instancias, no estás restringido por el hecho de que una instancia de VM solo puede ser parte de un único grupo de instancias.

En la siguiente figura, se muestra un ejemplo de arquitectura de un balanceador de cargas de red de transferencia interno con una VM compartida.

Balanceadores de cargas de red de transferencia internos con NEG zonales de "GCE_VM_IP".
Balanceadores de cargas de red de transferencia internos con NEG zonales superpuestos (haz clic para ampliar).

Interfaces que no son nic0 como extremos de backend

Los NEG zonales con extremos GCE_VM_IP permiten el balanceo de cargas en interfaces de red de VM que no son nic0. Esto puede ser útil cuando se integra en VMs de dispositivo de terceros que suelen reservar nic0 para las operaciones de administración. Con los NEG GCE_VM_IP, cualquier interfaz de red que no sea nic0 de la misma VM se puede conectar a un backend de NEG de un balanceador de cargas de red de transferencia.

Subdivisión de GKE

GKE usa NEG zonales de GCE_VM_IP y la subdivisión para mejorar la escalabilidad de los balanceadores de cargas de red de transferencia internos de la siguiente manera:

Sin la subdivisión, GKE crea un grupo de instancias no administrado por cada zona, compuesto por los nodos de clúster de todos los grupos de nodos en esa zona. Estos grupos de instancias zonales se usan como backends para uno o más servicios LoadBalancer internos (y para Ingress externos que no usan NEG).

Con la subdivisión, GKE crea GCE_VM_IP NEG zonales para cada servicio LoadBalancer interno. El mismo extremo puede ser miembro de más de un NEG zonal. A diferencia de los grupos de instancias, Google Cloud puede balancear las cargas en más NEG zonales que contienen el mismo extremo.

La subdivisión distribuye el tráfico de forma más eficiente a servicios LoadBalancer internos de clústeres con más de 250 nodos. Por ejemplo, un clúster de GKE de 300 nodos puede tener un servicio LoadBalancer interno con 25 nodos en un NEG porque hay 25 pods para entregar ese servicio. No todos los 300 nodos se deben agregar a un backend de grupo de instancias para este servicio.

Ten en cuenta que las cuotas para NEG, reglas de reenvío, servicios de backend y otros recursos de herramientas de redes de Google Cloud se siguen aplicando.

Para obtener más detalles, consulta Usa la subdivisión del balanceador de cargas de red de transferencia interno.

Balanceadores de cargas de aplicaciones y balanceadores de cargas de red de proxy

En las siguientes ilustraciones, se muestran componentes de configuración para balanceadores de cargas en los que los NEG zonales con extremos GCE_VM_IP_PORT son los backends:

Grupos de extremos de red zonales en el balanceo de cargas.
Grupos de extremos de red zonales en el balanceo de cargas (haz clic para ampliar)

Para obtener más información sobre los requisitos de la arquitectura de estos balanceadores de cargas, consulta los siguientes vínculos:

El caso de uso principal para los NEG zonales de GCE_VM_IP_PORT corresponde al balanceo de cargas nativo del contenedor, para que puedas distribuir el tráfico directamente a los contenedores que se ejecutan en las VMs, por ejemplo, direcciones IP de Pod en clústeres de GKE.

El balanceo de cargas nativo del contenedor permite que los balanceadores de cargas se orienten directamente a los Pods y que tomen decisiones de distribución de cargas a nivel de Pod en lugar de hacerlo a nivel de VM.

En el siguiente ejemplo, se demuestra cómo los balanceadores de cargas distribuyen el tráfico entre microservicios que se ejecutan en contenedores en tus VMs. Las VM están configuradas para usar rangos de alias de IP desde sus subredes, y esos rangos son las direcciones que usan los contenedores.

Grupos de extremos de red zonales de balanceo de cargas con contenedores.
Grupos de extremos de red zonales de balanceo de cargas con contenedores (haz clic para ampliar)

Hay dos formas de configurar el balanceo de cargas nativo del contenedor: usar NEG administrados por Ingress de GKE o usar NEG independientes.

  • Ingress de Kubernetes con NEG (recomendado)

    Cuando los NEG se usan con Ingress, el controlador de Ingress facilita la creación de todos los aspectos de un balanceador de cargas HTTP(S). Esto incluye la creación de la dirección IP virtual, las reglas de reenvío, las verificaciones de estado, las reglas de firewall y mucho más. Si quieres aprender a configurar esto, consulta Balanceo de cargas nativo del contenedor mediante Ingress.

    Ingress es la forma recomendada de usar los NEG para el balanceo de cargas nativo del contenedor, ya que tiene muchas características que simplifican la administración de los NEG. Como alternativa, puedes crear un balanceador de cargas de proxy de forma manual, pero aún puedes hacer que GKE administre la membresía del extremo de NEG, como se describe en el siguiente punto (NEG independientes).

    Si deseas obtener instrucciones para configurar un balanceador de cargas a través de Ingress, consulta Balanceo de cargas nativo del contenedor mediante Ingress.

  • NEG independientes

    Los NEG independientes proporcionan una forma para que tu clúster de GKE cree NEG zonales con extremos GCE_VM_IP_PORT que representen direcciones IP de los Pods y puertos de contenedores, mientras te da la flexibilidad de configurar los componentes del balanceador de cargas fuera de GKE.

    Si deseas ver ejemplos sobre el uso de NEG zonales independientes con GKE, consulta los siguientes vínculos:

Limitaciones

  • No puedes usar NEG zonales con redes heredadas.
  • Un servicio de backend que usa NEG como backends no puede usar grupos de instancias como backends.

Limitaciones para NEG zonales de GCE_VM_IP:

  • Los NEG zonales con extremos GCE_VM_IP solo son compatibles con balanceadores de cargas de red de transferencia internos y balanceadores de cargas de red de transferencia externos.
  • La propiedad default-port no es compatible con NEG zonales de GCE_VM_IP.

Cuotas

¿Qué sigue?