Información sobre el direccionamiento IP en GKE

Para compilar clústeres de Google Kubernetes Engine (GKE) escalables y seguros, debes administrar de manera eficaz el direccionamiento IP. En este documento, se proporciona una descripción general integral de cómo GKE usa las direcciones IP para la comunicación del clúster, los modelos de redes compatibles y las prácticas recomendadas para la administración eficaz de direcciones IP.

Este documento está dirigido a arquitectos de nube y especialistas en herramientas de redes que diseñan la red para su organización. Para obtener más información sobre los roles comunes y las tareas de ejemplo en Google Cloud, consulta Roles de usuario y tareas comunes de GKE Enterprise.

Antes de continuar, asegúrate de conocer los siguientes conceptos:

Cómo las direcciones IP conectan los componentes de GKE

GKE se basa en el modelo de redes de Kubernetes, que requiere que cada componente tenga una dirección IP distinta para la comunicación. En las siguientes secciones, se describe cómo GKE asigna y usa direcciones IP para 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 rango 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 el acceso a Internet saliente.

  • Pods: Siguiendo el modelo de Kubernetes "IP por Pod", GKE asigna a cada Pod una dirección IP única de un rango CIDR de Pod 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 los Pods, incluso entre diferentes nodos, sin necesidad de traducción de direcciones de red (NAT). Todos los contenedores dentro 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 rango de direcciones IP secundarias dedicado. Este ClusterIP proporciona un extremo único y confiable para un grupo de Pods. Cuando envías tráfico al ClusterIP, GKE lo balancea automáticamente a un Pod en buen estado dentro de ese Service.

  • Plano de control: En los clústeres privados, el plano de control reside dentro de un proyecto de usuario administrado por Google y usa su propio rango de direcciones IP internas. Este proyecto de usuario 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. Por lo general, esta conexión usa Private Service Connect.

  • Balanceadores de cargas: Para exponer aplicaciones a Internet o dentro de tu red de VPC, puedes configurar GKE para que use balanceadores de cargas deGoogle Cloud . Los balanceadores de cargas externos usan direcciones IP públicas. Los balanceadores de cargas internos usan direcciones IP internas del rango de subred principal de tu red de VPC.

En la siguiente tabla, se resume cómo GKE asigna direcciones IP a los componentes del clúster:

Componente Cómo se asignan las direcciones IP
Node GKE asigna una dirección IP interna a cada nodo. GKE asigna esta dirección IP del rango 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 rango de CIDR de Pod asignado a su nodo.
Servicio (ClusterIP) GKE asigna a cada Service una dirección IP virtual estable (ClusterIP) desde un rango 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 rango de direcciones IP internas dentro de un proyecto de arrendatario administrado por Google. Este proyecto de arrendatario se conecta a tu red de VPC, por lo general, a través de Private Service Connect.
Balanceador de cargas Los balanceadores de cargas externos usan direcciones IP públicas. Los balanceadores de cargas internos usan direcciones IP internas del rango de direcciones IP principal de la subred del clúster.

Direccionamiento IP de Kubernetes y la implementación de GKE

Para usar GKE de manera eficaz, debes comprender las diferencias entre el modelo de redes abstracto de Kubernetes y cómo GKE implementa este modelo en Google Cloud.

  • Modelo de direcciones IP de Kubernetes: El proyecto de código abierto de 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). Esto garantiza un espacio de red plano en el que los Pods pueden comunicarse entre sí con las direcciones IP asignadas.

  • Implementación del direccionamiento IP de GKE: GKE implementa el modelo de direccionamiento IP de Kubernetes en Google Cloud integrándose con las redes nativas de VPC. Cuando creas un Pod, GKE asigna su dirección IP desde un rango de direcciones IP de alias de VPC. Esto hace que la dirección IP de cada Pod se pueda enrutar de forma nativa en toda tu red de VPC. Esto permite la comunicación directa no solo entre los Pods, sino también con otros recursos de Google Cloud , como las instancias de Compute Engine y las bases de datos de Cloud SQL. Del mismo modo, GKE administra las direcciones IP de Service de Kubernetes (como ClusterIPs) dentro de la red de VPC. Cuando creas objetos Service LoadBalancer para la exposición externa, GKE aprovisiona balanceadores de cargasGoogle Cloud . Estos balanceadores de cargas usan direcciones IP públicas o internas de tu red de VPC. GKE utiliza la sólida infraestructura de redes y direccionamiento IP de Google Cloudpara implementar los conceptos de redes basadas en IP de Kubernetes de una manera escalable y segura.

Modelo de red de GKE: clústeres nativos de la VPC

GKE implementa el modelo de redes de Kubernetes con redes nativas de VPC, que es una capacidad Google Cloud fundamental.

Este modelo usa rangos de direcciones IP de alias. En un clúster nativo de la VPC, Kubernetes configura las direcciones IP de los Pods como rangos de direcciones IP de alias en la interfaz de red virtual del nodo.

Esta implementación ofrece varias ventajas clave:

  • Capacidad de enrutamiento nativa de la VPC: Las direcciones IP de los Pods se pueden enrutar directamente dentro de tu red de VPC. Esto simplifica el diseño de la red y permite una comunicación directa y de baja latencia entre tus Pods y otros recursos de Google Cloud , como instancias de Compute Engine y de Cloud SQL.
  • Conservación de la cuota de rutas: Cuando se usan direcciones IP de alias para los Pods, GKE no crea rutas estáticas personalizadas para cada nodo. Esto conserva tu cuota de rutas de la VPC, lo que representa una mejora significativa en comparación con los clústeres heredados basados en rutas, y es importante para las implementaciones a gran escala.
  • Mejora la seguridad: La capacidad de enrutamiento nativa de la VPC te permite aplicar reglas de firewall nativas de la VPC directamente al tráfico de tus Pods, lo que mejora la seguridad a nivel de la red.

El modo de redes nativo de la VPC es el modo predeterminado y recomendado para todos los clústeres de GKE.

Por qué es fundamental una administración eficaz de las direcciones IP

Para garantizar que tu clúster pueda escalar y mantener el estado de la aplicación, debes planificar tu espacio de direcciones IP de manera eficaz:

  • Garantiza la escalabilidad: Planifica de manera eficaz los rangos de direcciones IP de nodos, Pods y objetos Service para evitar el agotamiento de las direcciones IP y permitir que tu clúster se escale sin necesidad de una reestructuración disruptiva de la red.
  • Garantiza la confiabilidad: Evita rangos de direcciones IP superpuestos entre tu clúster de GKE y otras redes, como los entornos locales conectados a través de Cloud VPN. Los rangos superpuestos pueden provocar conflictos de enrutamiento, comportamientos impredecibles e interrupciones del servicio.
  • Fortalecer la seguridad: Administra las direcciones IP de manera eficaz para fortalecer la seguridad de la red. Define políticas de red de Kubernetes para controlar el flujo de tráfico entre los Pods y configura reglas de firewall para el aislamiento de cargas de trabajo a nivel de la red.

Elige un modelo de direccionamiento IP para tu clúster

GKE admite varias configuraciones de pila de red para satisfacer tus requisitos de redes, incluidas las opciones de solo IPv4, de pila doble (IPv4 y IPv6) y las próximas opciones de solo IPv6.

Solo IPv4 (pila única)

Esta es la configuración estándar y más común, en la que todos los componentes del clúster usan direcciones IPv4. Incluso en un modelo solo de IPv4, GKE proporciona flexibilidad:

  • Direcciones IP privadas de RFC 1918: Usa rangos de direcciones IP privadas de RFC 1918 (por ejemplo, 10.0.0.0/8) para tu clúster.
  • Direcciones IP públicas de uso privado (PUPI): Si tu organización no tiene suficiente espacio de direcciones IP privadas, puedes usar rangos de direcciones IP públicas para uso interno dentro de tu red de VPC. Cuando usas PUPI, 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 saliente de los Pods. Sin SNAT, el tráfico de retorno a un Pod que usa una PUPI se enruta a través de Internet pública y falla. El agente de enmascaramiento de IP evita esto cambiando la dirección IP de origen de los paquetes salientes de la PUPI del Pod a la dirección IP interna del nodo. Esto garantiza que el tráfico de retorno se enrute correctamente de vuelta al nodo y, luego, se reenvíe al Pod original.

Pila doble (IPv4 e IPv6)

Un clúster de pila doble usa los protocolos IPv4 e IPv6. GKE asigna una dirección IPv4 y una IPv6 a los nodos, los Pods y los Services en un clúster de pila doble. Este modelo es ideal para lo siguiente:

  • Facilitar una transición gradual a IPv6
  • Garantizar la compatibilidad con las cargas de trabajo preparadas para IPv6 y los clientes y servicios existentes solo para IPv4

Puedes habilitar las redes de pila doble cuando creas un clúster o puedes actualizar un clúster existente de pila única a pila doble.

¿Qué sigue?