Fallos reales de Kubernetes en producción: del plano de control al agotamiento de IP

Alguien planteó una pregunta sencilla: ¿qué va mal de verdad con Kubernetes en producción? Buscaba fallos reales, de esos que nunca aparecen en las guías de buenas prácticas ni en los diagramas de arquitectura de pizarra.

Las respuestas fueron testimonios directos de profesionales con experiencia de campo. Vistas en conjunto, revelan un patrón claro: la mayoría de los fallos en Kubernetes tienen su origen en decisiones muy humanas. Esto es lo que se rompió en la práctica.

1. Cuando el plano de control colapsa

Un ingeniero añadió por error unas 60 máquinas al grupo de servidores de la API en lugar de al grupo de nodos de trabajo. etcd "se enfadó de verdad y colapsó bajo su propio peso".

Eso describe el radio de impacto operativo más que un simple error de software. Lo curioso es que las cargas de trabajo siguieron funcionando. No se reprogramaban, no se autorreparaban ni escalaban, pero continuaban atendiendo tráfico en su último estado conocido.

Casi nadie comprende esto hasta que lo ve en directo. Kubernetes tolera esta desconexión de un modo peculiar: el plano de datos sigue activo mientras el plano de control arde, al menos durante un tiempo. La recuperación obligó a restaurar etcd a mano desde su propio directorio de datos y a unir de nuevo los miembros, algo que nadie calificaría como un martes divertido.

2. Agotamiento de direcciones IP

"Se creó un tamaño de subred para k8s demasiado pequeño". Esa única frase resume semanas de dolor. Los clústeres se quedan sin direcciones IP, los pods no consiguen programarse, los nodos escalan pero no pueden asociar ENIs, las reglas de firewall exigen una reescritura y los equipos de redes acaban arrastrados a reuniones urgentes.

Otro comentario sentenció sin rodeos:

No usar IPv6 es el primer error.

Quizá sonara sarcástico, pero la frustración de fondo es real. Otro usuario relató que desactivar la asignación en caliente de ENI en EKS liberó miles de direcciones IP, el típico aprendizaje que solo asimilas cuando ves que los nodos no pueden escalar durante un incidente. El cálculo de direcciones IP parece aburrido hasta que producción entra en modo de solo lectura.

3. Límites de tasa en DockerHub: el DDoS autoinfligido

"Los límites de tasa en DockerHub son un dilema clásico del huevo o la gallina". La secuencia es la siguiente:

• Escalas nodos.
• Los nodos descargan imágenes.
• DockerHub limita las peticiones.
• Los pods fallan.
• El escalador automático añade más nodos.
• Esos nodos nuevos también fallan.

Acabas provocando un ataque DDoS contra tu propia cadena de suministro. Un ingeniero describió cómo saturó su propio registro interno de contenedores durante el despliegue de un grupo de nodos. Kubernetes amplifica los fallos porque los despliegues son eventos multiplicativos. Si no has configurado un registro privado, una caché de paso intermedio, un mirror en ECR/ACR/GCR, Harbor o un mecanismo de intercambio de imágenes, tarde o temprano lo aprenderás por las malas.

4. etcd es pequeño, hasta que deja de serlo

etcd rara vez aparece como el villano en los esquemas de arquitectura, pero es el corazón del clúster. Cuando va lento, todo el plano de control se resiente, la programación de pods se retrasa y las llamadas a la API se bloquean. Cuando se sobrecarga, acabas restaurando desde snapshots y rezando. La mayoría de los equipos no monitoriza etcd con detalle hasta su primera caída importante, y ese tema recorre toda la conversación.

5. La planificación de capacidad no es opcional

Alguien admitió sin darle mayor importancia:

Mala planificación de capacidad por nuestra parte.

Es algo habitual. Los clústeres se diseñan para la escala de hoy, y seis meses después hay más namespaces, servicios y pods, mayor consumo de direcciones IP y más carga en el plano de control. A medida que Kubernetes se acerca a sus límites, se degrada de forma gradual, y esa degradación progresiva resulta mucho más difícil de diagnosticar que una explosión repentina.

6. La lección sobre el registro: cachea todo

Una respuesta mencionaba haber añadido caché de imágenes en ECR tras sufrir una mala experiencia, y otra señalaba que instalar Harbor ayudó de forma decisiva. El patrón es evidente: a gran escala, las dependencias externas se transforman en puntos únicos de fallo internos. Tu clúster puede estar sano mientras tu registro falla, y a Kubernetes le da igual de quién sea la culpa. Solo mostrará "ImagePullBackOff".

7. Supuestos sobre IPv4

Hay una buena razón por la que alguien comentó:

Si vas a desplegar un clúster y crees que "un /16 no será suficiente", entonces sí, usa IPv6

Muchos equipos asumen que un /24 basta, que un /22 es generoso y que un /16 resulta inmenso. Luego aumenta la densidad de pods por nodo, se asignan ENIs secundarias, los grupos en espera reservan direcciones IP y los sidecars duplican el número de pods. Las redes son el terreno donde el optimismo nativo de la nube choca contra los límites físicos.

8. El origen no suele ser Kubernetes

Al analizar todo esto en conjunto, muy pocas de las historias dramáticas se deben a errores de Kubernetes. Responden a malas configuraciones, planos de control sobredimensionados sin equilibrio, subredes insuficientes, dependencias de registros remotos y puntos ciegos en la capacidad. En casi todos los casos Kubernetes hizo exactamente lo que se le ordenó, y fueron las personas quienes le dieron las órdenes equivocadas.

9. Brechas de observabilidad

La pregunta original indagaba sobre las lagunas en la observabilidad, y la mayor parte de los fallos descritos tenían poco que ver con las aplicaciones. Eran restricciones de red, colapsos del plano de control, cuellos de botella de infraestructura y límites en los registros. Nada de eso figura en el panel de tu APM. Aparece en las métricas de etcd, el uso de subredes en la nube, la asignación de ENIs, la latencia de descarga de imágenes y la saturación del servidor de la API; por tanto, si solo vigilas la CPU y la memoria de los pods, no lo verás venir.

10. La lección que a nadie le gusta

Kubernetes ofrece una gran potencia, y esa potencia multiplica el radio de impacto. A gran escala, un fallo menor se convierte en 60 servidores de API mal configurados, miles de direcciones IP agotadas o el bloqueo total de un registro. El sistema en sí es determinista, pero sus consecuencias a gran escala resultan difíciles de prever.

¿Qué falla realmente?

De forma resumida, la conversación se reduce a seis causas:

1. Sobrecarga del plano de control
2. Agotamiento de IP o subred
3. Cuellos de botella en el registro
4. Errores de cálculo en la capacidad
5. Supuestos erróneos sobre la red
6. Despliegues con exceso de confianza

La indentación de YAML y las caídas aisladas de contenedores apenas se mencionaron. Casi todo fue pura matemática de infraestructura.

Por qué fallan los clústeres en producción

En producción, Kubernetes rara vez falla por un exploit de día cero exótico o un error en el planificador. Falla porque:

• Alguien asumió que el clúster no crecería tan rápido.
• Alguien subestimó el cálculo de direcciones IP.
• Alguien escaló grupos de nodos sin cachear imágenes.
• Alguien añadió máquinas al grupo equivocado.
• Alguien no modeló los despliegues en el peor escenario posible.

El clúster no hizo más que amplificar esas decisiones. Quizá por eso un participante llamó a estos relatos "historias cortas de terror para la gente de K8s". Una vez que has visto desarrollarse uno de estos incidentes en vivo, un simple comando kubectl apply nunca vuelve a verse igual.