Gestionar la migración de direcciones IP en GKE

En este documento se describe cómo gestionar el uso de direcciones IP en Google Kubernetes Engine (GKE) y cómo usar modelos de red alternativos en GKE cuando sea necesario. En este documento se tratan los siguientes conceptos:

  • Cómo reducir el uso de direcciones IP de pods en GKE para que GKE se adapte a las necesidades de direcciones IP de la mayoría de las organizaciones.
  • Cómo se pueden implementar modelos de redes alternativos en GKE cuando la arquitectura del clúster no cumple los requisitos de tu organización.

Este documento está dirigido a arquitectos de la nube, ingenieros de operaciones e ingenieros de redes que estén planeando migrar clústeres de Kubernetes de otros entornos a GKE. Sigue las directrices de este documento cuando tu organización tenga dificultades para asignar suficientes direcciones IP internas para el uso previsto de GKE.

En este documento se da por hecho que conoces Kubernetes y su modelo de red. 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 tratan las estrategias de gestión del intervalo de direcciones que se usa para las direcciones IP de servicio. El número de direcciones necesarias para los servicios es mucho menor que el de los pods y las opciones para reducir este número son limitadas. En GKE, el intervalo de direcciones IP de servicio es fijo durante la vida útil del clúster. Por lo tanto, el intervalo de direcciones IP de servicio debe tener el tamaño del mayor número de servicios previsto. Como no se puede acceder a las direcciones IP de servicio fuera del clúster, puedes reutilizar esas direcciones en otras redes.

En este documento también se hace referencia a diferentes modelos de red de Kubernetes: totalmente integrado, en modo aislado y aislado. Estos modelos se diferencian en la forma en que se puede acceder a las direcciones IP de los pods en toda la red. Estas diferencias influyen en las estrategias de gestión de direcciones IP que se pueden usar. Para obtener más información sobre estos modelos y el modelo de red de GKE, consulta el artículo Comparación de los modelos de red utilizados por GKE y otras implementaciones de Kubernetes.

Reducir el uso de direcciones IP internas en GKE

GKE usa un modelo de red totalmente integrado en el que los clústeres se implementan en una red de VPC que también puede contener otras aplicaciones. El modelo de GKE ofrece muchas ventajas. Sin embargo, este tipo de modelo no permite reutilizar las direcciones IP de los pods. Esta falta de reutilización requiere que uses direcciones IP de pods que sean únicas en toda la red de VPC. Por lo tanto, debes pensar detenidamente cuántas direcciones IP únicas necesitas.

El número de direcciones únicas que necesitas influye en si tienes que reducir el uso de direcciones IP, como se indica a continuación:

  • Si tienes suficiente espacio de direcciones para tus necesidades de direcciones IP, no es necesario que tomes medidas para reducir el uso de direcciones IP. Sin embargo, saber cómo reducir el uso de direcciones IP es útil para identificar el número mínimo de direcciones IP que se deben usar.
  • Si no tienes suficiente espacio de direcciones, debes reducir el uso de direcciones IP para crear clústeres de GKE que se ajusten a las restricciones de tu espacio de direcciones.

Para ayudarte a reducir el uso de direcciones IP en GKE, puedes usar las siguientes opciones:

  • Cambie el ajuste Pods por nodo. De forma predeterminada, los clústeres estándar de GKE reservan un intervalo de /24 subredes para cada nodo y permiten hasta 110 pods por nodo. Si prevé usar solo 64 pods o menos por nodo, puede ajustar el número máximo de pods por nodo y, por lo tanto, reducir el uso de direcciones IP de pods a la mitad o más. Los clústeres Autopilot permiten 32 pods por nodo y este ajuste no se puede cambiar.
  • Usa varios intervalos de direcciones IP de pods. Con el enrutamiento de interdominios sin clases (CIDR) de varios pods discontinuos, puedes añadir intervalos de direcciones IP de pods secundarios a clústeres ya creados. Puedes seleccionar el intervalo de direcciones IP de pods que usa cada grupo de nodos. Si seleccionas el intervalo de direcciones IP que usa cada grupo, podrás ser conservador al asignar el espacio de direcciones IP de pods inicial y, al mismo tiempo, ampliar el clúster.

  • Usa direcciones IP que no sean RFC 1918. Es posible que tu red empresarial no tenga suficientes direcciones IP RFC 1918 sin asignar para usarlas como direcciones IP de pods. Si no tienes suficientes direcciones IP RFC 1918 sin asignar, puedes usar direcciones que no sean RFC 1918, como las del espacio de direcciones RFC 6598 (100.64.0.0/10).

    Si ya usas el espacio RFC 6598 en otra parte de tu red empresarial, puedes usar el espacio de direcciones Clase E/RFC 5735 (240.0.0.0/4) para las direcciones IP de los pods. Sin embargo, el tráfico de estas direcciones IP se bloquea en los hosts de Windows y en algunos hardware local. Para evitar bloquear las direcciones RFC 5735, considera la posibilidad de enmascarar el tráfico a estos destinos externos, tal como se describe en la sección Ocultar las direcciones IP de los pods solo de las redes locales. Sin embargo, perderás algunos datos de telemetría dirigidos a aplicaciones locales cuando enmascares el tráfico a destinos externos.

Si tu organización tiene un espacio de direcciones IP públicas grande, también puedes usar direcciones públicas usadas de forma privada (PUPI). Cuando se usan direcciones PUPI, se deben incluir en la lista nonMasqueradeCIDRs para tener conectividad fuera del clúster sin usar NAT.

Elegir un modelo de red en GKE

En el documento sobre el modelo de redes de GKE se explica cómo funcionan los clústeres estándar en GKE, incluidas las direcciones IP de los pods implicadas. En este documento, la sección Reduce el uso de direcciones IP internas en GKE describe cómo reducir el número de direcciones IP internas necesarias en esos clústeres. Conocer cómo funciona el modelo de red de GKE y cómo reducir las direcciones IP internas es fundamental para cualquier modelo de red que uses en GKE.

Sin embargo, conocer y aplicar estos conceptos puede que no te proporcione una implementación de red que satisfaga tus necesidades. El siguiente árbol de decisiones puede ayudarte a decidir cómo implementar el modelo de red de GKE que mejor se adapte a tus necesidades:

Árbol de decisiones de las estrategias de migración de direcciones IP en GKE.

El árbol de decisiones siempre empieza con la creación de clústeres estándar de GKE basados en un modelo de red totalmente integrado. El siguiente paso en el árbol es reducir el uso de direcciones IP aplicando todas las opciones descritas en este documento.

Si has reducido el uso de direcciones IP tanto como has podido y sigues sin tener suficiente espacio de direcciones para tus clústeres de GKE, necesitas un modelo de red alternativo. El árbol de decisión te ayuda a decidir cuál de los siguientes modelos de red alternativos debes usar:

Recuerda que este diagrama de flujo de toma de decisiones solo debe usarse como guía. Según tu caso práctico específico, puede que prefieras otro modelo en función de las ventajas e inconvenientes de cada uno. A menudo, se pueden usar varios modelos y puedes elegir el que mejor se adapte a tu organización.

En algunos casos excepcionales, los modelos alternativos que se presentan en el árbol de decisiones no satisfacen tus necesidades. En estos casos excepcionales, puedes usar el modelo descrito en Usar instancias con varias NICs para ocultar direcciones de clúster.

Emular modelos de red alternativos

Para aprovechar las ventajas del modelo de red totalmente integrado, le recomendamos que mantenga sus clústeres de GKE en la misma red lógica que sus otros recursos en la nube. Sin embargo, es posible que no puedas seguir esta recomendación. Es posible que no tengas suficiente espacio de direcciones IP o que tengas que ocultar las direcciones IP de los pods de la red más grande de tu organización.

En esta sección se ofrecen opciones para usar el modelo de red totalmente integrado. Para ello, se describen diferentes patrones de arquitectura que imitan varios modelos de red alternativos en GKE. Estos patrones de arquitectura alternativos crean un modo de funcionamiento para GKE similar al modelo de red en modo aislado o al modelo de red en modo isla.

Cada patrón de arquitectura alternativo incluye la siguiente información:

Ocultar las direcciones IP de los pods solo de las redes locales

El patrón de arquitectura en el que se ocultan las direcciones IP de las redes locales usa una combinación de los siguientes objetivos de enrutamiento:

  • Haz que los clústeres de GKE de Google Cloud asignen direcciones IP de pod que se enruten en toda la implementación de Google Cloud .
  • Evita que estas direcciones IP se enruten sin NAT a recursos on-premise u otros entornos de nube a través de Cloud VPN o Cloud Interconnect.

Este patrón de arquitectura se suele usar con el espacio de direcciones IP de clase E o RFC 5735, ya que incluye muchas direcciones IP. Tener tantas direcciones IP disponibles ayuda a satisfacer la necesidad de proporcionar direcciones IP únicas a cada pod. Sin embargo, las direcciones IP de clase E o RFC 5735 no se pueden enrutar fácilmente a recursos locales porque muchos proveedores de hardware de red bloquean este tráfico.

En lugar de usar el espacio de direcciones IP de clase E o RFC 5735, puedes usar direcciones IP de RFC 1918 o un conjunto interno de direcciones IP que no sean de RFC 1918. Si usas uno de estos otros conjuntos de direcciones IP, determina si hay alguna superposición de direcciones IP entre las direcciones usadas para los pods y las direcciones usadas en las redes locales. Si hay solapamiento, asegúrate de que nunca haya comunicación entre los clústeres que usen esas direcciones y las aplicaciones locales que usen las mismas direcciones.

En los siguientes pasos se explica cómo configurar este patrón de arquitectura:

  1. Crea un intervalo de direcciones IP secundario para la subred de pods. Como se ha descrito anteriormente en esta sección, puedes crear este intervalo de direcciones a partir del espacio de clase E o RFC 5735, el espacio RFC 1918 o un conjunto interno de direcciones IP que no sean RFC 1918. Normalmente, se usa el espacio de clase E/RFC 5735.
  2. Usa rutas anunciadas personalizadas y quita el intervalo de direcciones IP de los pods de los anuncios de tus Cloud Routers. Si quitas estas direcciones, te aseguras de que los intervalos de IPs de pods no se anuncien a través del protocolo de puerta de enlace de frontera (BGP) a tus routers locales.
  3. Crea tu clúster de GKE usando el intervalo de direcciones IP secundarias como enrutamiento entre dominios sin clases (CIDR) para el pod. Puedes usar las estrategias descritas en el artículo sobre cómo reducir el uso de direcciones IP internas en GKE para reducir el uso de direcciones IP.

  4. Añade las siguientes direcciones IP a la lista nonMasqueradeCIDRs del agente de suplantación de identidad:

    • El intervalo de direcciones IP que has usado para los pods.
    • Intervalo de direcciones IP que se usa para los nodos.
    • Otras direcciones IP que se usan solo en Google Cloud, como los intervalos de direcciones IP principales que se usan en Google Cloud.

    No incluyas los intervalos de direcciones IP internas que se usan en entornos locales o en otros entornos de nube. Si tienes cargas de trabajo de Windows en Google Cloud, mantenlas en subredes independientes y no incluyas esos intervalos.

Cuando sigues los pasos anteriores para configurar este patrón, los clústeres se configuran para que tengan los siguientes comportamientos:

  • Actúa como un modelo de red totalmente integrado en Google Cloud.
  • Actúa como un modelo de red en modo aislado al interactuar con redes locales.

Para que este patrón alternativo emule por completo el modelo de red en modo isla, debes cambiar la lista nonMasqueradeCIDRs del agente de enmascaramiento por una lista que solo contenga los intervalos de direcciones IP de los nodos y los pods del clúster. Si se crea una lista de este tipo, el tráfico fuera del clúster siempre se enmascarará con la dirección IP del nodo, incluso dentro de Google Cloud. Sin embargo, después de hacer este cambio, no podrá recoger datos de telemetría a nivel de pod en la red VPC.

En el siguiente diagrama se muestra una implementación de este patrón de arquitectura:

Diagrama de red que muestra la implementación de la ocultación de la dirección IP solo en redes locales.

En el diagrama anterior se muestra cómo ocultar las direcciones IP de los pods de redes externas. Como se muestra en este diagrama, los pods de Google Cloud pueden comunicarse directamente entre sí, incluso entre clústeres. Esta comunicación de pods es similar al modelo de GKE. Ten en cuenta que el diagrama también muestra los pods que usan direcciones del espacio Class E/RFC 5735.

En el caso del tráfico enviado fuera de los clústeres, el diagrama muestra cómo se aplica la NAT de origen (SNAT) a ese tráfico cuando sale del nodo. SNAT se usa independientemente de si el tráfico se enruta a través de Cloud VPN a aplicaciones on-premise o a través de Cloud NAT a aplicaciones externas.

Este patrón de arquitectura usa direcciones IP de pods para la comunicación interna. Google CloudEl tráfico solo se enmascara cuando se dirige a aplicaciones on-premise u otros entornos de nube. Aunque no puedes conectarte a los pods directamente desde aplicaciones locales, sí puedes conectarte a los servicios expuestos mediante el balanceo de carga interno.

Ocultar las direcciones IP de los pods de las redes locales tiene las siguientes ventajas:

  • Puedes seguir aprovechando el modelo de red totalmente integrado en Google Cloud, como usar cortafuegos y recoger datos de telemetría basados en direcciones IP de pods. Además, puedes conectarte a los pods directamente para depurar desde Google Cloud.
  • Puedes seguir usando mallas de servicios multiclúster con direcciones IP de pods en Google Cloud.

Sin embargo, ocultar las direcciones IP de los pods de las redes externas tiene los siguientes inconvenientes:

  • No puedes reutilizar los intervalos de direcciones IP de pods o servicios en diferentes clústeres de Google Cloud.
  • Es posible que tengas que gestionar dos conjuntos de reglas de cortafuegos diferentes: uno para el tráfico entre redes locales y otro para el tráfico que se produce completamente en Google Cloud.
  • No puedes tener una comunicación directa entre pods en mallas de servicios multiclúster que abarquen tanto Google Cloud como tu entorno local u otros proveedores de servicios en la nube. Por ejemplo, cuando se usa Istio, toda la comunicación debe producirse entre las pasarelas de Istio.

Ocultar direcciones IP de pods mediante Private Service Connect

Este patrón de arquitectura usa Private Service Connect para ocultar las direcciones IP de los pods. Usa este patrón de arquitectura cuando tengas las siguientes necesidades:

  • Solo tienes que exponer un número limitado de servicios de tus clústeres de GKE.
  • Tus clústeres de GKE pueden funcionar de forma independiente y no requieren comunicación de salida a muchas aplicaciones de tu red corporativa.

Private Service Connect te permite publicar tus servicios para que se puedan usar desde otras redes. Puedes exponer tus servicios de GKE mediante un balanceador de carga de red interno de transferencia directa y vinculaciones de servicio, y consumir estos servicios mediante un endpoint de otras redes de VPC.

En los siguientes pasos se explica cómo configurar este patrón de arquitectura:

  1. Crea un clúster de GKE en otra red de VPC. La red de VPC solo debe contener ese clúster.
  2. Por cada servicio de GKE de tu clúster que deba ser accesible desde otros clústeres o aplicaciones de otra red de VPC, crea un balanceador de carga de red de transferencia interno con Private Service Connect.

  3. (Opcional) Si tu clúster de GKE necesita comunicarse con algunas aplicaciones de tu red corporativa, expón esas aplicaciones publicando servicios a través de Private Service Connect.

    En el siguiente diagrama se muestra una implementación de este patrón de arquitectura:

Diagrama de red que muestra la implementación de la ocultación de la dirección IP mediante Private Service Connect.

El diagrama anterior muestra cómo es la comunicación dentro de los clústeres y entre ellos en el modelo de Private Service Connect, que es similar a la de un modelo de red aislada. Sin embargo, la comunicación permitida se produce a través de los endpoints de Private Service Connect en lugar de a través de direcciones IP públicas. Como se muestra en este diagrama, cada clúster tiene su propia red de VPC. Además, cada red de VPC puede compartir la misma dirección IP y cada clúster puede compartir el mismo espacio de direcciones IP. Solo los pods de un clúster pueden comunicarse directamente entre sí.

En el caso de la comunicación desde fuera del clúster, el diagrama muestra cómo puede acceder una aplicación externa al clúster a través de un endpoint de Private Service Connect. Este endpoint se conecta a la vinculación de servicio proporcionada por el productor de servicios en la red de VPC del clúster. La comunicación entre clústeres también se realiza a través de un endpoint de Private Service Connect y una vinculación de servicio del productor de servicios.

Usar Private Service Connect para ocultar las direcciones IP de los pods tiene las siguientes ventajas:

  • No tienes que planificar las direcciones IP porque el espacio de direcciones IP del clúster de GKE está oculto al resto de la red. Con este enfoque, solo se expone una dirección IP por servicio a la red VPC de consumo.
  • Proteger tu clúster es más fácil porque este modelo define claramente qué servicios están expuestos y solo se puede acceder a ellos desde el resto de la red de VPC.

Sin embargo, usar Private Service Connect para ocultar las direcciones IP de los pods tiene las siguientes desventajas:

  • Los pods del clúster no pueden establecer una comunicación privada fuera del clúster. Los pods solo pueden comunicarse con servicios públicos (cuando los pods tienen conectividad a Internet) o con APIs de Google (mediante Acceso privado de Google). Si los servicios externos al clúster se exponen a través de Private Service Connect, los pods también pueden acceder a esos servicios. Sin embargo, no todos los proveedores de servicios internos crean vinculaciones de servicio. Por lo tanto, Private Service Connect solo funciona cuando el número de estos servicios se limita a los proveedores que proporcionan vinculaciones.
  • Solo se puede acceder a los endpoints desde la misma región en la que se encuentra el servicio. Además, solo se puede acceder a estos puntos finales desde la propia red de VPC conectada, no desde redes de VPC emparejadas ni desde redes conectadas a través de Cloud VPN o Cloud Interconnect.

Ocultar las direcciones IP de los pods mediante Cloud VPN

Este patrón de arquitectura usa Cloud VPN para crear una separación entre los clústeres de GKE y la red de VPC principal. Cuando creas esta separación, la red resultante funciona de forma similar al modelo de red en modo aislado. Al igual que el modelo de modo isla, este patrón te ofrece la ventaja de reutilizar los intervalos de direcciones IP de Pod y Service entre clústeres. Se puede reutilizar porque la comunicación con aplicaciones fuera del clúster usa SNAT. Los nodos usan SNAT para asignar las direcciones IP de los pods a su propia dirección IP de nodo antes de que el tráfico salga del nodo.

En los siguientes pasos se explica cómo configurar este modelo:

  1. Crea un clúster de GKE en otra red de VPC. La red de VPC solo debe contener ese clúster.

    En el clúster, usa la parte no utilizada de la asignación de tu dirección IP pública para definir dos intervalos de direcciones IP: uno para los pods y otro para los servicios. Ajusta el tamaño de estos intervalos de direcciones IP en función de las necesidades del clúster de GKE más grande que vayas a usar. Reserva cada uno de estos intervalos para usarlos exclusivamente en GKE. También puedes reutilizar estos intervalos en todos los clústeres de GKE de tu organización.

    A veces, no es posible reservar un intervalo de direcciones IP tan grande. Es posible que tu organización ya utilice uno o ambos intervalos de direcciones IP de Pod y Services para otras aplicaciones. Si el intervalo de direcciones IP está en uso y no se puede reservar, asegúrate de que las aplicaciones que usan esas direcciones IP no necesiten comunicarse con el clúster de GKE.

  2. En el clúster que acabas de crear, configura la lista nonMasqueradeCIDRs del agente de máscara para que contenga los intervalos de direcciones IP de los nodos y los pods del clúster. Esta lista hace que GKE siempre enmascare el tráfico que sale del clúster a la dirección IP del nodo, incluso dentro deGoogle Cloud.

  3. Usa Cloud VPN para conectar la red de VPC que contiene el clúster de GKE a la red de VPC principal.

  4. Usa rutas anunciadas personalizadas para evitar que la red de VPC del clúster anuncie los intervalos de direcciones IP de los pods y los servicios que se dirigen a tu red de VPC principal.

  5. Repite los pasos del 1 al 4 con los demás clústeres de GKE que necesites. En todos los clústeres, usa los mismos intervalos de direcciones IP para los pods y los servicios. Sin embargo, usa direcciones IP distintas para cada nodo.

  6. Si tienes conectividad con redes on-premise a través de Cloud VPN o Cloud Interconnect, usa rutas anunciadas personalizadas para anunciar manualmente los intervalos de IP de los nodos.

  7. Si tienes otras redes conectadas a tu red de VPC principal mediante el emparejamiento entre redes de VPC, exporta rutas personalizadas en estos emparejamientos para asegurarte de que los nodos del clúster de GKE puedan acceder a las redes emparejadas.

En el siguiente diagrama se muestra una implementación del uso de Cloud VPN para ocultar las direcciones IP de los pods:

Diagrama de red que muestra la implementación de la ocultación de la dirección IP mediante Cloud VPN.

En el diagrama anterior se muestra cómo ocultar las direcciones IP de los pods mediante Cloud VPN, que crea un enfoque similar al modelo de red en modo aislado. Como se muestra en el diagrama, cada clúster de GKE tiene su propia red VPC. Cada red tiene un espacio de direcciones IP de nodo distinto, pero usa el mismo espacio de direcciones IP de pod. Los túneles de Cloud VPN conectan estas redes de VPC entre sí y con la red corporativa, y el espacio de direcciones IP de los pods no se anuncia desde las redes de VPC que contienen clústeres.

En el diagrama, observa que solo los pods de un clúster pueden comunicarse directamente entre sí. El nodo usa SNAT para enmascarar el espacio de direcciones IP del pod cuando se comunica fuera del clúster con otro clúster, con la red corporativa o con una red local conectada. No se puede acceder directamente a los pods desde otros clústeres o desde la red corporativa. Solo se puede acceder a los servicios de clúster expuestos con un balanceador de carga interno a través de las conexiones de Cloud VPN.

Usar Cloud VPN para ocultar las direcciones IP de los pods tiene las siguientes ventajas:

  • Como se describe en el modelo de red en modo aislado, puedes reutilizar los intervalos de direcciones IP de Pod y Service entre clústeres.
  • Es posible que los cortafuegos necesiten menos configuración, ya que no se puede acceder directamente a las direcciones IP de los pods desde la red VPC principal ni desde las redes conectadas. Por lo tanto, no es necesario configurar reglas de cortafuegos explícitas para bloquear la comunicación con los pods.

Sin embargo, usar Cloud VPN para ocultar las direcciones IP de los pods tiene las siguientes desventajas:

  • Se aplican las mismas desventajas que se mencionan en el modelo de red en modo aislado. Por ejemplo, no puedes definir reglas de cortafuegos a nivel de pod. Tampoco puedes recoger datos de telemetría a nivel de pod en la red VPC principal ni en la red conectada.
  • En comparación con el modelo de red predeterminado de GKE, este patrón conlleva costes adicionales derivados de los costes asociados a los túneles de Cloud VPN y los cargos por transferencia de datos.
  • Cloud VPN tiene un límite de ancho de banda por túnel de VPN. Si alcanzas este límite de ancho de banda, puedes configurar varios túneles de Cloud VPN y distribuir el tráfico mediante multipath de igual coste (ECMP). Sin embargo, estas acciones aumentan la complejidad de la configuración y el mantenimiento de la implementación de GKE.
  • Mantener sincronizados los anuncios de rutas añade complejidad a la creación de clústeres. Cada vez que crees clústeres de GKE, tendrás que configurar túneles de Cloud VPN y crear rutas anunciadas personalizadas en esos túneles y en aplicaciones locales.

Ocultar las direcciones IP de los pods mediante direcciones IP públicas usadas internamente y el emparejamiento de redes VPC

Si tu organización tiene direcciones IP públicas sin usar, puedes utilizar este patrón de arquitectura, que se parece a un modelo de red en modo aislado, pero mediante el uso privado de este espacio de direcciones IP públicas. Esta arquitectura es similar al modelo que usa Cloud VPN, pero utiliza el emparejamiento entre redes de VPC para crear la separación entre el clúster de GKE y la red principal.

En los siguientes pasos se explica cómo configurar este patrón de arquitectura:

  1. Crea un clúster de GKE en otra red de VPC. La red de VPC solo debe contener ese clúster.

    En el clúster, usa la parte no utilizada de la asignación de tu dirección IP pública para definir dos intervalos de direcciones IP: uno para los pods y otro para los servicios. Ajusta el tamaño de estos intervalos de direcciones IP en función de las necesidades del clúster de GKE más grande que vayas a usar. Reserva cada uno de estos intervalos para usarlos exclusivamente en GKE. También puedes reutilizar estos intervalos en todos los clústeres de GKE de tu organización.

    En lugar de usar la asignación de tu dirección IP pública, teóricamente es posible usar los bloques de direcciones IP públicas más grandes y sin usar que son propiedad de terceros. Sin embargo, no recomendamos esta configuración, ya que estas direcciones IP se pueden vender o usar públicamente en cualquier momento. La venta o el uso de direcciones ha provocado problemas de seguridad y conectividad al usar servicios públicos en Internet.

  2. En el clúster que acabas de crear, configura la lista nonMasqueradeCIDRs del agente de máscara para que contenga los intervalos de direcciones IP de los nodos y los pods del clúster. Esta lista hace que GKE siempre enmascare el tráfico que sale del clúster a la dirección IP del nodo, incluso en Google Cloud.

  3. Usa el emparejamiento entre redes de VPC para conectar la red de VPC que contiene el clúster de GKE a la red de VPC principal. Como no quieres que se intercambien direcciones PUPI en este modelo, define la marca --no-export-subnet-routes-with-public-ip al configurar el peering.

  4. Repite los pasos del 1 al 3 con los demás clústeres de GKE que necesites. En todos los clústeres, usa el mismo intervalo de direcciones IP para los pods y los servicios. Sin embargo, usa una dirección IP distinta para cada nodo.

  5. Si tienes conectividad con redes on-premise a través de Cloud VPN o Cloud Interconnect, usa anuncios de ruta personalizada para anunciar manualmente los intervalos de direcciones IP de los nodos.

En el siguiente diagrama se muestra una implementación de este patrón de arquitectura:

Diagrama de red que muestra la implementación de la ocultación de direcciones IP mediante PUPI y el emparejamiento entre redes de VPC.

En el diagrama anterior se muestra cómo ocultar direcciones IP mediante el emparejamiento entre redes de VPC. Como se muestra en el diagrama, cada clúster de GKE tiene su propia red VPC. Cada nodo tiene un espacio de direcciones IP de nodo distinto, pero usa el mismo espacio de direcciones IP de pod que se definió a partir del espacio de direcciones PUPI de tu organización. Las redes de VPC se conectan entre sí y a aplicaciones que no son de Kubernetes enGoogle Cloud mediante el emparejamiento entre redes de VPC. El espacio de direcciones PUPI no se anuncia entre las conexiones de emparejamiento. Las redes de VPC se conectan a la red corporativa a través de túneles de Cloud VPN.

Solo los pods de un clúster pueden comunicarse directamente entre sí. El nodo usa SNAT para enmascarar el espacio de IP del pod cuando se comunica fuera del clúster con otro clúster, con la red corporativa o con una red local conectada. No se puede acceder a los pods directamente desde otros clústeres o desde la red corporativa. Solo se puede acceder a los servicios expuestos con un balanceador de carga interno a través de las conexiones de interconexión de redes de VPC.

Este patrón de arquitectura es similar al enfoque de Cloud VPN descrito anteriormente, pero tiene las siguientes ventajas con respecto a ese patrón:

  • A diferencia del patrón de arquitectura de Cloud VPN,el emparejamiento entre redes de VPC no conlleva ningún coste adicional para los túneles de Cloud VPN ni para el ancho de banda entre entornos.
  • El emparejamiento entre redes de VPC no tiene limitaciones de ancho de banda y está totalmente integrado en las redes definidas por software de Google. Por lo tanto, el emparejamiento de redes de VPC puede proporcionar una latencia ligeramente inferior a la de Cloud VPN, ya que el emparejamiento no requiere las pasarelas ni el procesamiento que necesita Cloud VPN.

Sin embargo, el modelo de emparejamiento entre redes de VPC también tiene las siguientes desventajas con respecto al modelo de Cloud VPN:

  • Tu organización necesita un espacio de direcciones IP públicas que no se esté usando y que sea lo suficientemente grande para el espacio de direcciones IP de los pods que necesite el clúster de GKE más grande que tengas previsto.
  • El emparejamiento entre redes de VPC no es transitivo. Por lo tanto, los clústeres de GKE conectados a la red de VPC principal mediante el emparejamiento de redes de VPC no pueden comunicarse directamente entre sí ni con las aplicaciones de las redes de VPC emparejadas con la red de VPC principal. Para habilitar esa comunicación, debes conectar directamente esas redes mediante el emparejamiento entre redes de VPC o usar una VM proxy en la red de VPC principal.

Usar instancias con varias NICs para ocultar direcciones de clúster

Este patrón de arquitectura consta de los siguientes componentes y tecnologías para crear un modelo similar a un modelo de red en modo aislado:

  • Utiliza instancias de Compute Engine con varias tarjetas de interfaz de red (multi-NIC) para crear una capa de separación entre los clústeres de GKE y la red VPC principal.
  • Usa NAT en las direcciones IP enviadas entre esos entornos.

Puedes usar este patrón cuando necesites inspeccionar, transformar o filtrar tráfico específico que entra o sale de los clústeres de GKE. Si necesitas hacer este tipo de inspección, transformación o filtrado, usa las instancias de Compute Engine implementadas para llevar a cabo estas tareas.

Usar instancias con varias NICs para ocultar las direcciones de clúster tiene las siguientes ventajas:

  • El espacio de direcciones IP del clúster de GKE está oculto al resto de la red. Solo se expone una dirección IP por servicio a la red de VPC de consumo.
  • Se puede acceder a los servicios de forma global, desde redes on-premise conectadas y desde redes emparejadas.

Sin embargo, usar instancias con varias NICs para ocultar las direcciones de clúster tiene los siguientes inconvenientes:

  • Este modelo es más complejo de implementar que otros enfoques, ya que requiere no solo implementar el modelo, sino también configurar la monitorización y el registro de las instancias de varias NICs.
  • Las instancias con varias NICs tienen limitaciones de ancho de banda y están sujetas a los precios de las instancias de máquinas virtuales.
  • Debes gestionar y actualizar las instancias con varias NICs.

Siguientes pasos