Comparar modelos de red 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 red de otros entornos de Kubernetes. En este documento se tratan los siguientes conceptos:

  • Los modelos de red más habituales que utilizan varias implementaciones de Kubernetes.
  • Los mecanismos de direccionamiento IP de los modelos de red más comunes.
  • Las ventajas y desventajas de cada modelo de red.
  • Descripción detallada del modelo de red predeterminado que usa GKE.

Este documento está dirigido a arquitectos de la nube, ingenieros de operaciones e ingenieros de redes que conozcan otras implementaciones de Kubernetes y tengan previsto usar GKE. En este documento se da por supuesto que conoces Kubernetes y su modelo de red básico. También debes conocer conceptos de redes, como el direccionamiento IP, la traducción de direcciones de red (NAT), los cortafuegos y los proxies.

En este documento no se explica cómo modificar el modelo de red predeterminado de GKE para cumplir varias restricciones de direcciones IP. Si te faltan direcciones IP al migrar a GKE, consulta Estrategias de gestión de direcciones IP al migrar a GKE.

Implementaciones típicas de modelos de red

Puedes implementar el modelo de red de Kubernetes de varias formas. Sin embargo, cualquier implementación siempre debe cumplir 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 de la red de host de un nodo pueden comunicarse con todos los pods de todos los nodos sin usar NAT.

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

Estas implementaciones se pueden agrupar en tres tipos de modelos de red. Estos tres modelos se diferencian en los siguientes aspectos:

  • Cómo pueden comunicarse los pods con servicios que no son de Kubernetes en la red corporativa.
  • Cómo pueden comunicarse los pods con otros clústeres de Kubernetes de la misma organización.
  • Indica si se requiere NAT para la comunicación fuera del clúster.
  • Indica si las direcciones IP de los pods se pueden reutilizar en otros clústeres o en otras partes de la red de la empresa.

Cada proveedor de servicios en la nube ha implementado uno o varios de estos tipos de modelos.

En la siguiente tabla se identifican los tres tipos de modelos que se suelen usar y en qué implementación de Kubernetes se utilizan:

Nombre del modelo de red Se usa en estas implementaciones
Totalmente integrada o plana
Modo isla o conectado
Aislado o aislado físicamente
  • No se suele usar en las implementaciones de Kubernetes, pero se puede usar con cualquier implementación cuando el clúster se despliega en una red independiente o en una nube privada virtual (VPC).

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 on-premise conectadas a las redes que estén conectadas a través de una red privada virtual (VPN) o mediante una interconexión privada, incluidas las conexiones a otros proveedores de servicios en la nube. En el caso de GKE, estas conexiones incluyen toda la conectividad a través de Cloud VPN o Cloud Interconnect.

Modelo de red totalmente integrado

El modelo de red totalmente integrada (o plana) ofrece facilidad de comunicación 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 estrechamente su implementación de Kubernetes con su red definida por software (SDN).

Cuando usas el modelo totalmente integrado, las direcciones IP que usas para los pods se enrutan en 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 los pods. En muchas implementaciones, las direcciones IP de los pods del mismo nodo proceden de un intervalo de direcciones IP de pods específico y preasignado. Sin embargo, este intervalo de direcciones preasignado no es obligatorio.

En el siguiente diagrama se muestran las opciones de comunicación de los pods en el modelo de red totalmente integrado:

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

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

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

El diagrama también muestra que los intervalos de direcciones IP de los pods son distintos entre los diferentes clústeres.

Disponibilidad

El modelo de red totalmente 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 el modelo de redes 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 interfaz de red de contenedores (CNI) de Amazon VPC para Kubernetes con el fin de asignar direcciones IP de pods directamente desde el espacio de direcciones de VPC. El complemento CNI asigna direcciones IP de la subred predeterminada en la que se encuentran los nodos o de una subred personalizada. Las direcciones IP de los pods no proceden de un intervalo de direcciones IP de pods dedicado por nodo.
  • En Azure, AKS implementa este modelo cuando se usa Azure CNI (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 el número máximo de pods por nodo. Por lo tanto, el número de direcciones IP reservadas por adelantado para los pods de ese nodo es el mismo que el número máximo de pods por nodo.

Ventajas

Si utilizas un modelo de red totalmente integrado, disfrutarás de las siguientes ventajas:

  • Datos de telemetría más precisos. Las direcciones IP de los pods son visibles en toda la red. Esta visibilidad hace que los datos de telemetría sean más útiles que en otros modelos, ya que los pods se pueden identificar incluso a partir de datos de telemetría recogidos fuera del clúster.
  • Configuración del cortafuegos más sencilla. Al configurar reglas de cortafuegos, es más fácil diferenciar el tráfico de nodos y pods en el modelo de red totalmente integrado que en los demás modelos.
  • Mayor compatibilidad. Los pods pueden comunicarse mediante protocolos que no admiten NAT.
  • Mejor depuración. Si el cortafuegos lo permite, los recursos externos al clúster pueden acceder directamente a los pods durante el proceso de depuración.
  • Compatibilidad con mallas de servicios. Las mallas de servicios, como Istio o Cloud Service Mesh, pueden comunicarse fácilmente 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.

Desventajas

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

  • Uso de la dirección IP. No puedes reutilizar direcciones IP de pods en la red y cada dirección IP debe ser única. Estos requisitos pueden provocar que se deba reservar un gran número de direcciones IP para los pods.
  • Requisitos de SDN Un modelo de red totalmente integrado requiere una integración profunda con la red subyacente, ya que la implementación de Kubernetes debe programar la SDN directamente. La programación de la SDN es transparente para el usuario y no produce ningún inconveniente para el usuario. Sin embargo, estos modelos de red tan integrados no se pueden implementar fácilmente en entornos autogestionados y locales.

Modelo de red en modo aislado

El modelo de red en modo aislado (o puenteado) se suele usar en implementaciones de Kubernetes locales en las que no es posible una integración profunda con la red subyacente. Cuando usas un modelo de red en modo aislado, los pods de un clúster de Kubernetes pueden comunicarse con recursos externos al clúster a través de algún tipo de pasarela o proxy.

En el siguiente diagrama se muestran las opciones de comunicación de los pods en un modelo de red en modo aislado:

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

En el diagrama anterior del modelo de red en modo aislado se muestra cómo pueden comunicarse directamente entre sí los pods de un clúster de Kubernetes. El diagrama también muestra que los pods de un clúster deben usar una pasarela o un proxy cuando se comunican con aplicaciones fuera del clúster o con pods de otros clústeres. Aunque la comunicación entre un clúster y una aplicación externa requiere una sola pasarela, la comunicación entre clústeres requiere dos pasarelas. El tráfico entre dos clústeres pasa por una pasarela al salir del primer clúster y por otra al entrar en el segundo.

Hay diferentes formas de implementar las pasarelas o los proxies en un modelo de red aislada. Las siguientes implementaciones son las dos pasarelas o proxies más habituales:

  • Usar los nodos como pasarelas. Esta implementación se suele usar cuando los nodos del clúster forman parte de la red y sus direcciones IP se pueden enrutar de forma nativa en 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 de un pod hacia fuera del clúster se puede dirigir hacia otros clústeres o hacia aplicaciones que no sean de Kubernetes. Por ejemplo, se puede usar para llamar a una API local en la red corporativa. Para este tráfico de salida, el nodo que contiene el pod usa la 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 los servicios que están dentro, puedes usar el tipo de servicio NodePort en la mayoría de las implementaciones. En algunas implementaciones, puedes usar el tipo de servicio LoadBalancer para exponer servicios. Cuando se usa el tipo de servicio LoadBalancer, se asigna a esos servicios una dirección IP virtual que se balancea entre los nodos y se dirige a un pod que forma parte del servicio.

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

    Diagrama de red que muestra los patrones de comunicación en el modelo de red en modo aislado que usa nodos como pasarelas.

    El diagrama anterior muestra que el uso de nodos como pasarelas no afecta a la comunicación entre pods de un clúster. Los pods de un clúster siguen comunicándose entre sí directamente. Sin embargo, el diagrama también muestra los siguientes patrones de comunicación fuera del clúster:

    • Cómo se comunican los pods con otros clústeres o aplicaciones que no son de Kubernetes mediante SNAT al salir del nodo.
    • Cómo entra en el clúster el tráfico procedente de servicios externos de otros clústeres o de aplicaciones que no son de Kubernetes a través de un servicio NodePort antes de reenviarse al pod correcto del clúster.

  • Usar máquinas virtuales proxy con varias interfaces de red. Este patrón de implementación usa proxies para acceder a la red que contiene el clúster de Kubernetes. Los proxies deben tener acceso al espacio de direcciones IP de los pods y los nodos. En este patrón, cada VM 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 al usar VMs proxy:

    Diagrama de red que muestra los patrones de comunicación en el modelo de red en modo aislado que usa máquinas virtuales proxy.

    El diagrama anterior muestra que el uso de proxies en el modo aislado no afecta a la comunicación dentro de un clúster. Los pods de un clúster pueden seguir comunicándose entre sí directamente. Sin embargo, el diagrama también muestra cómo la comunicación de los pods a otros clústeres o aplicaciones que no son de Kubernetes pasa por un proxy que tiene acceso tanto a la red del clúster como a la red de destino. Además, la comunicación que entra en el clúster desde fuera también pasa por el mismo tipo de proxy.

Disponibilidad

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

  • De forma predeterminada, Azure Kubernetes Service (AKS) usa la red en modo isla cuando se usa la red de Kubenet (básica). Cuando AKS usa la red en modo aislado, la red virtual que contiene el clúster solo incluye direcciones IP de nodos. Las direcciones IP de los pods no forman parte de la red virtual. En su lugar, los pods reciben direcciones IP de un espacio lógico diferente. El modelo de modo aislado que usa AKS también dirige el tráfico de pod a pod entre nodos mediante rutas definidas por el usuario con el reenvío de IP activado en la interfaz de los nodos. Para que los pods se comuniquen con recursos fuera del clúster, el nodo usa SNAT para asignar la dirección IP del pod a la dirección IP del nodo antes de que el tráfico de salida abandone el nodo.
  • En Oracle Container Engine for Kubernetes (OKE), la comunicación entre pods usa una red superpuesta VXLAN. Además, el tráfico de los pods a las aplicaciones fuera del clúster usa SNAT para asignar la dirección IP del pod a la dirección IP del nodo.

Ventajas

Usar un modelo de red en modo aislado tiene las siguientes ventajas:

  • Uso de la dirección IP. Las direcciones IP de los pods del clúster se pueden reutilizar en otros clústeres. Sin embargo, los clústeres nativos de VPC predeterminados de GKE no admiten la reutilización de intervalos de direcciones IP de pods en clústeres de la misma red de VPC. En GKE, las direcciones IP de los pods se pueden enrutar directamente en tu red de VPC. Por lo tanto, las direcciones IP de los pods deben ser únicas en todos los clústeres y recursos de esa única VPC. Si necesitas reutilizar direcciones IP, implementa tus clústeres de GKE en redes de VPC independientes. Independientemente del modelo de red, los pods que necesiten comunicarse con servicios externos de tu red empresarial no pueden usar direcciones IP que ya utilicen esos servicios externos. En el caso de las redes en modo aislado, la práctica recomendada es reservar un espacio de direcciones IP de pods que sea único en tu red empresarial y usarlo en todos los clústeres que utilicen esta configuración.

  • Ajustes de seguridad más sencillos. Como los pods no están expuestos directamente al resto de la red de la empresa, no es necesario protegerlos contra el tráfico entrante del resto de la red de la empresa.

Desventajas

Usar un modelo de red en modo aislado tiene las siguientes desventajas:

  • Telemetría imprecisa. Los datos de telemetría recogidos fuera del clúster solo contienen la dirección IP del nodo, no la dirección IP del pod. La falta de direcciones IP de pods dificulta la identificación del origen y el destino del tráfico.
  • Más difícil de depurar. Cuando depuras, no puedes conectarte directamente a los pods desde fuera del clúster.
  • Es más difícil configurar cortafuegos. Solo puedes usar direcciones IP de nodos al configurar tu cortafuegos. Por lo tanto, la configuración del cortafuegos resultante permite que todos los pods de un nodo y el propio nodo accedan a servicios externos, o bien no permite que ninguno de ellos acceda a servicios externos.

  • Compatibilidad con mallas de servicios. En el modo aislado, no es posible la comunicación directa entre pods de diferentes clústeres en mallas de servicios, como Istio o Cloud Service Mesh.

    Hay más restricciones con algunas implementaciones de malla de servicios. La compatibilidad con varios clústeres de Cloud Service Mesh para clústeres de GKE enGoogle Cloud solo admite clústeres de la misma red. En las implementaciones de Istio que admiten un modelo de varias redes, la comunicación debe producirse a través de puertas de enlace de Istio, lo que hace que las implementaciones de malla de servicios multiclúster sean más complejas.

Modelo de red aislada

El modelo de red aislada (o con air gap) se usa con mayor frecuencia en clústeres que no necesitan acceder a la red corporativa más grande, excepto a través de APIs públicas. Si usas un modelo de red aislada, cada clúster de Kubernetes estará aislado y no podrá 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 que no están en el clúster, esta comunicación debe usar direcciones IP públicas tanto para la entrada como para la salida.

En el siguiente diagrama se muestran las opciones de comunicación de los pods en un modelo de red aislada:

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

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

  • Hay una pasarela 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, el diagrama muestra cómo se puede reutilizar el mismo espacio de direcciones IP para pods y nodos en diferentes entornos.

Disponibilidad

El modelo de red aislada no se suele usar en las implementaciones de Kubernetes. Sin embargo, puedes conseguir un modelo de red aislado en cualquier implementación. Solo tienes que desplegar un clúster de Kubernetes en una red o una VPC independientes sin conectividad a otros servicios ni a la red de la empresa. La implementación resultante tendría las mismas ventajas e inconvenientes que el modelo de red aislado.

Ventajas

Usar un modo de red aislado tiene las siguientes ventajas:

  • Uso de la dirección IP. Puedes reutilizar todas las direcciones IP internas del clúster: direcciones IP de nodos, direcciones IP de servicios y direcciones IP de pods. Es posible reutilizar las direcciones IP internas porque cada clúster tiene su propia red privada y la comunicación con los recursos fuera del clúster solo se produce 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 gestión de direcciones IP. Por ejemplo, los administradores pueden asignar todo el espacio de direcciones 10.0.0.0/8 a los pods y servicios del clúster, aunque estas direcciones ya se utilicen en la organización.
  • Seguridad. La comunicación fuera del clúster está estrictamente controlada y, cuando se permite, utiliza interfaces externas y NAT bien definidas.

Desventajas

Usar un modelo de red aislada tiene las siguientes desventajas:

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

Modelo de red de GKE

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

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

Información sobre la gestión de direcciones IP en clústeres nativos de VPC

Cuando usas un clúster nativo de VPC, las direcciones IP de los pods son direcciones IP secundarias de cada nodo. A cada nodo se le asigna una subred específica de un intervalo de direcciones IP de pods que seleccionas de tu espacio de direcciones IP internas al crear el clúster. De forma predeterminada, un clúster nativo de VPC asigna una subred /24 a cada nodo para que se use como dirección IP de pod. Una /24 subred corresponde a 256 direcciones IP. En Autopilot, el clúster usa una subred /26 que corresponde a 64 direcciones, y no puedes cambiar este ajuste de subred.

El modelo de red de GKE no permite reutilizar direcciones IP en la red. Cuando migres a GKE, debes planificar la asignación de direcciones IP para reducir el uso de direcciones IP internas en GKE.

Como las direcciones IP de los pods se pueden enrutar en la red de VPC, los pods pueden recibir tráfico de forma predeterminada de los siguientes recursos:

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

Cuando te comunicas desde pods con servicios externos al 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 gestiona las direcciones IP privadas y externas de forma diferente, tal como se indica en los siguientes puntos:

También puedes usar direcciones IP públicas usadas de forma privada (PUPI) en tu red de VPC o en las redes conectadas. Si usas direcciones PUPI, puedes seguir beneficiándote del modelo de red totalmente integrado y ver la dirección IP del pod directamente como fuente. Para conseguir ambos objetivos, debes incluir las direcciones PUPI en la lista nonMasqueradeCIDRs.

Entender el flujo de tráfico de los pods en una red de GKE

En el siguiente diagrama se muestra cómo pueden comunicarse los pods en el modelo de red 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 pueden usar las direcciones IP internas los pods de los entornos de GKE para comunicarse directamente con los siguientes recursos:

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

El diagrama también muestra lo que ocurre cuando un pod necesita usar una dirección IP externa para comunicarse con una aplicación. Cuando 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. Una vez que el tráfico sale del nodo, Cloud NAT traduce la dirección IP del nodo a una dirección IP externa.

Para disfrutar de las ventajas descritas anteriormente en este documento, especialmente la de que las direcciones IP de los pods sean visibles en todos los datos de telemetría, Google ha elegido un modelo de red totalmente integrado. En GKE, las direcciones IP de los pods se exponen en los registros de flujo de VPC (incluidos los nombres de los pods en los metadatos), en Packet Mirroring, en los registros de reglas de cortafuegos y en los registros de tu aplicación para destinos no enmascarados.

Siguientes pasos