Compara modelos de redes en GKE

En este documento, se describe el modelo de red que usa Google Kubernetes Engine (GKE) y cómo puede diferir de los modelos de redes en otros entornos de Kubernetes. En este documento, se abordan los siguientes conceptos:

  • Los modelos de red más comunes que usan varias implementaciones de Kubernetes
  • Los mecanismos de direccionamiento IP de los modelos de red más comunes
  • Las ventajas y desventajas que ofrece cada modelo de red
  • Una descripción detallada del modelo de red predeterminado que usa GKE

El documento está dirigido a ingenieros de redes, ingenieros de operaciones y arquitectos de la nube que pueden estar familiarizados con otras implementaciones de Kubernetes y planean usar GKE. En este documento, se supone que estás familiarizado con Kubernetes y su modelo de red básico. También debes estar familiarizado con conceptos de herramientas de redes, como el direccionamiento IP, la traducción de direcciones de red (NAT), los firewalls y los proxies.

En este documento, no se explica cómo modificar el modelo de red de GKE predeterminado para cumplir con varias restricciones de direcciones IP. Si tienes escasez de direcciones IP cuando migras a GKE, consulta Estrategias de administración de direcciones IP cuando se migran a GKE.

Implementaciones típicas de modelos de red

Puedes implementar el modelo de red de Kubernetes de varias maneras. Sin embargo, cualquier implementación siempre debe cumplir con los siguientes requisitos:

  • Cada Pod necesita una dirección IP única.
  • Los Pods pueden comunicarse con otros Pods en todos los nodos sin usar NAT.
  • Los agentes de un nodo, como kubelet, pueden comunicarse con todos los Pods de ese nodo.
  • Los Pods en la red host de un nodo pueden comunicarse con todos los Pods en todos los nodos sin usar NAT.

Se desarrollaron más de 20 implementaciones diferentes para el modelo de red de Kubernetes que cumplen con estos requisitos.

Esta implementación se puede agrupar en tres tipos de modelos de red. Estos tres modelos difieren de las siguientes maneras:

  • Cómo los Pods pueden comunicarse con servicios que no son de Kubernetes en la red corporativa.
  • Cómo los Pods pueden comunicarse con otros clústeres de Kubernetes en la misma organización.
  • Si se requiere NAT para la comunicación fuera del clúster
  • Si las direcciones IP de Pod se pueden volver a usar en otros clústeres o en cualquier otro lugar de la red empresarial

Cada nube comprobada implementó uno o más de estos tipos de modelos.

En la siguiente tabla, se identifican los tres tipos de modelos que se usan con frecuencia y en qué implementación de Kubernetes se usan:

Nombre del modelo de red Se usa en estas implementaciones
Completamente integrado o plano
Modo de isla o conectado
Aislado
  • Las implementaciones de Kubernetes no lo usan con frecuencia, pero se puede usar con cualquier implementación cuando el clúster se implementa en una nube privada virtual (VPC) o red independiente.

Cuando en este documento se describen estos modelos de red, se hace referencia a sus efectos en las redes locales conectadas. Sin embargo, puedes aplicar los conceptos descritos para las redes locales conectadas a las redes conectadas a través de una red privada virtual (VPN) o una interconexión privada, incluidas las conexiones a otros proveedores de servicios en la nube. Para GKE, estas conexiones incluyen toda la conectividad a través de Cloud VPN o Cloud Interconnect.

Modelo de red completamente integrado

El modelo de red completamente integrado (o plano) ofrece facilidad para comunicarse con aplicaciones fuera de Kubernetes y en otros clústeres de Kubernetes. Los principales proveedores de servicios en la nube suelen implementar este modelo porque pueden integrar de forma estrecha su implementación de Kubernetes con su red definida por software (SDN).

Cuando usas el modelo completamente integrado, las direcciones IP que usas para los Pods se enrutan dentro de la red en la que se encuentra el clúster de Kubernetes. Además, la red subyacente sabe en qué nodo se encuentran las direcciones IP de Pod. En muchas implementaciones, las direcciones IP de Pod en el mismo nodo pertenecen a un rango de direcciones IP de Pod específico asignado de forma previa. Sin embargo, este rango de direcciones asignado previamente no es un requisito.

En el siguiente diagrama, se muestran las opciones de comunicación del Pod en el modelo de herramientas de redes completamente integrado:

Diagrama de red que muestra los patrones de comunicación en el modelo de red completamente integrado.

En el diagrama anterior de un modelo de red completamente integrado, se muestran los siguientes patrones de comunicación:

  • Los Pods dentro de un clúster de Kubernetes pueden comunicarse directamente entre sí.
  • Los Pods pueden comunicarse con otros Pods en otros clústeres, siempre que esos clústeres estén dentro de la misma red.
  • Los Pods no necesitan NAT para comunicarse con otras aplicaciones fuera del clúster, sin importar si esas aplicaciones están en la misma red o en redes interconectadas.

En el diagrama, también se muestra que los rangos de direcciones IP de Pod son distintos entre los diferentes clústeres.

El modelo de red completamente integrado está disponible en las siguientes implementaciones:

  • De forma predeterminada, GKE implementa este modelo. Para obtener más información sobre esta implementación, consulta Modelo de red de GKE más adelante en este documento.
  • De forma predeterminada, Amazon EKS implementa este modelo. En esta implementación, Amazon EKS usa el complemento de la interfaz de red de contenedor (CNI) de Amazon VPC para Kubernetes a fin de asignar direcciones IP de Pod directamente desde el espacio de direcciones de VPC. El complemento de CNI asigna direcciones IP desde la subred predeterminada en la que se encuentran los nodos o desde una subred personalizada. Las direcciones IP del Pod no provienen de un rango de direcciones IP del Pod exclusivo por nodo.
  • En Azure, AKS implementa este modelo cuando se usa Azure CNI (herramientas de redes avanzadas). Esta implementación no es la configuración predeterminada. En esta implementación, cada Pod obtiene una dirección IP de la subred. También puedes configurar la cantidad máxima de Pods por nodo. Por lo tanto, la cantidad de direcciones IP reservadas por adelantado para los Pods en ese nodo es la misma que la cantidad máxima de Pods por nodo.

El uso de un modelo de red completamente integrado ofrece las siguientes ventajas:

  • Mejor datos de telemetría. Las direcciones IP de Pod son visibles en toda la red. Esta visibilidad hace que los datos de telemetría sean más útiles que en otros modelos porque los Pods se pueden identificar incluso a partir de datos de telemetría que se recopilan fuera del clúster.
  • Configuración de firewall más sencilla. Cuando se configuran las reglas de firewall, diferenciar el tráfico de nodos y Pods es más fácil en el modelo de red completamente integrado que en los otros modelos.
  • Mejor compatibilidad. Los Pods pueden comunicarse mediante protocolos que no son compatibles con NAT.
  • Mejor depuración. Si el firewall lo permite, los recursos fuera del clúster pueden llegar a los Pods directamente durante el proceso de depuración.
  • Compatibilidad con mallas de servicios. Las mallas de servicios, como Istio o Cloud Service Mesh, pueden comunicarse con facilidad entre clústeres porque los Pods pueden comunicarse directamente. entre sí. Algunas implementaciones de malla de servicios solo admiten la conectividad de Pod a Pod para mallas de servicios de varios clústeres.

Usar un modelo de red completamente integrado tiene las siguientes desventajas:

  • Uso de direcciones IP. No puedes volver a usar las direcciones IP de Pod dentro de la red, y cada dirección IP debe ser única. Estos requisitos pueden generar una gran cantidad de direcciones IP que deben reservarse para los Pods.
  • Requisitos de SDN. Un modelo de red completamente integrado requiere una integración profunda con la red subyacente, ya que la implementación de Kubernetes necesita programar la SDN directamente. La programación de la SDN es transparente para el usuario y no produce ninguna desventaja para este. Sin embargo, estos modelos de red profundamente integrados no pueden implementarse fácilmente en entornos locales autoadministrados.

Modelo de red de modo isla

El modelo de red en modo de isla (o conectado) se usa por lo general para las implementaciones locales de Kubernetes en las que no es posible una integración profunda con la red subyacente. Cuando usas un modelo de red de modo isla, los Pods en un clúster de Kubernetes pueden comunicarse con recursos fuera del clúster a través de algún tipo de puerta de enlace o proxy.

En el siguiente diagrama, se muestran las opciones de comunicación del Pod en un modelo de herramientas de redes de modo isla:

Diagrama de red que muestra los patrones de comunicación en el modelo de red de modo isla.

En el diagrama anterior de un modelo de red de modo isla, se muestra cómo los Pods dentro de un clúster de Kubernetes pueden comunicarse directamente entre sí. En el diagrama, también se muestra que los Pods en un clúster deben usar una puerta de enlace o un proxy cuando se comunican con aplicaciones fuera del clúster o Pods en otros clústeres. Si bien la comunicación entre un clúster y una aplicación externa requiere una única puerta de enlace, la comunicación de clúster a clúster requiere dos puertas de enlace. El tráfico entre dos clústeres pasa por una puerta de enlace cuando sale del primer clúster y por otra cuando ingresa al otro clúster.

Existen diferentes formas de implementar las puertas de enlace o los proxies en un modelo de red aislado. Las siguientes implementaciones son las dos puertas de enlace o los dos proxies más comunes:

  • Uso de los nodos como puertas de enlace. Esta implementación se usa comúnmente cuando los nodos del clúster son parte de la red existente y sus direcciones IP se pueden enrutar de forma nativa dentro de esta red. En este caso, los nodos son las puertas de enlace que proporcionan conectividad desde el interior del clúster a la red más grande. El tráfico de salida desde un Pod hacia el exterior del clúster puede dirigirse a otros clústeres o a aplicaciones que no sean de Kubernetes, por ejemplo, para llamar a una API local en la red corporativa. Para este tráfico de salida, el nodo que contiene el Pod usa NAT de origen (SNAT) para asignar la dirección IP del Pod a la dirección IP del nodo. Para permitir que las aplicaciones que están fuera del clúster se comuniquen con Services dentro del clúster, puedes usar el tipo de Service NodePort para la mayoría de las implementaciones. En algunas implementaciones, puedes usar el tipo de Service LoadBalancer para exponer los Services. Cuando usas el tipo de Service LoadBalancer, asignas a esos Services una dirección IP virtual con balanceo de cargas entre los nodos y que se enruta a un Pod que es parte del Service.

    En el siguiente diagrama, se muestra el patrón de implementación cuando se usan nodos como puertas de enlace:

    Diagrama de red que muestra los patrones de comunicación en el modelo de red de modo isla que usa nodos como puertas de enlace.

    En el diagrama anterior, se muestra que el uso de nodos como puertas de enlace no tiene un impacto en la comunicación de Pod a Pod dentro de un clúster. Los Pods de un clúster aún se comunican entre sí directamente. Sin embargo, en el diagrama también se muestran los siguientes patrones de comunicación fuera del clúster:

    • Cómo los Pods se comunican con otros clústeres o aplicaciones que no son de Kubernetes mediante SNAT cuando salen del nodo.
    • Cómo el tráfico externo a servicios en otros clústeres o aplicaciones que no son de Kubernetes ingresa al clúster a través de un servicio NodePort antes de reenviarse al Pod correcto en el clúster.

  • Uso de máquinas virtuales (VM) de proxy con interfaces de red múltiples. En este patrón de implementación, se usan proxies para acceder a la red que contiene el clúster de Kubernetes. Los proxies deben tener acceso al espacio de direcciones IP de Pod y nodo. En este patrón, cada VM de proxy tiene dos interfaces de red: una en la red empresarial más grande y otra en la red que contiene el clúster de Kubernetes.

    En el siguiente diagrama, se muestra el patrón de implementación cuando se usan VM del proxy:

    Diagrama de red que muestra los patrones de comunicación en el modelo de red de modo isla que usa VM de proxy.

    En el diagrama anterior, se muestra que el uso de proxies en modo isla no tiene un impacto en la comunicación dentro de un clúster. Los Pods de un clúster aún pueden comunicarse entre sí directamente. Sin embargo, en el diagrama también se muestra cómo la comunicación desde los Pods a otros clústeres o aplicaciones que no son de Kubernetes pasa a través de un proxy que tiene acceso a la red del clúster y a la red de destino. Además, la comunicación que ingresa al clúster desde el exterior también pasa por el mismo tipo de proxy.

El modelo de red de modo isla está disponible en las siguientes implementaciones:

  • De forma predeterminada, Azure Kubernetes Service (AKS) usa herramientas de redes en modo de isla cuando usa herramientas de redes de kubenet (básico). Cuando AKS usa herramientas de redes en modo isla, la red virtual que contiene el clúster solo incluye direcciones IP de nodo. Las direcciones IP de Pod no forman parte de la red virtual. En cambio, los Pods reciben direcciones IP de un espacio lógico diferente. El modelo de modo isla que usa AKS también enruta el tráfico de Pod a Pod entre nodos mediante el uso de rutas definidas por el usuario con el reenvío de IP activado en la interfaz de nodos. Para la comunicación de Pods a recursos fuera del clúster, el nodo usa SNAT a fin de asignar la dirección IP de Pod a la dirección IP de nodo antes de que el tráfico de salida salga del nodo.
  • En Oracle Container Engine for Kubernetes (OKE), la comunicación de Pod a Pod usa una red de superposición VXLAN. Además, el tráfico de Pods a aplicaciones fuera del clúster usa SNAT para asignar la dirección IP de Pod a la dirección IP de nodo.

El uso de un modelo de red de modo isla tiene las siguientes ventajas:

  • Uso de direcciones IP. Las direcciones IP de Pod en el clúster se pueden volver a usar en otros clústeres. Sin embargo, las direcciones IP que ya usan los servicios externos de la red empresarial no se pueden usar para Pods si la comunicación debe ocurrir entre los Pods y esos servicios. Por lo tanto, en el caso de las herramientas de redes en modo isla, se recomienda reservar un espacio de direcciones IP de Pod que sea único dentro de la red y usar este espacio de direcciones IP para todos los clústeres.
  • Configuración de seguridad más sencilla. Debido a que los Pods no están expuestos de forma directa al resto de la red empresarial, no es necesario proteger los Pods contra el tráfico de entrada del resto de la red empresarial.

Usar un modelo de red de modo isla tiene las siguientes desventajas:

  • Telemetría imprecisa. Los datos de telemetría recopilados fuera del clúster solo contienen la dirección IP de nodo, no la dirección IP de Pod. La falta de direcciones IP de Pod dificulta la identificación de la fuente y el destino del tráfico.
  • Depuración más difícil. Cuando realizas la depuración, no puedes conectarte directamente a los Pods desde fuera del clúster.
  • Configuración de firewalls más difícil. Solo puedes usar direcciones IP de nodo cuando configuras tu firewall. Por lo tanto, la configuración de firewall resultante permite que todos los Pods en un nodo y el nodo en sí lleguen a servicios externos o no permite que ninguno de ellos llegue a servicios externos.

  • Compatibilidad con mallas de servicios. Con el modo isla, la comunicación directa de Pod a Pod entre clústeres en mallas de servicios, como Istio o Cloud Service Mesh, no es posible.

    Existen otras restricciones con algunas implementaciones de malla de servicios. La compatibilidad de varios clústeres con Cloud Service Mesh para los clústeres de GKE en Google Cloud solo admite clústeres en la misma red. Para las implementaciones de Istio que admiten un modelo de varias redes, la comunicación debe ocurrir a través de puertas de enlace de Istio, que hace que las implementaciones de malla de servicios de varios clústeres sean más complejas.

Modelo de red aislado

El modelo de red aislado se usa con mayor frecuencia para clústeres que no necesitan acceso a la red corporativa más grande, excepto a través de las API públicas. Cuando se usa un modelo de red aislado, cada clúster de Kubernetes está aislado y no puede usar direcciones IP internas para comunicarse con el resto de la red. El clúster se encuentra en su propia red privada. Si algún Pod del clúster necesita comunicarse con servicios fuera del clúster, esta comunicación debe usar direcciones IP públicas para la entrada y la salida.

En el siguiente diagrama, se muestran las opciones de comunicación del Pod en un modelo de red aislado:

Diagrama de red que muestra los patrones de comunicación en el modelo de red aislado.

En el diagrama anterior de un modelo de red aislado, se muestra que los Pods dentro de un clúster de Kubernetes pueden comunicarse directamente entre sí. En el diagrama, también se muestra que los Pods no pueden usar direcciones IP internas para comunicarse con Pods en otros clústeres. Además, los Pods pueden comunicarse con aplicaciones fuera del clúster solo cuando se cumplen los siguientes criterios:

  • Existe una puerta de enlace de Internet que conecta el clúster con el exterior.
  • La aplicación externa usa una dirección IP externa para las comunicaciones.

Por último, en el diagrama se muestra cómo se puede volver a usar el mismo espacio de direcciones IP para Pods y nodos entre diferentes entornos.

Las implementaciones de Kubernetes no suelen usar el modelo de red aislado. Sin embargo, puedes lograr un modelo de red aislado en cualquier implementación. Solo necesitas implementar un clúster de Kubernetes en una VPC o red independiente sin conectividad a otros servicios o a la red empresarial. La implementación resultante tendría las mismas ventajas y desventajas que tiene el modelo de red aislado.

Usar un modo de red aislado presenta las siguientes ventajas:

  • Uso de direcciones IP. Puedes volver a usar todas las direcciones IP internas del clúster: direcciones IP de nodo, direcciones IP de Service y direcciones IP de Pod. La reutilización de direcciones IP internas es posible porque cada clúster tiene su propia red privada y la comunicación con los recursos fuera del clúster solo ocurre a través de direcciones IP públicas.
  • Control. Los administradores del clúster tienen control total sobre el direccionamiento IP del clúster y no tienen que realizar ninguna tarea de administración de direcciones IP. Por ejemplo, los administradores pueden asignar el espacio de direcciones 10.0.0.0/8 completo a los Pods y Services en el clúster, incluso si estas direcciones ya se usan en la organización.
  • Seguridad. La comunicación fuera del clúster se controla de forma estricta y, cuando se permite, usa NAT e interfaces externas bien definidas.

Usar un modelo de red aislado presenta las siguientes desventajas:

  • No hay comunicación privada. No se permite la comunicación mediante direcciones IP internas a otros clústeres ni a otros servicios de la red.

Modelo de red de GKE

GKE usa un modelo de red completamente integrado en el que los clústeres se implementan en una red de nube privada virtual (VPC) que también puede contener otras aplicaciones.

Recomendamos que uses un clúster nativo de la VPC para tu entorno de GKE. Puedes crear el clúster nativo de la VPC en Standard o Autopilot. Si eliges el modo Autopilot, el modo nativo de la VPC siempre está activado y no se puede desactivar. En los siguientes párrafos, se describe el modelo de red de GKE en modo Standard con notas sobre cómo difiere el modo Autopilot.

Administración de direcciones IP en clústeres nativos de la VPC

Cuando usas un clúster nativo de la VPC, las direcciones IP de Pod son direcciones IP secundarias en cada nodo. A cada nodo se le asigna una subred específica de un rango de direcciones IP del Pod que seleccionas del espacio de direcciones IP internas cuando creas el clúster. De forma predeterminada, un clúster nativo de la VPC asigna una subred /24 a cada nodo para usarla como direcciones IP de Pod. Una subred /24 corresponde a 256 direcciones IP. En Autopilot, el clúster usa una subred /26 que corresponde a 64 direcciones y no puedes cambiar este parámetro de configuración de subred.

El modelo de red de GKE no permite que las direcciones IP se vuelvan a usar en la red. Cuando migras a GKE, debes planificar la asignación de direcciones IP para Reducir el uso de direcciones IP internas en GKE.

Debido a que las direcciones IP del Pod se pueden enrutar dentro de la red de VPC, los Pods pueden recibir tráfico de los siguientes recursos de forma predeterminada:

Administra la comunicación de tráfico externo con el agente de enmascaramiento de IP

Cuando te comunicas desde los Pods a servicios fuera del clúster, el agente de enmascaramiento de IP rige cómo se muestra el tráfico a esos servicios. El agente de enmascaramiento de IP maneja las direcciones IP privadas y externas de manera diferente, como se describe en las siguientes viñetas:

  • De forma predeterminada, el agente de enmascaramiento de IP no enmascara el tráfico a las direcciones IP internas, incluidas las direcciones IP RFC 1918 y las direcciones IP que no son RFC 1918 que se usan con frecuencia de manera interna. (Para obtener más información, consulta la lista de destinos predeterminados sin enmascarar). Debido a que las direcciones IP internas no están enmascaradas, el nodo no usa NAT en esas direcciones.
  • En el caso de las direcciones IP externas, el agente de enmascaramiento de IP enmascara esas direcciones para la dirección IP de nodo. Por lo tanto, esas direcciones enmascaradas se traducen a una dirección IP externa con Cloud NAT o a la dirección IP externa de la instancia de máquina virtual (VM)..

También puedes usar direcciones IP públicas que se usan de forma privada (PUPI) dentro de tu red de VPC o redes conectadas. Si usas direcciones PUPI, igualmente puedes beneficiarte del modelo de red completamente integrado y ver la dirección IP de Pod de forma directa como fuente. Para lograr estos dos objetivos, debes incluir las direcciones PUPI en la lista nonMasqueradeCIDRs.

Información sobre el flujo de tráfico de Pods en una red de GKE

En el siguiente diagrama, se muestra cómo pueden comunicarse los Pods en el modelo de herramientas de redes de GKE:

Diagrama de red que muestra los patrones de comunicación en el modelo de red de GKE.

En el diagrama anterior, se muestra cómo los Pods en entornos de GKE pueden usar direcciones IP internas para comunicarse directamente con los siguientes recursos:

  • Otros Pods en el mismo clúster.
  • Pods en otros clústeres de GKE en la misma red de VPC.
  • Otras aplicaciones de Google Cloud en la misma red de VPC.
  • Aplicaciones locales conectadas a través de Cloud VPN.

En el diagrama, también se muestra lo que sucede cuando un Pod necesita usar una dirección IP externa para comunicarse con una aplicación. A medida que el tráfico sale del nodo, el nodo en el que reside el Pod usa SNAT para asignar la dirección IP del Pod a la dirección IP del nodo. Después de que el tráfico sale del nodo, Cloud NAT traduce la dirección IP del nodo a una dirección IP externa.

En cuanto a los beneficios descritos antes en este documento, en especial para el beneficio de tener direcciones IP de Pods visibles en todos los datos de telemetría, Google eligió un modelo de red completamente integrado. En GKE, las direcciones IP del Pod se exponen en Registros de flujo de VPC (incluidos los nombres de los Pods en los metadatos), Duplicación de paquetes, Registro de reglas de firewall y en tus propios registros de aplicación para destinos sin enmascarar.

¿Qué sigue?