¿Cómo asigna Kubernetes las direcciones IP?

Kubernetes asigna direcciones IP usando notación CIDR para dividir la red del cluster en rangos específicos para nodos, pods y servicios. El kube-controller-manager reparte un rango Pod CIDR a cada nodo cuando se une al cluster, y los plugins CNI (como Calico o Flannel) implementan esa asignación en cada contenedor. Los pods obtienen IPs dentro del rango del nodo, mientras que los servicios reciben IPs de un rango separado definido en la configuración del cluster.

¿Qué es CIDR en Kubernetes?

CIDR (Classless Inter-Domain Routing) es una notación que define un rango de direcciones IP con una máscara de red. En lugar de listar cada dirección individual, usás una sola cadena como 10.0.0.0/16 para representar 65,536 direcciones. El número después de la barra indica cuántos bits están “fijos” (la red) y cuántos están libres para asignar (los hosts).

Ponele que tu cluster es un edificio de apartamentos. En lugar de decir “el piso 5 tiene apartamentos 501, 502, 503, 504, 505”, simplemente decís “el piso 5 usa el rango 500-599”. Es exactamente lo mismo, pero mucho más compacto.

Cómo leer la notación CIDR

10.0.0.0/16 significa: red base 10.0.0.0, con 16 bits fijos. Los 16 bits restantes (de 32 totales en IPv4) están disponibles para direcciones, lo que da 2^16 = 65,536 direcciones posibles.

10.100.1.0/24 es más chico: 24 bits fijos, 8 bits libres. Eso son 2^8 = 256 direcciones, perfectas para un nodo individual.

Si sumás mal los rangos, pisás direcciones que otro nodo ya usa y ahí te das cuenta de que trabajaste sin red toda la noche. Por eso Kubernetes pre-calcula esto.

La jerarquía de IPs: Cluster → Nodo → Pod

Cuando creás un cluster, definís un Cluster CIDR grande. Ponele 10.0.0.0/16. Es el “cofre” de donde salen todas las IPs de pods. Pero un cluster tiene múltiples nodos, y si todos comparten el mismo rango sin organización, el caos llega rápido.

Acá entra el kube-controller-manager. Cuando un nodo se suma al cluster, el controller dice “Bienvenido, tu rango personal es 10.0.1.0/24“. Otro nodo recibe 10.0.2.0/24. Otro 10.0.3.0/24. Cada nodo tiene su propia “porción de pastel”. Relacionado: ejecutar servicios en tu red local.

Cómo funciona en la práctica

Vos deployás un pod. El kubelet en el nodo ve que necesita una IP. Mira su rango asignado (10.0.1.0/24) y le dice al CNI plugin: “Necesito una IP de acá”. El CNI plugin agarra la primera disponible (típicamente 10.0.1.2, porque .0 es la red y .1 es la puerta de enlace) y la configura en el contenedor.

Luego deployás un segundo pod. Same thing: siguiente IP del rango, 10.0.1.3. Seguís hasta que agotás el rango (256 direcciones en un /24), y entonces… bueno, ese nodo está lleno. Si querés más pods, necesitás un nodo más.

Lo que no queda claro en muchos documentos es que esto es semi-automático. El controller crea el rango, pero el CNI hace el trabajo sucio de verdad.

Pod CIDR vs Service CIDR: las dos redes del cluster

Acá viene el punto donde muchos se pierden. Tu cluster en realidad tiene DOS redes paralelas, y NO pueden solaparse.

Pod CIDR: Rango de IPs para contenedores reales. Ejemplos: 10.100.0.0/16. Si deployás 100 pods en 5 nodos, cada uno obtiene una IP de acá. Es routable dentro del cluster.

Service CIDR: Rango de IPs para servicios (puntos de entrada virtuales). Típicamente 10.96.0.0/20 según la documentación oficial de Kubernetes. Un servicio no es un pod real. Es una abstracción. Cuando creás un Service de tipo ClusterIP, Kubernetes asigna una IP de este rango. Esa IP es solo routable dentro del cluster.

¿Por qué dos redes? Porque un pod es efímero (muere y nace, cambia IP). Un servicio es el “nombre” estable. Vosotros hablás con el servicio (my-app:80), Kubernetes internamente lo enruta al pod de turno.

Si tu Pod CIDR es 10.100.0.0/16 y tu Service CIDR también es 10.100.0.0/16 (o se superponen), tenés un quilombo. El router no sabe si el tráfico va a un pod o a un servicio. Esto te arruina todo.

Cómo el CNI plugin asigna IPs realmente

El CNI (Container Network Interface) no es una mágica. Es un estándar de plugins que Kubernetes usa para delegar el networking. Cuando vos deployás un pod, esto pasa en orden: Para más detalles técnicos, mirá seguridad en clusters y comunicación privada.

• Kubelet recibe el request de crear un pod
• Kubelet llama al CRI (Container Runtime Interface, ej. containerd) para crear el contenedor
• El CRI crea el contenedor sin IP
• El CRI llama al CNI plugin: “Necesito una IP para este contenedor, en el rango 10.0.1.0/24”
• El CNI plugin asigna una IP disponible, configura interfaces de red, routing, todo
• El pod arranca con IP asignada

La clave es que Kubernetes NO asigna IPs directamente. Le dice al nodo “acá está el rango, vos sos responsable”. El CNI plugin es quien decide la implementación: overlay network, BGP routing, lo que sea.

Calico, Flannel, Cilium son tres formas diferentes de resolver el mismo problema. Todas respetan el CIDR que Kubernetes definió, pero lo hacen de forma distinta.

Calico vs Flannel: dos formas de distribuir IPs

Estos son los dos plugins más usados. La elección depende del tamaño de tu cluster y cuánto te importa la velocidad.

Flannel: simple y directo

Flannel usa una overlay network con VXLAN. Imaginate que encapsula cada paquete del pod dentro de otro paquete que viaja entre nodos. Es como empacar un regalo dentro de otro regalo.

Ventajas: setup fácil, no necesitas routers complejos, funciona en cualquier infraestructura. Desventajas: cada paquete tiene overhead de encapsulación, es más lento, usa más CPU en los nodos.

Flannel es ideal para clusters pequeños (hasta 20 nodos) o si tu infraestructura no te permite routing BGP nativo.

Calico: BGP routing, más rápido

Calico usa BGP (Border Gateway Protocol) para publicar rutas de pods entre nodos. En lugar de encapsular, Calico hace que el router “sepa” dónde están los pods. Es como tener un mapa actualizado en lugar de envolver paquetes.

Calico también ofrece Network Policies nativos, que Flannel no tiene. Si necesitás firewall entre pods, Calico lo hace. Flannel no. Más contexto en orquestación de cargas de trabajo complejas.

Ventajas: más rápido (sin encapsulación), escalable a clusters grandes (100+ nodos), Network Policies. Desventajas: setup más complejo, necesitás BGP en tu infraestructura (o IP-in-IP como fallback).

Tabla comparativa

Según el análisis comparativo de SUSE sobre CNI providers, Calico es la opción más escalable para producción, pero Flannel sigue siendo útil si tu caso de uso no requiere complejidad.

Errores comunes al planificar CIDR

Agotamiento de IPs por cluster pequeño

Configurás tu cluster con Pod CIDR 10.0.0.0/24 porque “solo son 4 nodos”. Eso son 256 direcciones totales. Parece mucho, ¿no? Salvo que crezcas a 10 nodos y de repente tienes 25 pods por nodo. Ya agotaste el rango hace un mes. Para expandir, necesitás recrear el cluster (o usar IP expansion, que es complicado).

Lección: asigná un Pod CIDR generoso. 10.0.0.0/16 (65,536 direcciones) es el estándar. Ocupás lo que necesitás, el resto está disponible para crecer.

Solapamiento de rangos con redes externas

Tu cluster en AWS usa Pod CIDR 10.0.0.0/16. Tu VPC también usa 10.0.0.0/16. ¿Ves el problema? El router no sabe si un paquete a 10.0.5.3 va a un pod o a un EC2 en la VPC. Tráfico perdido garantizado.

Revisá la documentación de Google Cloud GKE sobre flexible Pod CIDR y Azure AKS sobre planificación de IPs: ambas insisten en auditar qué rangos están en uso en tu infraestructura antes de crear el cluster.

Mala estimación de densidad de pods

Estimaste 10 pods por nodo. Cada nodo recibe /25 (128 IPs). Pero después agregás 3 sidecars a cada pod, y de repente tenés 40 pods por nodo. Ya corriste fuera de IPs en el nodo (máximo 128). Los nuevos pods quedan en Pending.

Ojo: la densidad depende de tu caso de uso. Microservicios pequeños pueden ser 30+ pods por nodo. Workloads pesadas pueden ser 2-3. Calculá peor caso, no caso promedio.

Configuración práctica: cálculo de rangos CIDR

Acá viene lo que importa de verdad. Vos necesitás elegir qué CIDR asignarle a tu cluster. La fórmula es simple.

La matemática básica

Cantidad de direcciones = 2^(32 - prefijo)

Ejemplos:

• /16 = 2^(32-16) = 2^16 = 65,536 direcciones
• /20 = 2^(32-20) = 2^12 = 4,096 direcciones
• /24 = 2^(32-24) = 2^8 = 256 direcciones

Para un cluster, necesitás:

IPs totales = (Nodos planificados × Pods por nodo) + margen de crecimiento Esto se conecta con lo que analizamos en plataformas cloud para Kubernetes.

Ejemplo real: cluster de 10 nodos, 30 pods por nodo. Total = 300 pods. Agregás 50% de margen (porque siempre crecés). Necesitás mínimo 450 IPs. El Pod CIDR mínimo sería /23 (512 direcciones). Pero mejor usá /16 (65,536) para no quedarte corto en 2 años.

Para Service CIDR, tipicamente /20 (4,096 servicios) es suficiente. Casi nadie tiene 4,000 servicios.

Checklist antes de crear el cluster

• Revisá qué rangos ya están en uso en tu infraestructura (VPC, subnets, on-premise networks)
• Elegí Pod CIDR que NO solape con nada de eso. Típicamente algo en 10.0.0.0/8, 172.16.0.0/12, o 192.168.0.0/16 que no esté en uso
• Elegí Service CIDR dentro del pod CIDR (ej. si Pod es 10.0.0.0/16, Service podría ser 10.96.0.0/20). O completamente separado (ej. 172.30.0.0/16). Lo importante es que NO se solapen
• Documentá tu decisión. Dentro de 6 meses alguien va a preguntar “¿Por qué usamos este rango?” y vos querés tener la respuesta

Preguntas Frecuentes

¿Qué es CIDR y cómo funciona en Kubernetes?

CIDR es una notación compacta para definir rangos de IPs. En Kubernetes, se usa para dividir la red del cluster en subredes: una para pods (routable), otra para servicios (solo dentro del cluster). El kube-controller-manager automáticamente asigna un sub-rango a cada nodo dentro del Pod CIDR.

¿Cuál es la diferencia entre Pod CIDR y Service CIDR?

Pod CIDR es la red de contenedores reales (pods que corren en los nodos). Service CIDR es para servicios virtuales (puntos de entrada estables que enrutan a pods). Los pods nacen y mueren (IPs cambian), los servicios son estables. Nunca deben solaparse.

¿Cómo configura el kube-controller-manager los rangos de IPs?

Vos defines el Pod CIDR en la creación del cluster. El controller automáticamente divide ese rango en sub-rangos (típicamente /24 o /25) y asigna uno a cada nodo cuando se suma. El nodo después usa eso para asignar IPs a sus pods.

¿Qué plugin CNI debería usar, Calico o Flannel?

Flannel si tu cluster es pequeño (menos de 20 nodos) y setup simple te importa más que velocidad. Calico si planeás crecer (100+ nodos) y necesitás Network Policies. Calico es el estándar en producción. Flannel es bueno para testing y demos.

¿Qué pasa si me quedo sin IPs en el Pod CIDR?

Los nuevos pods quedan en estado Pending. No hay errores ruidosos, simplemente nunca se scheduleán. El kubelet intenta asignar una IP, no encuentra, espera. Es una muerte silenciosa. Por eso sobre-estimá siempre: mejor rangos grandes que no usás que quedarte corto.

Conclusión

Kubernetes asigna IPs de forma automática pero controlada: tu cluster define un rango grande (Pod CIDR), se divide en sub-rangos por nodo (cada nodo recibe su porción), y dentro de cada nodo, el CNI plugin hace la asignación real a cada pod. Todo está organizado en CIDR, una notación matemática compacta que te permite escalar sin caos.

Lo que muchos documentos no destacan es que esto requiere planning. No podés simplemente “crear un cluster” sin pensar en qué rangos usás. Si solapás con tu VPC, o si elegís mal la densidad de pods, terminás con un cluster que no puede crecer.

El takeaway: antes de crear tu cluster, auditá tu infraestructura, elegí Pod CIDR y Service CIDR que no solapen con nada, sobreestimá IPs, y documentá por qué elegiste lo que elegiste. Luego dejá que el controller y el CNI hagan su magia.

Fuentes

• How Kubernetes Actually Hands Out IPs – Dev.to
• Kubernetes Services – Documentación oficial
• Google Kubernetes Engine – Flexible Pod CIDR
• Comparación de CNI Providers – SUSE Rancher Blog
• Azure AKS – Planificación de direcciones IP