Límites de Kubernetes que todo equipo DevOps debe conocer antes de escalar a producción

Hay una idea peligrosa que se repite en muchos equipos: pensar que un clúster está listo porque "funciona". Funciona en staging, funciona con tres servicios, funciona el día del demo. Pero un clúster que funciona no es lo mismo que un clúster diseñado para producción. La diferencia casi siempre está en un terreno que pocos revisan a tiempo: los límites por defecto de Kubernetes.

Kubernetes es flexible, pero no es infinito. Detrás de cada componente hay topes —algunos del API server, otros de etcd, otros del kubelet, otros del propio sistema de nombres— que rara vez se documentan en una runbook interna y que terminan apareciendo justo cuando el clúster crece. El resultado típico: despliegues que fallan sin causa evidente, costos que se disparan, troubleshooting eterno y decisiones de arquitectura que hay que rehacer bajo presión.

Este artículo recorre los límites que más impacto tienen en operación real y, sobre todo, explica por qué importan.

Por qué los límites de Kubernetes no son un detalle técnico

Los límites de Kubernetes no son trivia para entrevistas. Son restricciones que condicionan la arquitectura del clúster desde el primer día.

Tomemos el ejemplo más conocido. La documentación oficial define que Kubernetes está pensado para escalar dentro de un marco concreto: no más de 110 pods por nodo, no más de 5.000 nodos, no más de 150.000 pods totales y no más de 300.000 contenedores totales por clúster. No son números arbitrarios: reflejan el punto hasta el cual el control plane, el scheduler y la red mantienen un comportamiento predecible.

Cuando un equipo ignora estos topes, no recibe un error claro que diga "te pasaste". Lo que recibe es latencia creciente en el API server, scheduling lento, addons que se reinician por consumo de memoria y un clúster que se vuelve difícil de operar. El límite no desaparece por no conocerlo; simplemente se manifiesta como un incidente.

Lo mismo aplica a la capa de almacenamiento. Kubernetes guarda todo el estado del clúster en etcd, y etcd tiene sus propios límites: por defecto, el tamaño máximo de cualquier solicitud es de 1,5 MiB, y el tamaño de la base de datos arranca en 2 GB, con 8 GB como máximo sugerido. Si etcd se llena, no es "un servicio más" el que se cae: es la memoria del clúster entero.

No todos los límites son iguales

Un error frecuente es tratar todos los límites como si vinieran del mismo lugar. No es así, y entender de dónde sale cada uno cambia la forma de diagnosticar problemas.

• Límites del API server. El tope de 1 MiB para Secrets y ConfigMaps individuales lo impone el API server, precisamente para evitar que objetos enormes saturen su memoria y la del kubelet. La documentación oficial lo declara de forma explícita para Secrets.
• Límites de etcd. El tope real de 1,5 MiB por solicitud es de etcd. Por eso un objeto que parece estar "dentro del límite" puede ser rechazado: las anotaciones, sumadas al resto del objeto, empujan el total por encima del máximo.
• Límites de metadatos y DNS. El total de anotaciones por objeto está limitado a 256 KiB (262.144 bytes). Las claves de labels y anotaciones admiten hasta 63 caracteres, y el prefijo opcional, hasta 253. Los nombres de objetos siguen reglas de DNS: subdominio (253 caracteres) para recursos como Pods, etiqueta (63 caracteres) para recursos como Services.
• Límites del kubelet y del nodo. Aquí viven valores operativos como terminationGracePeriodSeconds (30s por defecto) o los umbrales de eviction —por ejemplo, memory.available en 100Mi o nodefs.available en 10%— que determinan cuándo el kubelet empieza a expulsar pods.

Parecen detalles menores, pero un nombre demasiado largo o una anotación que crece sin control puede romper un Helm chart, un operador o una automatización completa. Y lo hará de forma intermitente, que es la peor forma de fallar.

Tabla de referencia rápida

Para tener todo en un solo vistazo, esta tabla resume los valores por defecto del proyecto upstream y de dónde proviene cada límite. Recuerda que algunos cambian según proveedor, versión o CNI (lo vemos más abajo).

Los valores por defecto no son los valores recomendados

Este es quizá el malentendido más caro. Un valor por defecto es un punto de partida seguro y conservador, no una recomendación para producción.

El límite de 1 MiB en Secrets y ConfigMaps lo ilustra bien. Técnicamente puedes acercarte a ese tope, pero la práctica recomendada es mantener estos objetos mucho más pequeños —idealmente por debajo de 100–200 KiB— para reducir la presión sobre etcd y acelerar el arranque de los pods. El límite te dice qué es posible; la buena práctica te dice qué es sano.

Lo mismo ocurre con etcd: 2 GB es el valor por defecto, pero rara vez es el valor con el que quieres operar un clúster grande sin haber planificado compactación, defragmentación y monitoreo del tamaño de la base de datos.

Algunos límites cambian en servicios administrados

Si tu clúster corre en EKS, GKE o AKS, hay un matiz importante: varios de estos límites no aplican igual que en un clúster autogestionado.

El caso más claro es el de pods por nodo. El valor de 110 corresponde al comportamiento por defecto del proyecto upstream, pero los proveedores lo redefinen:

• En Amazon EKS, el máximo de pods por nodo suele estar atado a la capacidad de ENI del tipo de instancia, y con frecuencia es bastante menor a 110.
• En GKE Standard, puede llegar hasta 256 pods por nodo.
• En Azure AKS, depende del modo de CNI configurado.

La conclusión operativa es directa: no asumas que el número "oficial" es el número de tu entorno. Verifica siempre contra la documentación del proveedor, el tipo de instancia y el plugin de red que estás usando. Lo mismo aplica a distribuciones específicas —por ejemplo, OpenShift establece PodPidsLimit en 4096 por defecto, en lugar del valor sin límite del upstream—. Afirmar que "Kubernetes funciona igual en todas partes" es exactamente el tipo de suposición que genera incidentes.

Buenas prácticas para equipos DevOps y Platform Engineering

Conocer los límites es el primer paso. El segundo es construir una operación que no dependa de que cada ingeniero los recuerde de memoria.

1. Documenta los límites como estándar interno. Pods por nodo, tamaño máximo de Secrets, comportamiento de etcd y convenciones de nombres deberían vivir en un estándar de plataforma, no en la cabeza de una persona.
2. Valida en CI/CD, no en producción. Políticas de admisión y validación de manifiestos pueden frenar un ConfigMap demasiado grande o un nombre inválido antes del despliegue.
3. Trata la observabilidad como un sistema de alerta temprana. Monitorea el tamaño de la base de datos de etcd, los pods por nodo y la latencia del API server para detectar cuándo el clúster se acerca a un límite, no cuando ya lo cruzó.
4. Diseña el clúster con la capacidad como variable explícita. Decide pods por nodo y nodos por clúster a partir de límites reales —incluidos los del proveedor— y no del crecimiento accidental.
5. Mantén los objetos pequeños. Secrets, ConfigMaps y anotaciones livianos reducen la carga sobre etcd y el API server, y hacen el clúster más estable y más barato de operar.

Esto es justamente lo que aporta una práctica madura de Platform Engineering: convertir el conocimiento disperso en estándares, automatización y guardarraíles que escalan con el equipo.

Conclusión

La madurez con Kubernetes no se mide por cuántos workloads se despliegan, sino por cuán bien se entiende el comportamiento del clúster bajo carga. Los límites de pods, etcd, Secrets, DNS y kubelet no son obstáculos: son la información que permite diseñar para escalar en lugar de improvisar y corregir.

Un clúster preparado para producción es uno donde los límites están entendidos, monitoreados y traducidos en estándares operativos. Todo lo demás es una falla esperando el momento de aparecer.