Kubernetes en producción: límites de recursos que sí evitan caídas

Los límites de recursos en Kubernetes parecen simples hasta que un pod empieza a reiniciarse sin motivo aparente. En este repaso se comparan requests y limits mal calibrados con configuraciones que sostienen cargas variables, se muestran fragmentos de manifiestos y se explica cómo leer los eventos del scheduler y del kubelet para distinguir falta de memoria de throttling de CPU.

También se comentan los errores más comunes al copiar valores de un entorno de pruebas a producción y qué métricas conviene vigilar antes de tocar los números. El punto de partida suele ser el mismo: un nodo que empieza a mostrar latencia alta, pods que reinician en cadena y un panel de observabilidad donde el pico aparece justo cuando nadie estaba desplegando.

Antes de intervenir conviene mirar el estado de los nodos, los eventos del scheduler y la presión de recursos que reporta el kubelet. Distinguir un OOMKill de un throttling de CPU cambia por completo la decisión: en un caso el limit de memoria está por debajo de lo que el proceso realmente necesita, en el otro el contenedor está recibiendo menos ciclos de los que cree tener.

Un manifiesto con requests y limits razonables no se copia de un entorno a otro sin revisar. Las cargas en producción tienen ráfagas que las pruebas no reproducen, y los valores que funcionaban en un clúster pequeño dejan de servir cuando el tráfico se reparte distinto. La recomendación práctica es ajustar de a un recurso por vez, dejar correr la carga real y volver a leer las métricas antes del siguiente cambio.