Planifica las direcciones IP cuando migres a GKE

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

  • Cómo reducir el uso de direcciones IP de Pod 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 red alternativos en GKE cuando la arquitectura del clúster no cumple con los requisitos de tu organización.

Este documento es para ingenieros de operaciones, ingenieros de redes y arquitectos de la nube que planean migrar clústeres de Kubernetes de otros entornos a GKE. Usa la guía de este documento cuando tu organización tenga dificultades para asignar suficientes direcciones IP internas del uso esperado de GKE.

En este documento, se supone que estás familiarizado con Kubernetes y su modelo de red. 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 abordan las estrategias de administración para el rango de direcciones que se usa en las direcciones IP del Service. La cantidad de direcciones necesarias para los Services es mucho menor que la de los Pods, y las opciones para reducir esta cantidad son limitadas. En GKE, el rango de direcciones IP del Service es fijo durante el ciclo de vida del clúster. Por lo tanto, el rango de direcciones IP del Service debe tener un tamaño adecuado para la cantidad de Services esperada más grande. Debido a que no se puede acceder a las direcciones IP del Service fuera del clúster, puedes volver a usar esas direcciones en otras redes.

En este documento, también se hace referencia a diferentes modelos de red de Kubernetes: integrados completamente, en modo de isla y aislados. Estos modelos difieren en cómo se puede acceder a las direcciones IP de los Pods en toda la red. Estas diferencias tienen un impacto en las estrategias de administración de direcciones IP que se pueden usar. Para obtener información más detallada sobre estos modelos y el modelo de red de GKE, consulta Comparación de los modelos de red que usan GKE y otras implementaciones de Kubernetes.

Reduce el uso de direcciones IP internas en GKE

GKE usa un modelo de red completamente 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 tiene muchos beneficios. Sin embargo, este tipo de modelo no permite que se vuelvan a usar las direcciones IP de Pod. Esta falta de reutilización requiere que uses direcciones IP de Pod que sean únicas en toda la red de VPC. Por lo tanto, debes considerar con cuidado cuántas direcciones IP únicas necesitas.

La cantidad de direcciones únicas que necesitas influye en si necesitas reducir el uso de direcciones IP, de la siguiente manera:

  • Si tienes suficiente espacio de direcciones para tus necesidades de dirección IP, no necesariamente necesitas tomar medidas a fin de reducir el uso de direcciones IP. Sin embargo, saber cómo reducir el uso de direcciones IP es útil para identificar la cantidad mínima de direcciones IP que se usarán.
  • 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, considera las siguientes opciones:

  • Cambiar la configuración de los Pods por nodo. De forma predeterminada, los clústeres estándar de GKE reservan un rango de subred /24 para cada nodo y permiten hasta 110 Pods por nodo Si esperas usar solo 64 Pods por nodo o menos, puedes ajustar la cantidad máxima de Pods por nodo y, por lo tanto, reducir el uso de direcciones IP de Pod a la mitad o más. . Los clústeres de Autopilot permiten 32 Pods por nodo y este parámetro de configuración no se puede cambiar.
  • Usar varios rangos de direcciones IP de Pod. Con el enrutamiento entre dominios sin clases (CIDR) de varios Pods no contiguos, puedes agregar rangos de direcciones IP de Pod secundarios a los clústeres existentes. Puedes seleccionar qué rango de direcciones IP de Pod usa cada grupo de nodos. La selección del rango de direcciones IP que usa cada grupo te permite ser conservador cuando asignes el espacio de direcciones IP de Pod inicial sin dejar de poder expandir el clúster.

  • Usar direcciones IP que no sean RFC 1918. Es posible que la red de tu empresa no tenga suficientes direcciones IP RFC 1918 sin asignar para usarlas en las direcciones IP de Pod. Si no tienes suficientes direcciones IP RFC 1918 sin asignar, puedes usardirecciones que no son RFC 1918, como direcciones en el espacio de direcciones RFC 6598 (100.64.0.0/10 ).

    Si ya usas el espacio RFC 6598 en otra parte de la red empresarial, puedes usar el espacio de direcciones clase E/RFC 5735 (240.0.0.0/4) para direcciones IP de Pod. Sin embargo, el tráfico de estas direcciones IP se bloquea en los hosts de Windows y en algunos hardware locales. Para evitar el bloqueo de las direcciones RFC 5735, considera enmascarar el tráfico a estos destinos externos como se describe en la sección Oculta direcciones IP de Pod solo de las redes locales. Sin embargo, cuando enmascaras el tráfico a destinos externos, pierdes algunos datos de telemetría que se dirigen a aplicaciones locales.

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

Elige un modelo de red en GKE

En el documento sobre el modelo de red de GKE, se analiza cómo funcionan los clústeres estándar en GKE, incluidas las direcciones IP de Pod involucradas. En este documento, en la sección Reduce el uso de direcciones IP internas en GKE, se describe cómo reducir la cantidad de direcciones IP internas necesarias en esos clústeres. Saber 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, solo conocer y aplicar esos conceptos podría no brindarte una implementación de red que satisfaga tus necesidades. El siguiente árbol de decisión puede ayudarte a decidir cómo implementar el modelo de red de GKE que más te convenga:

Árbol de decisión para las estrategias de mitigación de direcciones IP en GKE.

El árbol de decisión siempre comienza con la creación de clústeres estándar de GKE que se basan en un modelo de red completamente integrado. El siguiente paso del árbol es reducir el uso de direcciones IP mediante la aplicación de todas las opciones descritas en este documento.

Si redujiste el uso de direcciones IP tanto como es posible y aún no tienes 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 usar:

Recuerda que este árbol de decisión solo debe usarse como guía. Según tu caso de uso específico, es posible que prefieras otro modelo según las ventajas y desventajas de cada modelo. A menudo, varios modelos son viables y puedes elegir qué enfoque se adapta mejor a tu organización.

Hay casos excepcionales en los que los modelos alternativos que se presentan en el árbol de decisión no satisfacen tus necesidades. En estos casos excepcionales, es posible que puedas usar el modelo descrito en Usa instancias de varias NIC para ocultar direcciones de clústeres.

Emula modelos de red alternativos

Para aprovechar los beneficios del modelo de red completamente integrado, te recomendamos que mantengas los clústeres de GKE en la misma red lógica que tus otros recursos de la nube. Sin embargo, es posible que no puedas seguir esta recomendación. Tal vez que no tengas suficiente espacio de direcciones IP o debas ocultar las direcciones IP de Pod de la red más grande de tu organización.

En esta sección, se proporcionan opciones para usar el modelo de red completamente integrado mediante la descripción de diferentes patrones de arquitectura que imitan varios modelos de red alternativos en GKE. Estos patrones alternativos de arquitectura crean un modo de operación para GKE similar a los modelos de red de modo isla o de modo aislado.

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

Ocultar las direcciones IP del Pod solo de las redes locales

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

  • Haz que los clústeres de GKE en Google Cloud asignen direcciones IP de Pods que se enruten a través de la implementación de Google Cloud.
  • Evitar que estas direcciones IP se enruten sin NAT a recursos locales o a otros entornos de nube a través de Cloud VPN o Cloud Interconnect.

Por lo general, este patrón de arquitectura se usa con el espacio de direcciones IP de clase E/RFC 5735, ya que este espacio 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/RFC 5735 no se pueden enrutar con facilidad a los recursos locales, ya que muchos proveedores de hardware de red bloquean este tráfico.

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

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

  1. Crea un rango de direcciones IP secundario para la subred del Pod. Como se describió antes en esta sección, puedes crear este rango de direcciones a partir del espacio de clase E/RFC 5735, el espacio RFC 1918 o un conjunto interno de direcciones IP que no sean RFC 1918. Por lo general, se usa el espacio de clase E/RFC 5735.
  2. Usa anuncios de ruta personalizados y quita el rango de IP del Pod de los anuncios en tus Cloud Routers. Quitar estas direcciones ayuda a garantizar que los rangos de IP del Pod no se anuncien a través del Protocolo de puerta de enlace fronteriza (BGP) a tus routers locales.
  3. Crea tu clúster de GKE con el rango de direcciones IP secundario como el enrutamiento entre dominios sin clases (CIDR) para el Pod. Puedes usar las estrategias descritas en Reduce el uso de direcciones IP internas en GKE para reducir el uso de direcciones IP.

  4. Agrega las siguientes direcciones IP a la lista nonMasqueradeCIDRs en el agente de enmascaramiento:

    • El rango de direcciones IP que usaste para los Pods.
    • El rango de direcciones IP que se usa para los nodos.
    • Otras direcciones IP que se usan solo en Google Cloud, como los rangos de direcciones IP principales que se usan en Google Cloud

    No incluyas los rangos 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 separadas y tampoco incluyas esos rangos.

Cuando usas los pasos anteriores a fin de configurar este patrón, configuras los clústeres para que tengan los siguientes comportamientos:

  • Actúa como un modelo de red completamente integrado dentro de Google Cloud.
  • Actuar como un modelo de red de modo isla cuando interactúan con redes locales

Para que este patrón alternativo emule por completo el modelo de red en modo isla, debes cambiar la lista nonMasqueradeCIDRs en el agente de enmascaramiento a una lista que contenga solo los nodos del clúster y los rangos de direcciones IP del Pod. Hacer esa lista siempre da como resultado el enmascaramiento del tráfico fuera del clúster a la dirección IP del nodo, incluso dentro de Google Cloud. Sin embargo, después de realizar este cambio, no podrás recopilar datos de telemetría a nivel de los Pods dentro de la red de VPC.

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

Diagrama de red que muestra la implementación del ocultamiento de direcciones IP solo de redes locales.

En el diagrama anterior, se muestra cómo ocultar las direcciones IP de Pod de las redes externas. Como se muestra en este diagrama, los Pods dentro 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 en el diagrama también se muestran los Pods que usan direcciones en el espacio de clase E/RFC 5735.

En el caso del tráfico que se envía fuera de los clústeres, en el diagrama se muestra cómo se aplica NAT de origen (SNAT) a ese tráfico cuando sale del nodo. La SNAT se usa sin importar si el tráfico se enruta a través de Cloud VPN a aplicaciones locales o a través de Cloud NAT a aplicaciones externas.

En este patrón de arquitectura, se usan direcciones IP de Pod para la comunicación dentro de Google Cloud. El tráfico solo se enmascara cuando se dirige a aplicaciones locales o a otros entornos de nube. Si bien no puedes conectarte a los Pods directamente desde aplicaciones locales, puedes conectarte a los servicios expuestos a través del balanceo de cargas interno.

Ocultar las direcciones IP de Pod de las redes locales tiene las siguientes ventajas:

  • Aún puedes aprovechar el modelo de red completamente integrado dentro de Google Cloud, como el uso de firewalls y la recopilación de datos de telemetría basados en direcciones IP de Pods. Además, puedes conectarte a los Pods directamente para fines de depuración desde Google Cloud.
  • Aún puedes usar mallas de servicios de varios clústeres con direcciones IP de Pods dentro de Google Cloud.

Sin embargo, ocultar las direcciones IP de Pod de las redes externas tiene las siguientes desventajas:

  • No puedes volver a usar los rangos de direcciones IP de Pods o servicios para diferentes clústeres dentro de Google Cloud.
  • Es posible que debas administrar dos conjuntos diferentes de reglas de firewall: una para el tráfico entre redes locales y otra para el tráfico completo dentro de Google Cloud.
  • No puedes tener comunicación directa de Pod a Pod en mallas de servicios de varios clústeres que abarquen Google Cloud y tu entorno local, o bien, otros proveedores de servicios en la nube. Cuando se usa Istio, por ejemplo, toda la comunicación debe ocurrir entre las puertas de enlace de Istio.

Ocultar las direcciones IP del Pod mediante Private Service Connect

En este patrón de arquitectura, se usa Private Service Connect para ocultar las direcciones IP de Pod. Usa este patrón de arquitectura cuando tengas las siguientes necesidades:

  • Solo necesitas exponer una cantidad limitada de Services de tus clústeres de GKE.
  • Los clústeres de GKE pueden funcionar de forma independiente y no requieren comunicación de salida a varias aplicaciones en la red corporativa.

Private Service Connect proporciona una forma de publicar tus servicios que se consumirán desde otras redes. Puedes exponer los servicios de GKE mediante un balanceador de cargas de red de transferencia interno y adjuntos de servicio, y consumir estos servicios mediante un extremo desde otras redes de VPC.

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

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

  3. Si tu clúster de GKE necesita comunicación de salida a algunas aplicaciones de tu red corporativa, expón esas aplicaciones mediante la publicación de servicios a través de Private Service Connect (opcional).

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

Diagrama de red que muestra la implementación del ocultamiento de direcciones IP mediante Private Service Connect.

En el diagrama anterior, se muestra cómo la comunicación dentro de los clústeres del modelo de Private Service Connect y entre ellos es similar a un modelo de red aislado. Sin embargo, la comunicación permitida se realiza a través de extremos de Private Service Connect en lugar de mediante direcciones IP públicas. Como se muestra en este diagrama, cada clúster obtiene su propia red de VPC independiente. 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 dentro de un clúster pueden comunicarse directamente entre sí.

Para la comunicación desde fuera del clúster, el diagrama muestra cómo una aplicación externa puede llegar al clúster a través de un extremo de Private Service Connect. Ese extremo se conecta al adjunto de servicio que proporciona el productor de servicios en la red de VPC del clúster. La comunicación entre clústeres también pasa por un extremo de Private Service Connect y un adjunto de servicio de un productor de servicios.

Usar Private Service Connect para ocultar las direcciones IP de un Pod presenta las siguientes ventajas:

  • No es necesario planificar las direcciones IP porque el espacio de direcciones IP del clúster de GKE está oculto del resto de la red. Este enfoque expone solo una dirección IP por servicio a la red de VPC que la usa.
  • Proteger el clúster es más fácil porque este modelo define con claridad qué servicios están expuestos y solo se puede acceder a esos servicios desde el resto de la red de VPC.

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

  • Los Pods dentro del clúster no pueden establecer 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 las API de Google (mediante el Acceso privado a Google). Si los servicios fuera del 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 adjuntos de servicio. Por lo tanto, el uso de Private Service Connect solo funciona cuando la cantidad de estos servicios se limita a aquellos proveedores que proporcionan adjuntos.
  • Solo se puede acceder a los extremos desde la misma región en la que se encuentra el servicio. Además, se puede acceder a estos extremos solo desde la red de VPC conectada, no desde redes de VPC con intercambio de tráfico ni redes conectadas a través de Cloud VPN o Cloud Interconnect.

Ocultar direcciones IP del Pod mediante Cloud VPN

En este patrón de arquitectura, se 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 manera similar al modelo de red de modo isla. Al igual que el modelo de modo isla, este patrón te ofrece la ventaja de reutilizar rangos de direcciones IP de Pod y Service entre clústeres. La reutilización es posible porque la comunicación con aplicaciones fuera del clúster usa SNAT. Los nodos usan SNAT para asignar direcciones IP de Pod a su propia dirección IP de nodo antes de que el tráfico salga del nodo.

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

  1. En una red de VPC independiente, crea un clúster de GKE. La red de VPC debe contener solo ese clúster.

    Para el clúster, usa la parte sin usar de tu asignación de dirección IP pública a fin de definir dos rangos de direcciones IP: uno para Pods y otro para objetos Service. Ajusta el tamaño de estos rangos de direcciones IP según las necesidades del clúster de GKE más grande que esperas usar. Reserva cada uno de estos rangos para usarlos de forma exclusiva dentro de GKE. También debes volver a usar estos rangos para todos los clústeres de GKE en tu organización.

    A veces, no es posible reservar un rango tan grande de direcciones IP. Es posible que tu organización ya use uno o ambos rangos de direcciones IP de Pod y Service para otras aplicaciones. Si el rango 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. Para el clúster que acabas de crear, configura la lista nonMasqueradeCIDRs en el agente de enmascaramiento en una lista que contenga los rangos de direcciones IP del nodo y del Pod 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 de Google Cloud.

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

  4. Usa anuncios de ruta personalizados para evitar que la red de VPC del clúster anuncie los rangos de direcciones IP de Pod y Service que se dirigen a tu red de VPC principal.

  5. Repite los pasos del 1 al 4 para los otros clústeres de GKE que necesitas. En todos los clústeres, usa los mismos rangos de direcciones IP para Pods y Services. Sin embargo, usa direcciones IP distintas para cada nodo.

  6. Si tienes conectividad a redes locales a través de Cloud VPN o Cloud Interconnect, usa los anuncios de ruta personalizados para anunciar de forma manual los rangos de IP de nodo.

  7. Si tienes otras redes conectadas a tu red principal de VPC a través del intercambio de tráfico entre redes de VPC, exporta rutas personalizadas en estos intercambios de tráfico para asegurarte de que los nodos del clúster de GKE puedan acceder a las redes con intercambio de tráfico.

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

Diagrama de red que muestra la implementación del ocultamiento de direcciones IP mediante Cloud VPN.

En el diagrama anterior, se muestra cómo ocultar las direcciones IP de Pod mediante Cloud VPN, que crea un enfoque similar al modelo de red de modo isla. Como se muestra en el diagrama, cada clúster de GKE obtiene su propia red de VPC independiente. Cada red tiene un espacio de direcciones IP de nodo que es 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 dirección IP de Pod no se anuncia desde las redes de VPC que contienen clústeres.

Observa en el diagrama que solo los Pods dentro de un clúster pueden comunicarse directamente entre sí. El nodo usa SNAT para enmascarar el espacio de direcciones IP de 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 ni desde la red corporativa. Solo se puede acceder a los Services del clúster expuestos con un balanceador de cargas interno a través de las conexiones de Cloud VPN.

Usar Cloud VPN para ocultar las direcciones IP del Pod tiene las siguientes ventajas:

  • Como se describe en el modelo de red de modo isla, puedes volver a usar los rangos de direcciones IP de Pod y Service entre clústeres.
  • Es posible que los firewalls necesiten menos configuración porque no se puede acceder a las direcciones IP del Pod directamente desde la red de VPC principal ni desde las redes conectadas. Por lo tanto, no necesitas configurar reglas de firewall 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 mencionadas en el modelo de red de modo isla. Por ejemplo, no puedes establecer reglas de firewall a nivel de Pod. Tampoco puedes recopilar datos de telemetría a nivel de Pod en la red de VPC principal o en la red conectada.
  • En comparación con el modelo de red de GKE predeterminado, este patrón genera costos adicionales que provienen de los costos asociados con los túneles de Cloud VPN y cargos por transferencia de datos.
  • Cloud VPN tiene un límite de ancho de banda por túnel VPN. Si alcanzas este límite de ancho de banda, puedes configurar varios túneles de Cloud VPN y distribuir el tráfico mediante varias rutas de igual costo (ECMP). Sin embargo, realizar estas acciones aumenta la complejidad de la configuración y el mantenimiento de tu implementación de GKE.
  • Mantener los anuncios de ruta sincronizados agrega complejidad a la creación del clúster. Siempre que crees clústeres de GKE nuevos, debes configurar túneles de Cloud VPN y crear anuncios de ruta personalizados en esos túneles y en las aplicaciones locales.

Ocultar las direcciones IP del Pod mediante las direcciones IP públicas usadas de forma interna y el intercambio de tráfico entre redes de VPC

Si la organización posee direcciones IP públicas sin usar, puedes usar este patrón de arquitectura que se parece a un modelo de red de modo isla, pero a través del uso privado de este espacio de direcciones IP públicas. Esta arquitectura es similar al modelo que usa Cloud VPN, pero usa el intercambio de tráfico entre redes de VPC para crear la separación entre el clúster de GKE y la red principal.

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

  1. En una red de VPC independiente, crea un clúster de GKE. La red de VPC debe contener solo ese clúster.

    Para el clúster, usa la parte sin usar de tu asignación de dirección IP pública a fin de definir dos rangos de direcciones IP: uno para Pods y otro para objetos Service. Ajusta el tamaño de estos rangos de direcciones IP según las necesidades del clúster de GKE más grande que esperas usar. Reserva cada uno de estos rangos para usarlos de forma exclusiva dentro de GKE. También debes volver a usar estos rangos para todos los clústeres de GKE en tu organización.

    En lugar de usar la asignación de dirección IP pública, en teoría, es posible usar los bloques de dirección IP pública más grandes y sin usar que son propiedad de terceros. Sin embargo, no recomendamos esa configuración, ya que esas direcciones IP podrían venderse o usarse públicamente en cualquier momento. La venta o el uso de direcciones genera problemas de seguridad y conectividad cuando se usan servicios públicos en Internet.

  2. Para el clúster que acabas de crear, configura la lista nonMasqueradeCIDRs en el agente de enmascaramiento en una lista que contenga los rangos de direcciones IP del nodo y del Pod 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 de Google Cloud.

  3. Usa el intercambio de tráfico entre redes de VPC para conectar la red de VPC que contiene el clúster de GKE a la red de VPC existente (principal). Debido a que no quieres que se intercambien direcciones PUPI en este modelo, establece la marca --no-export-subnet-routes-with-public-ip cuando configures el intercambio de tráfico.

  4. Repite los pasos del 1 al 3 para los otros clústeres de GKE que necesitas. En todos los clústeres, usa el mismo rango de direcciones IP para Pods y Services. Sin embargo, usa una dirección IP distinta para cada nodo.

  5. Si tienes conectividad a redes locales a través de Cloud VPN o Cloud Interconnect, usa los anuncios de ruta personalizados para anunciar de forma manual los rangos de IP de nodo.

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

Diagrama de red que muestra la implementación del ocultamiento de direcciones IP mediante el intercambio de tráfico entre redes de VPC y PUPI.

En el diagrama anterior, se muestra cómo ocultar las direcciones IP mediante el intercambio de tráfico entre redes de VPC. Como se muestra en el diagrama, cada clúster de GKE obtiene su propia red de VPC independiente. Cada nodo tiene un espacio de direcciones IP de nodo distinto, pero usa el mismo espacio de direcciones IP de Pod que se definió desde el espacio de direcciones PUPI de tu organización. Las redes de VPC se conectan entre sí y con aplicaciones que no son de Kubernetes en Google Cloud a través del intercambio de tráfico entre redes de VPC. El espacio de direcciones PUPI no se anuncia entre los intercambios de tráfico. Las redes de VPC se conectan a la red corporativa a través de túneles de Cloud VPN.

Solo los Pods dentro de un clúster pueden comunicarse directamente entre sí. El nodo usa SNAT para enmascarar el espacio de IP de 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 ni desde la red corporativa. Solo se puede acceder a los Services expuestos con un balanceador de cargas interno a través de las conexiones de intercambio de tráfico entre redes de VPC.

Este patrón de arquitectura es similar al enfoque de Cloud VPN descrito antes, pero tiene las siguientes ventajas sobre ese patrón:

  • A diferencia del patrón de arquitectura de Cloud VPN, el intercambio de tráfico entre redes de VPC no incluye costos adicionales para los túneles de Cloud VPN ni el ancho de banda entre entornos.
  • El intercambio de tráfico entre redes de VPC no tiene limitaciones de ancho de banda y está completamente integrado en las redes definidas por software de Google. Por lo tanto, el intercambio de tráfico entre redes de VPC puede proporcionar una latencia un poco menor que Cloud VPN porque el intercambio de tráfico no requiere las puertas de enlace ni el procesamiento que necesita Cloud VPN.

Sin embargo, el modelo de intercambio de tráfico entre redes de VPC también tiene las siguientes desventajas en comparación con el modelo de Cloud VPN:

  • Tu organización requiere un espacio de direcciones IP públicas que no esté en uso y sea lo suficientemente grande como para el espacio de direcciones IP del Pod que necesita el clúster de GKE más grande que esperas.
  • El intercambio de tráfico entre redes de VPC no es transitivo. Por lo tanto, los clústeres de GKE conectados a través del intercambio de tráfico entre redes de VPC a la red de VPC principal no pueden comunicarse directamente entre sí ni con aplicaciones en redes de VPC que intercambian tráfico con la VPC principal. Debes conectar esas redes directamente a través del intercambio de tráfico entre redes de VPC para habilitar dicha comunicación o usar una VM de proxy en la red de VPC principal.

Usa instancias de varias NIC para ocultar las 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 de modo isla:

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

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

Usar instancias de varias NIC para ocultar las direcciones del clúster presenta las siguientes ventajas:

  • El espacio de direcciones IP del clúster de GKE está oculto del resto de la red. Solo se expone una dirección IP por servicio a la red de VPC que la usa.
  • Se puede acceder a los servicios de forma global, desde redes locales conectadas y desde redes con intercambio de tráfico.

Sin embargo, usar instancias de varias NIC para ocultar las direcciones del clúster presenta las siguientes desventajas:

  • Este modelo es más complejo de implementar que otros enfoques porque no solo requiere implementar el modelo, sino también configurar la supervisión y el registro para las instancias de varias NIC.
  • Las instancias de varias NIC tienen limitaciones de ancho de banda y están sujetas a los precios de instancias de VM.
  • Debes administrar y actualizar las instancias de varias NIC.

¿Qué sigue?