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 completa 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 y las tareas de ejemplo comunes dentro de Google Cloud, consulta Roles de usuario y tareas comunes de GKE Enterprise.
Antes de continuar, asegúrate de estar familiarizado con los siguientes conceptos:
- Herramientas de redes básicas: incluidas las direcciones IP, CIDR, los firewalls y la traducción de direcciones de red (NAT).
- Componentes principales de Kubernetes: como clústeres, nodos, Pods y Services.
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 con 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 "una IP por Pod", GKE asigna a cada Pod una dirección IP única de un rango de CIDR de Pod asignado al nodo. En GKE, la red de VPC enruta de forma nativa las direcciones IP de Pod. Esta capacidad de enrutamiento integrada permite la comunicación directa entre los Pods, incluso en diferentes nodos, sin necesidad de traducción de direcciones de red (NAT). Todos los contenedores dentro de un solo Pod comparten la misma dirección IP y pueden comunicarse a través de
localhost.Services: GKE asigna a cada Service de Kubernetes una dirección IP virtual estable, (el
ClusterIP) de un rango de direcciones IP secundario dedicado. EsteClusterIPproporciona un extremo único y confiable para un grupo de Pods. Cuando envías tráfico alClusterIP, GKE lo balancea de cargas 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 tenant administrado por Google y usa su propio rango de direcciones IP internas. Este proyecto de tenant se conecta a tu red de VPC, lo que permite una comunicación segura entre el plano de control y los nodos en 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 Google Cloud balanceadores de cargas. 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 con el 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. |
| Service (ClusterIP) | GKE asigna a cada Service una dirección IP virtual estable
(ClusterIP) de 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 tenant administrado por Google. Este proyecto de tenant se conecta a tu red de VPC, por lo general mediante 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 direccionamiento IP de Kubernetes: El proyecto de Kubernetes de código abierto especifica que cada Pod recibe una dirección IP única. Todas las direcciones IP de Pod pueden comunicarse directamente sin traducción de direcciones de red (NAT). Este enfoque ayuda a garantizar un espacio de red plano en el que los Pods pueden comunicarse entre sí mediante sus direcciones IP asignadas.
Implementación de direccionamiento IP de GKE: GKE implementa el modelo de direccionamiento IP de Kubernetes en Google Cloud integrándose con las redes nativas de la VPC. Cuando creas un Pod, GKE asigna su dirección IP de 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 dentro de toda tu red de VPC. Esto permite la comunicación directa no solo entre los Pods, sino también con otros Google Cloud recursos, como las instancias de Compute Engine y las bases de datos de Cloud SQL. Del mismo modo, GKE administra las direcciones IP de
Servicede Kubernetes (comoClusterIPs) dentro de la red de VPC. Cuando creasLoadBalancerobjetos Service para la exposición externa, GKE aprovisiona Google Cloud balanceadores de cargas. Estos balanceadores de cargas usan direcciones IP públicas o internas de tu red de VPC. GKE usa Google Cloud's la infraestructura de redes y direccionamiento IP sólida de para implementar los conceptos de redes basadas en IP de Kubernetes de una manera escalable y segura
Modelo de redes de GKE: clústeres nativos de la VPC
GKE implementa el modelo de redes de Kubernetes mediante el uso de redes nativas de la VPC, que es una capacidad principal Google Cloud .
Este modelo usa rangos de direcciones IP de alias. En un clúster nativo de la VPC, Kubernetes configura las direcciones IP de Pod 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 Pod se pueden enrutar directamente dentro de tu red de VPC. Esto simplifica el diseño de la red y permite la comunicación directa y de baja latencia entre tus Pods y otros Google Cloud recursos, como las instancias de Compute Engine y las instancias de Cloud SQL.
- Conservar la cuota de ruta: 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 ruta de VPC, una mejora significativa en comparación con los clústeres basados en rutas heredados, y es importante para las implementaciones a gran escala.
- Mejorar 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 tu Pod, lo que mejora la seguridad a nivel de la red.
La VPC nativa es el modo de redes predeterminado y recomendado para todos los clústeres de GKE.
Por qué es fundamental la administración eficaz de direcciones IP
Para asegurarte de que tu clúster pueda escalar y mantener el estado de la aplicación, debes planificar tu espacio de direcciones IP de manera eficaz:
- Garantizar la escalabilidad: planifica los rangos de direcciones IP de nodo, Pod y Service de manera eficaz para evitar el agotamiento de las direcciones IP y permitir que tu clúster escale sin necesidad de una rearquitectura de red disruptiva.
- Garantizar la confiabilidad: Evita los 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 generar conflictos de enrutamiento, comportamiento impredecible e interrupciones del servicio.
- Fortalecer la seguridad: Administra las direcciones IP de manera eficaz para fortalecer la seguridad de la red. Define las políticas de red de Kubernetes para controlar el flujo de tráfico entre los Pods y configurar reglas de firewall para el aislamiento de la carga 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 solo IPv4, de pila doble (IPv4 e IPv6) y las próximas opciones 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 dentro de un modelo solo 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. Este enfoque ayuda a garantizar 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 listas para IPv6 y los clientes y servicios existentes solo 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?
- Para obtener más información sobre los beneficios del modo de redes predeterminado de GKE, consulta Acerca de los clústeres nativos de la VPC.
- Para comenzar, obtén información para crear un clúster nativo de la VPC.
- Para obtener orientación sobre el tamaño de los rangos de direcciones IP de tu clúster, consulta Planificación del rango de direcciones IP para clústeres nativos de la VPC.
- Si necesitas ayuda con problemas comunes, consulta Soluciona problemas del agente de enmascaramiento de IP.