Solución de Problemas Comunes de Cuellos de Botella de Rendimiento en Kubernetes

Los problemas de rendimiento de Kubernetes rara vez se anuncian como "Kubernetes es lento". Ves un despliegue que se cuelga, una API que de repente devuelve errores 5xx, una cola que deja de drenar, o pods que parecen saludables mientras los usuarios se quejan de latencia. El clúster es solo una parte de esa historia, pero es la parte que puedes inspeccionar con un conjunto consistente de comandos.

El truco es evitar saltar directamente al tamaño del nodo o al número de réplicas. Primero decide qué tipo de cuello de botella tienes: estrangulamiento de CPU, presión de memoria, retraso en la programación, escalado lento, latencia de red, latencia de almacenamiento, o una aplicación que simplemente está haciendo más trabajo del esperado.

Fase 1: Identificar los Síntomas

Antes de sumergirte en componentes específicos, define claramente la degradación del rendimiento observada. Los síntomas comunes a menudo caen en una de estas categorías:

• Despliegues/Actualizaciones Lentas: La creación de pods toma un tiempo excesivo, o las actualizaciones continuas se estancan.
• Aplicaciones que No Responden: Los pods se están ejecutando pero no responden al tráfico a nivel de aplicación (por ejemplo, alta latencia, errores 5xx).
• Picos Altos de Recursos: Picos inexplicables de uso de CPU o memoria en nodos o despliegues específicos.
• Retrasos en la Programación: Los nuevos pods permanecen en estado Pending indefinidamente.

Fase 2: Diagnosticar Restricciones de Recursos (CPU y Memoria)

La mala gestión de recursos es la causa más frecuente de problemas de rendimiento en Kubernetes. Las solicitudes y límites mal configurados llevan a estrangulamiento o OOMKills.

1. Verificar la Utilización y los Límites de Recursos

Comienza inspeccionando las asignaciones de recursos para la aplicación afectada usando kubectl describe y kubectl top.

Verificación Accionable: Compara las requests y limits contra el uso real reportado por los servidores de métricas.

# Obtener el uso de recursos para todos los pods en un namespace
kubectl top pods -n <namespace>

# Examinar las solicitudes/límites de recursos para un pod específico
kubectl describe pod <pod-name> -n <namespace>

También inspecciona la carga de trabajo propietaria para entender si el problema afecta a un pod o a todo el Deployment:

kubectl get deploy <deployment-name> -n <namespace> -o yaml
kubectl get pods -n <namespace> -l app=<label> -o wide

Si solo un pod es lento y está en un nodo diferente de los demás, es más probable que sea presión a nivel de nodo. Si cada réplica es lenta, las configuraciones de recursos, las dependencias posteriores o el comportamiento de la aplicación merecen más atención.

2. Estrangulamiento de CPU

Si el uso de CPU de un contenedor alcanza repetidamente su límite definido, el kernel lo estrangulará, lo que lleva a picos severos de latencia incluso si el nodo en sí tiene capacidad disponible. Esto a menudo se confunde con falta general de CPU.

Consejo de Diagnóstico: Busca respuestas de alta latencia, incluso cuando kubectl top no muestra un 100% de uso de CPU en el nodo. El estrangulamiento ocurre por contenedor.

Para una confirmación más profunda, usa tu sistema de métricas si expone métricas de estrangulamiento de CPU del contenedor. En configuraciones basadas en Prometheus, los equipos a menudo observan métricas como períodos de CPU estrangulados junto con la latencia de solicitud. El uso bruto de CPU por sí solo puede ocultar el estrangulamiento porque un contenedor puede ser estrangulado antes de que parezca usar un núcleo completo del nodo.

Resolución:

• Aumenta el limit de CPU si la carga de trabajo legítimamente requiere más potencia de procesamiento.
• Si la aplicación está en espera activa, optimiza el código de la aplicación en lugar de simplemente aumentar los límites.
• Considera eliminar los límites de CPU para algunos servicios sensibles a la latencia mientras mantienes las solicitudes de CPU, si eso se ajusta a tu política de plataforma. Esto evita el estrangulamiento duro mientras aún proporciona información de ubicación útil al planificador.

3. Presión de Memoria y OOMKills

Si un contenedor excede su límite de memoria, Kubernetes inicia una eliminación por falta de memoria (OOM), reiniciando el contenedor repetidamente.

Diagnóstico: Verifica el estado del pod para reinicios frecuentes (revisa la columna RESTARTS en kubectl get pods) y examina los registros en busca de eventos OOMKilled.

# Verificar eventos recientes para OOMKills
kubectl get events --field-selector involvedObject.name=<pod-name> -n <namespace>

Resolución:

• Si los OOMKills son frecuentes, aumenta inmediatamente el limit de memoria.
• Para soluciones a largo plazo, perfila la aplicación para encontrar y corregir fugas de memoria o reducir el tamaño del heap.

La memoria se comporta de manera diferente a la CPU. La CPU puede ser estrangulada y el proceso sigue funcionando lentamente. Las violaciones del límite de memoria generalmente terminan con la eliminación del proceso. Esto hace que los problemas de memoria parezcan incidentes de confiabilidad: reinicios, conexiones caídas, cachés frías y solicitudes en vuelo fallidas.

Mejor Práctica: Establecer Solicitudes con Sabiduría. Asegúrate de que las requests de recursos estén configuradas razonablemente cerca del uso mínimo esperado. Si las requests son demasiado bajas, el planificador podría sobrecomprometer el nodo, lo que lleva a contención cuando todos los pods alcanzan sus demandas simultáneamente.

Fase 3: Investigar Cuellos de Botella de Programación

Cuando los pods permanecen en estado Pending, el problema radica en la incapacidad del planificador para encontrar un nodo adecuado.

1. Analizar Pods Pendientes

Usa kubectl describe pod en un pod pendiente para leer la sección Events. Esta sección generalmente contiene una explicación clara de la falla para programar.

Mensajes Comunes del Planificador:

• 0/3 nodes are available: 3 Insufficient cpu. (Problema de capacidad del nodo)
• 0/3 nodes are available: 3 node(s) had taint {dedicated: infra}, that the pod didn't tolerate. (Desajuste de Taints/Tolerations)
• 0/3 nodes are available: 1 node(s) had taint {NoSchedule: true}, that the pod didn't tolerate. (Presión del nodo o mantenimiento)

2. Saturación de Recursos del Clúster

Si la programación se retrasa debido a falta de CPU/Memoria, el clúster carece de capacidad agregada suficiente.

Resolución:

• Agrega más nodos al clúster.
• Verifica que la utilización del nodo no sea artificialmente alta debido a solicitudes de recursos mal configuradas (ver Fase 2).
• Usa Cluster Autoscaler (CA) si se ejecuta en proveedores de nube para agregar nodos dinámicamente cuando se acumulan pods pendientes.

Si Cluster Autoscaler está habilitado pero no se agregan nodos, lee sus registros antes de asumir que el proveedor de nube está roto. Autoscaler puede negarse a agregar nodos porque los grupos de nodos alcanzaron su tamaño máximo, el pod pendiente tiene restricciones que ningún grupo de nodos puede satisfacer, o las cuotas impiden nuevas instancias.

Fase 4: Problemas de Rendimiento en Mecanismos de Escalado

El escalado automatizado debería reaccionar rápidamente, pero las malas configuraciones en Horizontal Pod Autoscalers (HPA) o Vertical Pod Autoscalers (VPA) pueden causar problemas.

1. Retraso del Horizontal Pod Autoscaler (HPA)

HPA depende del Metrics Server para reportar la utilización precisa de CPU/Memoria o métricas personalizadas.

Pasos de Diagnóstico:

1. Verificar la Salud del Metrics Server: Asegúrate de que el Metrics Server esté funcionando y sea accesible.

   kubectl get --raw "/apis/metrics.k8s.io/v1beta1/nodes"
   

2. Verificar el Estado del HPA: Inspecciona la configuración del HPA y los eventos recientes.

   kubectl describe hpa <hpa-name> -n <namespace>
   

   Busca mensajes que indiquen si la fuente de métricas no está disponible o si el bucle de decisión de escalado está funcionando.

Cuellos de Botella: Si se usan métricas personalizadas, asegúrate de que el proveedor de métricas externo funcione correctamente y reporte datos con la frecuencia suficiente para que el HPA tome decisiones útiles.

HPA es reactivo. No sabe que se acerca un pico de tráfico a menos que tu métrica lo refleje. Para cargas de trabajo con ráfagas repentinas, es posible que necesites réplicas mínimas más altas, métricas personalizadas más rápidas, escalado basado en colas o pre-escalado antes de eventos conocidos.

2. Interacciones del Vertical Pod Autoscaler (VPA)

Si bien VPA ajusta automáticamente las solicitudes de recursos, puede causar inestabilidad en el rendimiento durante su fase de ajuste si reinicia o redimensiona pods con frecuencia, especialmente para aplicaciones con estado que no pueden tolerar reinicios.

Recomendación: Usa VPA en modo Recommender primero, o usa updateMode: "Off" para solo observar recomendaciones sin aplicación automática, mitigando interrupciones de redimensionamiento innecesarias.

Fase 5: Rendimiento de Red y Almacenamiento

Cuando los recursos de cómputo se ven bien, la red o el almacenamiento persistente podrían ser el punto de estrangulamiento.

1. Problemas de CNI (Interfaz de Red de Contenedores)

Si la comunicación entre pods (especialmente a través de nodos) es lenta o falla intermitentemente, el plugin CNI podría estar sobrecargado o mal configurado.

Solución de Problemas:

• Verifica los registros de los pods del daemonset CNI (por ejemplo, Calico, Flannel).
• Prueba la conectividad básica usando ping o curl entre pods en diferentes nodos.

2. Latencia de Volumen Persistente (PV)

Las aplicaciones que dependen en gran medida de E/S de disco (bases de datos, sistemas de registro) sufrirán si la latencia del Volumen Persistente subyacente es alta.

Verificación Accionable: Confirma el tipo de aprovisionador (por ejemplo, AWS EBS gp3 vs. io1) y verifica que el volumen cumpla con las especificaciones de IOPS/rendimiento requeridas.

Advertencia sobre Almacenamiento: Nunca ejecutes bases de datos de alto rendimiento directamente en volúmenes hostPath estándar sin entender las características de rendimiento del disco subyacente. Usa soluciones de almacenamiento en la nube gestionadas o aprovisionadores de almacenamiento local de alto rendimiento para cargas de trabajo exigentes.

Cuellos de Botella a Nivel de Nodo

A veces, todos los pods en un nodo se vuelven más lentos a la vez. Esa es tu señal para dejar de mirar un Deployment e inspeccionar el nodo.

kubectl describe node <node-name>
kubectl top node <node-name>
kubectl get pods --all-namespaces -o wide | grep <node-name>

Busca condiciones de MemoryPressure, DiskPressure y PIDPressure. La presión de disco es fácil de pasar por alto porque el síntoma de la aplicación puede ser un inicio lento, fallos en la extracción de imágenes o desalojos en lugar de un error de disco obvio.

En el propio nodo, si tienes acceso, verifica:

df -h
iostat -x 1
free -h
journalctl -u kubelet --since "30 minutes ago"

Los servicios de Kubernetes gestionados pueden limitar el acceso directo al nodo, pero la misma idea sigue siendo válida: usa métricas del proveedor, eventos de kubelet y condiciones del nodo para decidir si el nodo es el cuello de botella compartido.

Presión del Plano de Control y la API

La mayoría de la latencia de la aplicación no es causada por el servidor de la API de Kubernetes. Tu solicitud web generalmente no llama al servidor de la API en cada solicitud de usuario. Pero la presión del plano de control puede perjudicar el rendimiento operativo: despliegues lentos, programación retrasada, actualizaciones de endpoints lentas o controladores que se quedan atrás.

Los síntomas incluyen:

• Los comandos kubectl son lentos en todo el clúster.
• Los despliegues tardan más de lo habitual en crear pods.
• Los controladores se retrasan con respecto al estado deseado.
• Los eventos muestran timeouts repetidos de la API.

Verifica si el problema afecta al tráfico normal de la aplicación o a las operaciones del clúster. Si solo los despliegues y la programación son lentos, mira la salud del servidor de la API, el comportamiento del controller manager, los webhooks de admisión y la salud de etcd en clústeres donde gestionas el plano de control.

Los webhooks de admisión merecen atención especial. Un webhook lento o no disponible puede retrasar la creación de pods incluso cuando los nodos tienen mucha capacidad. Si un despliegue se cuelga en el momento de la creación y los eventos mencionan llamadas a webhooks, investiga el servicio del webhook antes de redimensionar los nodos.

Un Orden Práctico de Solución de Problemas

Comienza con el síntoma visible para el usuario:

• Solicitudes HTTP lentas: compara la latencia de la aplicación, el estrangulamiento de CPU, los reinicios de memoria, la latencia posterior y la ruta de red.
• Inicio lento de pods: verifica el tiempo de extracción de imágenes, los eventos de programación, el tiempo de montaje de volúmenes y los contenedores init.
• Pods pendientes: verifica solicitudes, capacidad del nodo, taints, afinidad, cuotas y límites del autoscaler.
• Picos periódicos de latencia: verifica el estrangulamiento de CPU, la recolección de basura, los vecinos ruidosos, la latencia de almacenamiento y el tiempo de escalado del HPA.
• Reinicios aleatorios: verifica OOMKilled, sondas de vida, presión del nodo y registros de la aplicación del contenedor anterior.

Luego prueba o elimina una capa a la vez. Por ejemplo, si los picos de latencia coinciden exactamente con el estrangulamiento de CPU, tienes una pista sólida. Si los picos de latencia ocurren mientras la CPU, la memoria, la red y el almacenamiento parecen tranquilos, el cuello de botella puede estar dentro de la aplicación o en un servicio posterior fuera de Kubernetes.

Ajuste de Solicitudes y Límites Sin Suposiciones

Las malas configuraciones de recursos crean muchos problemas de rendimiento:

• Solicitudes demasiado bajas: el planificador empaqueta demasiados pods ocupados en el mismo nodo.
• Solicitudes demasiado altas: los pods permanecen pendientes aunque el uso real sea modesto.
• Límites de CPU demasiado bajos: las aplicaciones sensibles a la latencia se estrangulan.
• Límites de memoria demasiado bajos: los contenedores se eliminan en lugar de ralentizarse.
• Sin solicitudes en absoluto: la programación se vuelve menos predecible y las cargas de trabajo críticas pueden competir mal con vecinos ruidosos.

Usa métricas de producción recientes como punto de partida, luego deja margen para picos normales. Para cargas de trabajo como Java, Node.js, Go, Python y bases de datos, el comportamiento de la memoria puede ser muy diferente, así que evita copiar límites de un servicio a otro solo porque el tamaño de la imagen del contenedor parece similar.

Próximos Pasos

Las mejores investigaciones de rendimiento de Kubernetes son aburridas en el buen sentido: define el síntoma, verifica el pod, verifica el nodo, verifica el escalado, luego verifica la red y el almacenamiento. kubectl describe y kubectl top son solo el comienzo, pero generalmente te dicen qué dirección vale la pena seguir.

1. Implementa Resource Quotas robustas para evitar que vecinos ruidosos priven de recursos a aplicaciones críticas.
2. Revisa regularmente los recuentos de reinicios de pods para detectar tempranamente OOM sutiles o comportamientos fallidos de la aplicación.
3. Utiliza paneles de Prometheus/Grafana que rastreen específicamente métricas de estrangulamiento de CPU, no solo el uso bruto.