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. Cada uno de ellos es compatible con diferentes casos de uso y tipos de balanceadores de cargas.

No puedes usar NEG zonal como backend con el balanceo de cargas de red.

NEG de GCE_VM_IP

Estos NEG zonales contienen uno o más extremos de red internos que se resuelven en una dirección IP principal de una VM de Compute Engine. No puedes especificar un puerto con este tipo de NEG zonal.

Estos extremos solo se pueden usar como backends en servicios de backend para balanceadores de cargas TCP/UDP internos.

Con los NEG GCE_VM_IP, solo puedes adjuntar extremos que pertenezcan a la dirección IP interna principal de una VM en la red de VPC de NEG. Las direcciones IP internas principales de cualquier NIC de una VM con varias NIC se pueden agregar a un NEG, siempre que el NEG use la misma red de VPC que el NIC.

NEG de GCE_VM_IP_PORT

Estos NEG zonales contienen uno o más extremos de red internos que se resuelven en una dirección IP interna principal de una VM o una dirección IP en uno de sus rangos de IP de alias. Por ejemplo, GKE usa NEG de este tipo, cuyos extremos son una dirección IP del rango de IP de alias del nodo más un puerto: una dirección IP de pod y un puerto de contenedor. Cada extremo de red se especifica mediante una combinación de dirección IP y un puerto.

Estos NEG se pueden usar como backends en servicios de backend para el balanceo de cargas HTTP(S) externo, HTTP(S) interno y balanceadores de cargas de proxy TCP y de proxy SSL. No puedes usar extremos GCE_VM_IP_PORT con balanceadores de cargas TCP/UDP internos ni balanceadores de cargas de red. 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.

Si quieres crear un extremo de red GCE_VM_IP_PORT único para un contenedor o una aplicación en ejecución en una VM, debes usar la dirección IP principal de la VM o una IP secundaria asignada a la VM mediante la característica de alias de dirección IP. El software en ejecución en el contenedor o la aplicación en ejecución en la VM debe configurarse para vincularse a la dirección IP que usa el extremo de red.

Los NEG de GCE_VM_IP_PORTson útiles, en especial, para GKE. Si quieres obtener más información sobre el uso de NEG zonales con GKE, consulta Usa el balanceo de cargas nativo de contenedores.

Relaciones entre los 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 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.

Para los NEG zonales GCE_VM_IP y 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, esta puede ser la dirección IP interna principal de la NIC de la VM o una IP de alias de la NIC. Tú eliges el puerto.

  • Si especificas solo una dirección IP, esta puede ser la dirección IP interna principal de la NIC de la VM o una IP de alias de la NIC. 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.

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 y no puedes definir una capacidad objetivo porque los balanceadores de cargas TCP/UDP internos no admiten esa configuración.

No puedes usar un modo de balanceo de UTILIZATION para backends de NEG zonales.

Balanceo de cargas TCP/UDP interno

Los NEG zonales con extremos de GCE_VM_IP se pueden usar como backends para servicios de backend solo para balanceadores de cargas TCP/UDP internos.

Los casos prácticos principales para los NEG con extremos de GCE_VM_IP son los siguientes:

Administración de VM simplificada para balanceadores de cargas TCP/UDP internos

Al igual que los grupos de instancias, puedes usar el mismo NEG como un backend para varios balanceadores de cargas TCP/UDP internos. A diferencia de los grupos de instancias, un extremo de VM 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 TCP/UDP internos.

Balanceadores de cargas TCP/UDP internos con NEG zonales de "GCE_VM_IP"
Balanceadores de cargas TCP/UDP internos con NEG zonales superpuestos

Subdivisión de GKE

GKE usa NEG zonales de GCP_VM_IP y la subdivisión para mejorar la escalabilidad de los balanceadores de cargas TCP/UDP 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.

Balanceo de cargas de HTTP(S) externo, HTTP(S) interno, proxy TCP y proxy SSL

Los NEG zonales con extremos GCE_VM_IP_PORT se pueden usar como backends para servicios de backend en los siguientes tipos de balanceadores de cargas: HTTP(S) interno, HTTP(S) interno, proxy TCP y balanceo de cargas de proxy SSL.

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 VM, por ejemplo, direcciones IP de pod en clústeres de GKE.

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 VM. 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 (haz clic para ampliar)
Grupos de extremos de red zonales de balanceo de cargas con contenedores (haz clic para ampliar)

En las siguientes ilustraciones, se muestran componentes de configuración para balanceadores de cargas de HTTP(S), de proxy TCP/SSL y de HTTP(S) interno en los que los NEG zonales son los backends:

  • En cada nivel Premium, el balanceador de cargas de HTTP(S), proxy SSL y proxy TCP tienen su propia regla de reenvío externo global para dirigir el tráfico al objeto de proxy de destino adecuado.

  • En cada nivel Estándar, el balanceador de cargas de HTTP(S), proxy SSL y proxy TCP tienen su propia regla de reenvío externo regional para dirigir el tráfico al objeto de proxy de destino adecuado.

  • Cada balanceador de cargas de HTTP(S) interno tiene su propia regla regional de reenvío administrado interno para dirigir el tráfico al objeto de proxy de destino adecuado.

  • Para los proxies HTTP(S) de destino, el servicio de backend que se usa se determina mediante la verificación del nombre del host de la solicitud y la ruta de acceso en el mapa de URL. Los balanceadores de cargas HTTP(S) internos y externos pueden tener varios servicios de backend a los que se hace referencia desde el mapa de URL.

  • Para los proxies TCP o SSL de destino, solo se puede definir un servicio de backend.

  • El servicio de backend dirige el tráfico a sus NEG zonales de backend. Para cada solicitud, el balanceador de cargas elige un extremo de red de uno de los NEG zonales y envía el tráfico allí.

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

Caso de uso: balanceo de cargas nativo del contenedor

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. 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 del balanceador de cargas L7. 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. Se pueden usar NEG independientes si los NEG administrados por Ingress no funcionan para tu caso de uso.

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

Cuando los NEG zonales se implementan con balanceadores de cargas y no es Ingress de GKE el que los aprovisiona, se consideran NEG independientes. Los NEG zonales independientes se implementan y administran a través del controlador de NEG, mientras que las reglas de reenvío, las verificaciones de estado y otros componentes del balanceo de cargas se implementan de forma manual.

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 TCP/UDP internos.
  • La propiedad default-port no es compatible con NEG zonales de GCE_VM_IP.
  • No puedes usar Cloud Console para crear o administrar NEG de GCE_VM_IP. Usa gcloud o la API de REST.

Cuotas

Soluciona problemas

El tráfico no llega a los extremos

Una vez que se configura el servicio, por lo general, se puede acceder a los extremos nuevos después de adjuntarlos al NEG zonal, siempre que respondan a las verificaciones de estado.

Si el tráfico no puede llegar a los extremos, y se genera un código de error 502 para HTTP(s) o conexiones rechazadas de balanceadores de cargas de TCP/SSL, verifica lo siguiente:

  • Verifica que las reglas de firewall permitan el tráfico de TCP entrante a los extremos de los siguientes rangos: 130.211.0.0/22 y 35.191.0.0/16.
  • Verifica que los extremos estén en buen estado mediante gcloud, como se muestra a continuación, o llama a la API de getHealth en el recurso de servicio de backend o a la API de listEndpoints en el NEG zonal con el parámetro showHealth establecido en SHOW. El siguiente comando de gcloud muestra información de estado por extremo de red:
gcloud compute network-endpoint-groups list-network-endpoints NAME \
    --zone=ZONE

¿Qué sigue?