Acerca de la compatibilidad con varias redes para Pods


En esta página, se describe la compatibilidad con varias redes para Pods, incluidos los casos de uso, los conceptos relevantes, la terminología y los beneficios.

Descripción general

Google Cloud admite interfaces de red múltiples a nivel de instancia de máquina virtual (VM). Puedes conectar una VM a hasta 8 redes con varias interfaces de red, incluida la red predeterminada, además de 7 redes adicionales.

Las herramientas de redes de Google Kubernetes Engine (GKE) extienden las capacidades de varias redes a los Pods que se ejecutan en los nodos. Con la compatibilidad de varias redes para Pods, puedes habilitar varias interfaces en nodos y Pods en un clúster de GKE. La compatibilidad de varias redes para Pods quita la limitación de interfaz única para los grupos de nodos, lo que limitó los nodos a una sola VPC para las herramientas de redes.

El optimizador de funciones de red (NFO) es un servicio de red disponible para GKE que proporciona compatibilidad con varias redes y un plano de datos nativo de Kubernetes de alto rendimiento. NFO habilita las funciones de red en contenedores en GKE. Las múltiples redes son uno de los pilares fundamentales del NFO.

Si deseas usar la compatibilidad con varias redes en tus Pods y nodos, consulta Configura la compatibilidad con varias redes para Pods.

Terminología y conceptos

En esta página, se usan los siguientes conceptos:

VPC principal: La VPC principal es una VPC preconfigurada que viene con un conjunto de configuraciones y recursos predeterminados. El clúster de GKE se crea en esta VPC. Si borras la VPC preconfigurada, el clúster de GKE se crea en la VPC principal.

Subred: En Google Cloud, una subred es la forma de crear enrutamiento entre dominios sin clases (CIDR) con máscaras de red en una VPC. Una subred tiene un solo rango de direcciones IP principal que se asigna a los nodos y puede tener varios rangos secundarios que pueden pertenecer a Pods y Services.

Red de nodo: la red de nodo se refiere a una combinación dedicada de un par de VPC y subred. Dentro de esta red de nodos, los nodos que pertenecen al grupo de nodos tienen direcciones IP asignadas del rango de direcciones IP principal.

Rango secundario: Un rango secundario de Google Cloud es un CIDR y una máscara de red que pertenecen a una subred. GKE lo usa como una red de Pods de capa 3. Un Pod puede conectarse a varias redes de Pods.

Red de Pods: Un objeto de red que funciona como un punto de conexión para Pods. La conexión puede ser del tipo Layer 3 o Device. Puedes configurar las redes de tipo Device en el modo netdevice o en el modo de kit de desarrollo del plano de datos (DPDK).

Las redes Layer 3 corresponden a un rango secundario en una subred. La red Device corresponde a una subred en una VPC. El modelo de datos para la red de Pods en la red múltiple de GKE es el siguiente:

  • Para la red Layer 3: VPC -> Nombre de subred -> Nombre del rango secundario

  • Para la red Device: VPC -> Nombre de la subred

Red de Pods predeterminada: Google Cloud crea una red de Pods predeterminada durante la creación del clúster. La red de Pods predeterminada usa la VPC principal como la red de nodo. La red de Pods predeterminada está disponible en todos los nodos y Pods de clúster de forma predeterminada.

Pods con interfaces múltiples: Varias interfaces en los Pods no pueden conectarse a la misma red de Pods.

En el siguiente diagrama, se muestra una arquitectura de clúster de GKE típica con redes Layer 3:

clúster de varias redes

En el caso de las redes de tipo Device, que se pueden configurar en modo netdevice o DPDK, la vNIC de VM se administra como un recurso y se pasa al Pod. En este caso, la red de Pods se asigna directamente a la red de nodos. No se requieren rangos secundarios para las redes de tipo Device.

Redes de Pods y nodos

Casos de uso

La compatibilidad de varias redes para Pods aborda los siguientes casos de uso:

  • Implementa funciones de red en contenedores: Si ejecutas las funciones de red en contenedores, que tienen datos de plano de administración y datos independientes. Las redes múltiples para Pods aíslan las redes para los diferentes planos de usuario, el alto rendimiento o la latencia baja de interfaces específicas, o las arquitecturas multiusuario a nivel de red. Esto es necesario para el cumplimiento, el QoS y la seguridad.
  • Conectar VPC dentro de la misma organización y proyecto: deseas crear clústeres de GKE en una VPC y necesitas conectarte a servicios en otra VPC. Puedes usar la opción de nodos de varias NIC para la conectividad directa. Esto puede deberse a un modelo de concentrador y radio, en el que un servicio centralizado (registro, autenticación) opera dentro de una VPC de concentrador, y los radios requieren conectividad privada para acceder a él. Puedes usar la compatibilidad con varias redes para que los Pods conecten los Pods que se ejecutan en el clúster de GKE directamente a la VPC de concentrador.
  • Ejecuta aplicaciones DPDK con VFIO: Deseas ejecutar aplicaciones de DPDK que requieren acceso a NIC en el nodo a través del controlador VFIO. Puedes lograr la tasa de paquetes óptima si omites el kernel, Kubernetes y GKE Dataplane V2 por completo.
  • Habilita el acceso directo a vNIC que omite Kubernetes y GKE Dataplane V2: Ejecutas las funciones de red en contenedores que requieren acceso directo a la tarjeta de interfaz de red (NIC) en el nodo. Por ejemplo, las aplicaciones de computación de alto rendimiento (HPC) que desean omitir Kubernetes y GKE Dataplane V2 para lograr una latencia más baja. Algunas aplicaciones también desean acceder a la información de la topología de PCIe de la NIC para ubicarla con otros dispositivos, como GPU.

Ventajas

La compatibilidad de varias redes con Pods proporciona los siguientes beneficios:

  • Aislamiento del tráfico: La compatibilidad con varias redes de Pods te permite aislar el tráfico en un clúster de GKE. Puedes crear Pods con interfaces de red múltiples para separar el tráfico según la funcionalidad, como la administración y el plano de datos, dentro de los Pods que ejecutan funciones nativas de la nube (CNF) específicas.
  • Orientación doble: La orientación doble permite que un Pod tenga interfaces múltiples y enrute el tráfico a diferentes VPC, lo que permite que el Pod establezca conexiones con una VPC principal y una secundaria. Si una VPC experimenta problemas, la aplicación puede recurrir a la VPC secundaria.
  • Segmentación de red: Los Pods pueden conectarse a redes internas o externas según las necesidades de carga de trabajo. Según los requisitos específicos de tus cargas de trabajo, puedes elegir qué Pods o grupos de Pods se conectan a cada red. Por ejemplo, puedes usar una red interna para la comunicación este-oeste y una red externa para acceso a Internet. Esto te permite adaptar la conectividad de red de tus cargas de trabajo en función de sus necesidades específicas.
  • Rendimiento óptimo con DPDK: La compatibilidad con varias redes para Pods en GKE permite que las aplicaciones de DPDK se ejecuten en Pods de GKE, lo que proporciona un rendimiento de procesamiento de paquetes óptimo.
  • NIC de host disponible de forma directa en Pod: La compatibilidad de NIC en modo netdevice con varias redes pasa NIC de VM directamente al Pod, omite Kubernetes y GKE Dataplane V2. Esto puede lograr la menor latencia para la colaboración entre dispositivos.
  • Rendimiento: A fin de mejorar el rendimiento de las aplicaciones, puedes conectar las aplicaciones a la red que se adapte mejor a las necesidades de las aplicaciones.

¿Qué sigue?