Descripción general de los grupos de extremos de red zonales

Puedes usar grupos de extremos de red (NEG) zonales como backend para un servicio de backend. El caso práctico principal para esta configuración es implementar contenedores en las VM a fin de que puedas ejecutar servicios en contenedores. También puedes distribuir tráfico de modo detallado a las aplicaciones que se ejecutan en las VM.

En este documento, se analiza el uso de grupos de extremos de red zonales con los siguientes tipos de balanceadores de cargas:

No puedes usar NEG por zonas como backend con los siguientes tipos de balanceadores de cargas:

Para obtener información sobre los NEG de Internet, consulta Descripción general de los grupos de extremos de red de Internet.

Para obtener información sobre los NEG sin servidores, consulta Descripción general de los grupos de extremos de red sin servidores.

Descripción general

Los grupos de extremos de red (NEG) por zonas son recursos zonales que representan grupos de direcciones IP y combinaciones de puertos para recursos de Google Cloud dentro de una única subred. Cada combinación de dirección IP y puerto se denomina extremo de red.

Los grupos de extremos de red zonales se pueden usar como backends en servicios de backend para el balanceo de cargas de HTTP(S), HTTP(S) interno, proxy TCP y proxy SSL. No puedes usar NEG zonales como backend con balanceadores de cargas de TCP/UDP internos. Debido a que los 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.

Relaciones entre los extremos

Cuando creas un grupo de extremos de red, 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.

En la actualidad, los grupos de extremos de red solo admiten el tipo GCE_VM_IP_PORT. Esto significa que los extremos individuales deben tener direcciones IP asociadas con las VM de Google Cloud. Cuando agregas extremos a un NEG zonal, debes cumplir con las siguientes condiciones:

  • Debes especificar el nombre de una instancia de VM. La instancia de VM debe estar en la misma zona que el NEG zonal, y su interfaz de red en la red de VPC debe estar en una subred en la misma región que contiene esa zona.

  • Puedes tener hasta 10,000 extremos en un NEG zonal. Los 10,000 extremos pueden estar en la misma VM. Cada extremo se crea mediante una referencia a la VM cuando agregas un extremo a un NEG zonal existente. Los extremos creados en diferentes NEG zonales pueden apuntar a la misma VM.

    • Puedes especificar una dirección IP o una combinación de dirección IP y puerto, además de especificar la instancia de VM. Cualquier dirección IP que especifiques debe ser la dirección IP interna principal de la VM o un alias de IP para la VM en la misma subred que el NEG zonal.

    • Si no especificas una dirección IP cuando agregas un extremo, se usa la dirección IP interna principal de la VM en la red de VPC.

    • Si no especificas un puerto cuando agregas un extremo, debes haber definido un puerto predeterminado para el NEG zonal. Los extremos usan el puerto predeterminado, a menos que especifiquen un puerto propio. Esto significa que debes especificar un puerto predeterminado cuando creas un NEG zonal o debes especificar un puerto para cada extremo que le agregues.

    • Cada extremo de un NEG zonal debe ser una combinación única de una dirección IP y un puerto. Si no se especifica un puerto para una dirección IP, la combinación se crea mediante la IP y el puerto predeterminado.

Extremos, contenedores y servicios

Si quieres crear un extremo de red ú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 que se ejecuta en el contenedor o la aplicación que se ejecuta en la VM deben configurarse para vincularse a la dirección IP que usa el extremo de red.

Los NEG son ú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.

Los NEG también 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.

Balanceo de cargas

Los NEG zonales se pueden usar como backends para servicios de backend en los siguientes tipos de balanceadores de cargas:

  • Un balanceador de cargas de HTTP(S) externo
  • Un balanceador de cargas de HTTP(S) interno
  • Un balanceador de cargas del proxy SSL
  • Un balanceador de cargas del proxy TCP

El caso de uso principal para los NEG zonales es el balanceo de cargas nativo del contenedor, de modo que puedas distribuir el tráfico entre los microservicios que se ejecutan en contenedores en tus 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 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)

Servicios de backend

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. No puedes usar grupos de instancias y NEG zonales como backends en el mismo servicio de backend.

Puedes agregar el mismo extremo de red (combinación de dirección IP y puerto) a más de un NEG zonal. Puedes usar el mismo NEG zonal como backend para más de un servicio de backend.

Los servicios de backend que usan NEG zonales para backends solo pueden usar modos de balanceo de RATE o CONNECTION. No se puede usar un modo de balanceo de UTILIZATION para los servicios de backend que usan NEG zonales como backends.

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

Puedes usar los grupos de extremos de red zonales en los balanceadores de cargas con los niveles de servicio de red Estándar o Premium.

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)

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.

En la siguiente lista, se describe el proceso de alto nivel necesario para configurar el balanceo de cargas con NEG independientes:

  1. Configura contenedores o servicios en las VM. Si varios contenedores se deben ejecutar en cada VM o si necesitas direcciones IP para los contenedores, configura los alias de direcciones IP de las VM. Si configuras servicios, necesitas que se ejecuten dos o más servicios en la misma VM de modo que, al menos, los números de puerto sean diferentes.
  2. Crea grupos de extremos de red zonales.
  3. Agrega extremos de red a los grupos de extremos de red zonales.
  4. Crea una verificación de estado.
  5. Crea un servicio de backend.
  6. Para el balanceo de cargas de HTTP(S), debes crear un mapa de URL y conectar el servicio de backend a él.
  7. Crea el tipo adecuado de proxy de destino, como un proxy HTTP de destino, un proxy HTTPS de destino, un proxy SSL de destino o un proxy TCP de destino. Vincula el proxy de destino al mapa de URL (para el balanceo de cargas de HTTP[S]) o al servicio de backend (para el balanceo de cargas de proxy TCP y proxy SSL).
  8. Crea una regla de reenvío y vincúlala al proxy de destino.

Para vincular un balanceador de cargas a los NEG independientes zonales, consulta los siguientes vínculos:

Restricciones

  • No puedes usar NEG zonales con redes heredadas.
  • La dirección IP para un extremo de red debe ser una IP principal o de alias que pertenezca a la instancia de VM especificada.

Límites

  • Los NEG zonales solo se pueden usar como backends para balanceadores de cargas. Los siguientes tipos de balanceadores de cargas son compatibles con los NEG zonales: de HTTP(S) externo, de HTTP(S) interno, de proxy TCP y proxy SSL.
  • Solo el modo de balanceo RATE es compatible con los NEG zonales para el balanceo de cargas de HTTP(S), mientras que CONNECTION es compatible con el balanceo de cargas de TCP/SSL. El balanceo de cargas en función del uso no es compatible.
  • Un servicio de backend que usa NEG como backends no puede usar grupos de instancias como backends.
  • En este momento, solo se pueden agregar direcciones IP internas (RFC 1918) a un NEG zonal.
  • Para obtener información sobre las cuotas de NEG, como los NEG por proyecto, los NEG por servicio de backend y los extremos por NEG, consulta la página de cuotas del balanceo de cargas.

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

Próximos pasos