Para crear clústeres de Google Kubernetes Engine (GKE) escalables y seguros, debes gestionar las direcciones IP de forma eficaz. En este documento se ofrece una descripción general completa de cómo usa GKE las direcciones IP para la comunicación entre clústeres, los modelos de redes admitidos y las prácticas recomendadas para gestionar las direcciones IP de forma eficaz.
Este documento está dirigido a arquitectos de nube y especialistas en redes que diseñan y definen la arquitectura de la red de su organización. Para obtener más información sobre los roles comunes y las tareas de ejemplo en Google Cloud, consulta Roles y tareas de usuario comunes de GKE Enterprise.
Antes de continuar, asegúrate de que conoces los siguientes conceptos:
- Redes básicas: incluidas direcciones IP, CIDR, cortafuegos y traducción de direcciones de red (NAT).
- Componentes principales de Kubernetes: como clústeres, nodos, pods y servicios.
Cómo conectan las direcciones IP los componentes de GKE
GKE se basa en el modelo de red de Kubernetes, que requiere que cada componente tenga una dirección IP distinta para comunicarse. En las siguientes secciones se describe cómo asigna y usa GKE las direcciones IP de los componentes principales del clúster:
Nodos: GKE asigna a cada nodo, que es una instancia de VM de Compute Engine, una dirección IP interna del intervalo de direcciones IP principal de la subred asociada a su grupo de nodos. Esta dirección IP permite la comunicación entre el nodo y el plano de control de Kubernetes. Los nodos también pueden tener una dirección IP externa para acceder a Internet.
Pods: siguiendo el modelo "IP por pod" de Kubernetes, GKE asigna a cada pod una dirección IP única de un intervalo CIDR de pods asignado al nodo. En GKE, la red de VPC enruta de forma nativa las direcciones IP de los pods. Esta capacidad de enrutamiento integrada permite la comunicación directa entre pods, incluso en diferentes nodos, sin necesidad de traducción de direcciones de red (NAT). Todos los contenedores de un mismo pod comparten la misma dirección IP y pueden comunicarse a través de
localhost.Servicios: GKE asigna a cada servicio de Kubernetes una dirección IP virtual estable (
ClusterIP) de un intervalo de direcciones IP secundario dedicado. EsteClusterIPproporciona un endpoint único y fiable para un grupo de pods. Cuando envías tráfico alClusterIP, GKE lo equilibra de carga automáticamente a un pod en buen estado de ese servicio.Plano de control: en los clústeres privados, el plano de control reside en un proyecto de inquilino gestionado por Google y usa su propio intervalo de direcciones IP internas. Este proyecto de arrendatario se conecta a tu red de VPC, lo que permite una comunicación segura entre el plano de control y los nodos de la red de VPC de tu clúster. Esta conexión suele usar Private Service Connect.
Balanceadores de carga: para exponer aplicaciones a Internet o dentro de tu red VPC, puedes configurar GKE para que useGoogle Cloud balanceadores de carga. Los balanceadores de carga externos usan direcciones IP públicas. Los balanceadores de carga internos usan direcciones IP internas del intervalo de la subred principal de tu red de VPC.
En la siguiente tabla se resume cómo asigna GKE direcciones IP a los componentes del clúster:
| Componente | Cómo se asignan las direcciones IP |
|---|---|
| Nodo | GKE asigna una dirección IP interna a cada nodo. GKE asigna esta dirección IP del intervalo de direcciones IP principal de la subred asociada al grupo de nodos del nodo. Esta subred puede ser la subred predeterminada del clúster o una subred adicional. |
| Pod | GKE asigna a cada pod una dirección IP única del intervalo CIDR de pods asignado a su nodo. |
| Servicio (ClusterIP) | GKE asigna a cada servicio una dirección IP virtual estable (ClusterIP) de un intervalo de direcciones IP secundario dedicado dentro de la red de VPC del clúster. |
| Plano de control | En los clústeres privados, el plano de control de GKE tiene su propio intervalo de direcciones IP internas en un proyecto de inquilino gestionado por Google. Este proyecto de arrendatario se conecta a tu red de VPC, normalmente mediante Private Service Connect. |
| Balanceador de carga | Los balanceadores de carga externos usan direcciones IP públicas. Los balanceadores de carga internos usan direcciones IP internas del intervalo de direcciones IP principal de la subred del clúster. |
Direcciones IP de Kubernetes e implementación de GKE
Para usar GKE de forma eficaz, debes conocer las diferencias entre el modelo de red abstracto de Kubernetes y cómo implementa GKE este modelo en Google Cloud.
Modelo de direccionamiento IP de Kubernetes: el proyecto de código abierto Kubernetes especifica que cada pod recibe una dirección IP única. Todas las direcciones IP de los pods pueden comunicarse directamente sin traducción de direcciones de red (NAT). De esta forma, se garantiza un espacio de red plano en el que los pods pueden comunicarse entre sí mediante las direcciones IP que tienen asignadas.
Implementación de direcciones IP de GKE: GKE implementa el modelo de direccionamiento IP de Kubernetes en Google Cloud integrándose con la red nativa de VPC. Cuando creas un pod, GKE le asigna su dirección IP a partir de un intervalo de direcciones IP de alias de VPC. De esta forma, la dirección IP de cada pod se puede enrutar de forma nativa en toda tu red de VPC. Esto permite la comunicación directa no solo entre pods, sino también con otros Google Cloud recursos, como instancias de Compute Engine y bases de datos de Cloud SQL. Del mismo modo, GKE gestiona las direcciones IP de Kubernetes (como
ServiceClusterIP) en la red de VPC. Cuando creasLoadBalancerservicios para la exposición externa, GKE aprovisiona Google Cloud balanceadores de carga. Estos balanceadores de carga usan direcciones IP públicas o internas de tu red de VPC. GKE usa la sólida infraestructura de direccionamiento IP y de redes de Google Cloudpara implementar conceptos de redes basadas en IP de Kubernetes de forma escalable y segura.
Modelo de redes de GKE: clústeres nativos de VPC
GKE implementa el modelo de red de Kubernetes mediante la red nativa de VPC, que es una función principal. Google Cloud
Este modelo usa intervalos de direcciones IP de alias. En un clúster nativo de VPC, Kubernetes configura las direcciones IP de los pods como intervalos de direcciones IP de alias en la interfaz de red virtual del nodo.
Esta implementación ofrece varias ventajas clave:
- Rutas nativas de VPC: las direcciones IP de los pods se pueden enrutar directamente en tu red de VPC. De esta forma, se simplifica el diseño de la red y se permite una comunicación directa y de baja latencia entre tus pods y otros recursos, como las instancias de Compute Engine y las de Cloud SQL. Google Cloud
- Conservar la cuota de rutas: al usar direcciones IP de alias para los pods, GKE no crea rutas estáticas personalizadas para cada nodo. De esta forma, se conserva la cuota de rutas de VPC, lo que supone una mejora significativa con respecto a los clústeres basados en rutas antiguas, y es importante para las implementaciones a gran escala.
- Mejorar la seguridad: el enrutamiento nativo de VPC te permite aplicar reglas de cortafuegos nativas de VPC directamente al tráfico de tus pods, lo que mejora la seguridad a nivel de red.
El modo nativo de VPC es el modo de red predeterminado y recomendado para todos los clústeres de GKE.
Por qué es fundamental una gestión eficaz de las direcciones IP
Para asegurarte de que tu clúster pueda escalar y mantener el estado de las aplicaciones, debes planificar tu espacio de direcciones IP de forma eficaz:
- Asegurar la escalabilidad: planifica los intervalos de direcciones IP de los nodos, los pods y los servicios de forma eficaz para evitar que se agoten las direcciones IP y permitir que tu clúster se escale sin necesidad de reestructurar la red, lo que podría provocar interrupciones.
- Garantizar la fiabilidad: evita que se solapen los intervalos de direcciones IP entre tu clúster de GKE y otras redes, como los entornos on-premise conectados a través de Cloud VPN. Si los intervalos se solapan, pueden producirse conflictos de enrutamiento, comportamientos impredecibles e interrupciones del servicio.
- Refuerza la seguridad: gestiona las direcciones IP de forma eficaz para reforzar la seguridad de la red. Define políticas de red de Kubernetes para controlar el flujo de tráfico entre pods y configura reglas de cortafuegos para aislar las cargas de trabajo a nivel de red.
Elegir un modelo de direccionamiento IP para un clúster
GKE admite varias configuraciones de pila de red para satisfacer tus requisitos de red, como las opciones de solo IPv4, de pila dual (IPv4 e IPv6) y de solo IPv6 (próximamente).
Solo IPv4 (pila única)
Esta es la configuración estándar y más habitual, en la que todos los componentes del clúster usan direcciones IPv4. Incluso en un modelo solo IPv4, GKE ofrece flexibilidad:
- Direcciones IP privadas de RFC 1918: usa intervalos de direcciones IP privadas de RFC 1918 (por ejemplo,
10.0.0.0/8) para tu clúster. - Direcciones IP públicas usadas de forma privada (PUPIs): si tu organización no tiene suficiente espacio de direcciones IP privadas, puedes usar intervalos de direcciones IP públicas para uso interno en tu red de VPC. Cuando uses PUPIs, debes configurar el agente de enmascaramiento de IP. Este agente realiza la traducción de direcciones de red de origen (SNAT) en el tráfico de salida de los pods. Sin SNAT, el tráfico de retorno a un pod que usa una PUPI se enruta a través de la red pública de Internet y falla. El agente de enmascaramiento de IP evita esto cambiando la dirección IP de origen de los paquetes salientes del PUPI del pod a la dirección IP interna del nodo. De esta forma, el tráfico de retorno se enruta correctamente al nodo y, a continuación, se reenvía al pod original.
Doble pila (IPv4 e IPv6)
Un clúster de doble pila usa los protocolos IPv4 e IPv6. GKE asigna una dirección IPv4 y una IPv6 a los nodos, los pods y los servicios de un clúster de doble pila. Este modelo es ideal para:
- Facilita una transición gradual a IPv6.
- Asegura la compatibilidad con cargas de trabajo preparadas para IPv6 y con clientes y servicios que solo usan IPv4.
Puedes habilitar la red de doble pila al crear un clúster o actualizar un clúster de pila única a doble pila.
Siguientes pasos
- Para obtener más información sobre las ventajas del modo de red predeterminado de GKE, consulta Acerca de los clústeres nativos de VPC.
- Para empezar, consulta cómo crear un clúster nativo de VPC.
- Para obtener información sobre cómo dimensionar los intervalos de direcciones IP de tu clúster, consulta Planificación de intervalos de direcciones IP para clústeres nativos de VPC.
- Si necesitas ayuda con problemas habituales, consulta el artículo sobre cómo solucionar problemas con el agente de enmascaramiento de IP.