Un Pod puede estar en estado Running y aun así tener problemas serios de rendimiento.

La aplicación puede responder lentamente, consumir memoria constantemente, reiniciarse con OOMKilled o experimentar CPU throttling incluso cuando el nodo parece tener recursos disponibles.

En este segundo artículo de nuestra serie de troubleshooting en Kubernetes vamos a investigar:

• alto consumo de CPU;

• alto consumo de memoria;

• OOMKilled;

• CPU throttling;

• Pod evictions;

• presión de recursos a nivel de nodo.

El objetivo no será simplemente encontrar "qué Pod consume más".

Queremos responder:

¿El problema está en la aplicación, en sus requests/limits, o en la capacidad del nodo?

Requests, limits y consumo real

Antes de investigar CPU o memoria necesitamos distinguir tres conceptos:

1                Resources
2                    |
3       +------------+------------+
4       |            |            |
5    Request        Limit       Usage
6       |            |            |
7       v            v            v
8 Scheduling     Enforcement    Actual

Requests

Los requests indican a Kubernetes la cantidad de recursos que un workload solicita.

Por ejemplo:

1resources:
2  requests:
3    cpu: "250m"
4    memory: "256Mi"

El scheduler utiliza estos valores para decidir en qué nodo puede ejecutar el Pod.

Un Pod puede utilizar más recursos que su request si existen recursos disponibles y los límites lo permiten.

Limits

Los limits establecen restricciones sobre el consumo.

1resources:
2  requests:
3    cpu: "250m"
4    memory: "256Mi"
5  limits:
6    cpu: "500m"
7    memory: "512Mi"

CPU y memoria no se comportan de la misma forma.

 1CPU limit
 2    |
 3    v
 4CPU throttling
 5
 6Memory limit
 7    |
 8    v
 9Memory pressure / allocation
10    |
11    v
12Possible OOM kill

Un contenedor no es eliminado simplemente por consumir demasiado CPU. El kernel restringe el tiempo de CPU disponible mediante los mecanismos de control del cgroup.

La memoria funciona diferente: cuando el límite de memoria es alcanzado y una nueva asignación no puede satisfacerse, el kernel puede terminar procesos utilizando el mecanismo OOM.

1. Alto consumo de CPU

Supongamos que recibimos una alerta indicando que la latencia aumentó y encontramos un Pod utilizando una cantidad elevada de CPU.

El primer paso puede ser:

1kubectl top pods -A

Para revisar los contenedores individualmente:

1kubectl top pod <pod> \
2  -n <namespace> \
3  --containers

Y para ordenar Pods por CPU:

1kubectl top pods \
2  -n <namespace> \
3  --sort-by=cpu

Esto nos da una vista reciente del consumo.

Sin embargo:

kubectl top no sustituye a un sistema de monitoring.

Sus métricas provienen normalmente de Metrics Server y están diseñadas principalmente para proporcionar señales eficientes a componentes como los autoscalers.

Para investigar cuándo comenzó un problema o cómo evolucionó durante horas o días necesitamos métricas históricas.

¿Qué debemos preguntar cuando aumenta el CPU?

No debemos asumir inmediatamente que la solución es agregar más CPU.

Primero:

 1High CPU
 2   |
 3   +--- ¿Aumentó el tráfico?
 4   |
 5   +--- ¿Cambió la aplicación?
 6   |
 7   +--- ¿Un endpoint específico está consumiendo CPU?
 8   |
 9   +--- ¿Una dependencia está respondiendo lentamente?
10   |
11   +--- ¿Existe un loop o proceso runaway?
12   |
13   +--- ¿Hay más trabajo en background?
14   |
15   +--- ¿El container está siendo throttled?

Revisa también los cambios recientes:

1kubectl rollout history \
2  deployment/<deployment> \
3  -n <namespace>

Y los recursos configurados:

1kubectl get deployment <deployment> \
2  -n <namespace> \
3  -o yaml

Busca:

1resources:
2  requests:
3    cpu:
4  limits:
5    cpu:

CPU usage vs CPU limit

Imaginemos:

1CPU request:  250m
2CPU limit:    500m
3CPU usage:    490m

Ese contenedor está trabajando muy cerca de su límite.

Pero ahora imaginemos que el nodo tiene:

1Node CPU usage: 35%

Puede parecer contradictorio.

No necesariamente lo es.

El contenedor tiene su propio límite de CPU.

 1Node
 216 CPUs available
 3      |
 4      |        Plenty of CPU available
 5      |
 6      +------------------------------+
 7                                     |
 8Container                            |
 9CPU limit = 500m                     |
10      |                              |
11      v                              |
12reaches limit                        |
13      |                              |
14      v                              |
15CPU throttling <---------------------+

Por lo tanto, un nodo puede tener capacidad libre y un contenedor seguir experimentando throttling debido a su propio límite.

2. CPU throttling

Este escenario merece investigarse por separado.

Un workload puede presentar:

1Pods: Running
2CPU node: Normal
3Memory: Normal
4Errors: Low
5
6Latency: HIGH

y aun así estar limitado por CPU.

Los CPU limits se aplican mediante mecanismos del kernel y cgroups. Cuando un contenedor agota el tiempo de CPU que puede utilizar según su cuota, debe esperar antes de continuar ejecutándose.

Eso puede aparecer como aumento de latencia.

Métricas de Prometheus

Dependiendo de cómo recolectemos las métricas del runtime/cAdvisor, podemos encontrar métricas como:

1container_cpu_usage_seconds_total
2
3container_cpu_cfs_throttled_periods_total
4
5container_cpu_cfs_periods_total
6
7container_cpu_cfs_throttled_seconds_total

Los nombres y labels disponibles pueden variar según el stack de observabilidad y runtime, por lo que siempre debemos verificar qué métricas realmente existen en nuestro entorno.

Una consulta útil, cuando estas métricas están disponibles, puede ser:

1rate(
2  container_cpu_usage_seconds_total{
3    namespace="production",
4    pod=~"api-.*",
5    container!="POD",
6    container!=""
7  }[5m]
8)

Para investigar la proporción de períodos throttled:

1sum by (namespace, pod, container) (
2  rate(container_cpu_cfs_throttled_periods_total[5m])
3)
4/
5sum by (namespace, pod, container) (
6  rate(container_cpu_cfs_periods_total[5m])
7)

No deberíamos interpretar una métrica de throttling de forma aislada.

Correlaciona:

 1CPU throttling
 2      +
 3CPU usage
 4      +
 5request rate
 6      +
 7latency
 8      +
 9application behavior
10      |
11      v
12Better diagnosis

¿Cómo resolver CPU throttling?

No existe una única respuesta.

Dependiendo de la causa podemos:

• corregir un workload CPU-intensive;

• optimizar código;

• incrementar CPU requests;

• modificar CPU limits;

• agregar réplicas;

• ajustar HPA;

• separar procesos background;

• investigar noisy neighbors;

• revisar capacidad del nodo.

Simplemente eliminar todos los límites tampoco debería ser una respuesta automática.

Los límites pueden ayudar a controlar workloads que de otro modo podrían monopolizar recursos compartidos.

La configuración correcta depende del comportamiento del workload y de los objetivos de performance y aislamiento.

3. Alto consumo de memoria

Comenzamos nuevamente con:

1kubectl top pods -A

Y:

1kubectl top pod <pod> \
2  -n <namespace> \
3  --containers

Pero una lectura puntual no nos dice si estamos frente a:

1Normal high usage
2
3Memory
4  ^
5  |        ____________
6  |       /
7  |______/
8                 time

o:

 1Possible leak
 2
 3Memory
 4  ^
 5  |                 /
 6  |              /
 7  |           /
 8  |        /
 9  |_____/
10                 time

Por eso para memoria necesitamos especialmente datos históricos.

Preguntas para investigar memoria

 1High Memory
 2    |
 3    +--- ¿El uso está creciendo continuamente?
 4    |
 5    +--- ¿Se estabiliza?
 6    |
 7    +--- ¿Coincide con aumento de tráfico?
 8    |
 9    +--- ¿Cambió recientemente la aplicación?
10    |
11    +--- ¿Existe caching?
12    |
13    +--- ¿Existe un memory leak?
14    |
15    +--- ¿Está creciendo una cola?
16    |
17    +--- ¿El runtime tiene heap configurado?
18    |
19    +--- ¿Estamos cerca del memory limit?

Revisa requests y limits:

1kubectl get pod <pod> \
2  -n <namespace> \
3  -o yaml

Por ejemplo:

1resources:
2  requests:
3    memory: "512Mi"
4  limits:
5    memory: "1Gi"

Después compara:

1Memory usage
2       vs
3Memory request
4       vs
5Memory limit

4. OOMKilled

Uno de los síntomas más claros que podemos encontrar es:

1Reason: OOMKilled

Primero:

1kubectl describe pod <pod> \
2  -n <namespace>

También podemos consultar el estado anterior:

1kubectl get pod <pod> \
2  -n <namespace> \
3  -o jsonpath='{.status.containerStatuses[*].lastState.terminated}'

Y los logs anteriores:

1kubectl logs <pod> \
2  -n <namespace> \
3  --previous

OOMKilled vs Exit Code 137

Es importante no confundirlos.

Podemos encontrar:

1Exit Code: 137

137 normalmente representa:

1128 + 9 = 137
2
3signal 9 = SIGKILL

Pero:

Exit Code 137 por sí solo no demuestra que Kubernetes haya matado el proceso por OOM.

Un proceso puede recibir SIGKILL por otras razones.

Por eso debemos revisar también:

1Reason: OOMKilled

junto con:

• container state;

• Events;

• métricas de memoria;

• logs;

• condiciones del nodo.

Container OOM vs Node memory pressure

Otra distinción importante:

 1          Memory problem
 2                |
 3        +-------+-------+
 4        |               |
 5        v               v
 6 Container OOM      Node Pressure
 7        |               |
 8 Memory limit       Node running
 9 / cgroup OOM       low on memory
10        |               |
11        v               v
12 OOMKilled          Possible eviction

No son el mismo problema.

Container OOM

Por ejemplo:

1limits:
2  memory: "512Mi"

La aplicación intenta utilizar más memoria de la que puede disponer dentro de ese cgroup y el kernel puede matar un proceso.

Node pressure

También podemos tener múltiples workloads consumiendo recursos hasta que el nodo empieza a quedarse sin memoria.

Revisa:

1kubectl describe node <node>

Busca:

1Conditions:
2  MemoryPressure:

Y:

1kubectl top node <node>

¿Cómo resolver OOMKilled?

Aumentar el memory limit puede ser correcto.

Pero primero debemos responder:

¿Por qué la aplicación necesita más memoria?

Podemos tener:

 1OOMKilled
 2   |
 3   +--- Memory leak
 4   |
 5   +--- Limit demasiado bajo
 6   |
 7   +--- Tráfico mayor al esperado
 8   |
 9   +--- Cache sin límite
10   |
11   +--- Heap mal configurado
12   |
13   +--- Query o procesamiento demasiado grande
14   |
15   +--- Worker concurrency demasiado alta
16   |
17   +--- memory-backed volume
18

Una solución correcta podría ser cambiar:

1resources:
2  requests:
3    memory: "512Mi"
4  limits:
5    memory: "1Gi"

a:

1resources:
2  requests:
3    memory: "1Gi"
4  limits:
5    memory: "2Gi"

pero únicamente si los datos muestran que ese consumo es legítimo.

Si el proceso tiene un memory leak, simplemente aumentar el límite probablemente solo retrasará el siguiente OOM.

5. Pod Evictions

Ahora encontramos un Pod con:

1STATUS: Evicted

Empieza con:

1kubectl describe pod <pod> \
2  -n <namespace>

Y revisa el nodo:

1kubectl describe node <node>

Kubernetes puede realizar node-pressure eviction cuando un nodo alcanza determinados niveles de presión de recursos.

El kubelet monitoriza señales relacionadas con recursos como:

1Memory
2Disk
3Filesystem inodes

y puede terminar Pods para recuperar recursos y evitar que el nodo quede completamente degradado.

Node conditions

Un buen punto de partida es:

1kubectl get nodes

seguido de:

1kubectl describe node <node>

Busca:

1MemoryPressure
2DiskPressure
3PIDPressure

Y revisa consumo:

1kubectl top node <node>

Para memoria y CPU de todos los Pods del nodo:

1kubectl get pods -A \
2  --field-selector spec.nodeName=<node> \
3  -o wide

Luego podemos revisar individualmente los workloads relevantes.

Eviction no es OOMKilled

Es fácil confundir ambos síntomas.

 1OOMKilled
 2   |
 3Process/container killed
 4because of an OOM condition
 5
 6             !=
 7
 8Evicted
 9   |
10kubelet removes a Pod
11to reclaim constrained
12node resources

La investigación es diferente.

Con un OOMKilled normalmente empezamos investigando el contenedor y su memoria.

Con Evicted debemos prestar especial atención al nodo y sus recursos.

6. QoS Classes

Kubernetes asigna una Quality of Service class a los Pods dependiendo de cómo estén definidos CPU y memoria.

Podemos verla con:

1kubectl get pod <pod> \
2  -n <namespace> \
3  -o jsonpath='{.status.qosClass}'

Las clases son:

1Guaranteed
2Burstable
3BestEffort

Guaranteed

En la configuración tradicional a nivel de contenedor, un Pod puede ser Guaranteed cuando todos sus contenedores tienen requests y limits para CPU y memoria, y request y limit son iguales para cada recurso.

Ejemplo:

1resources:
2  requests:
3    cpu: "500m"
4    memory: "512Mi"
5  limits:
6    cpu: "500m"
7    memory: "512Mi"

Burstable

Un Pod que tiene algún request o limit de CPU/memoria, pero no cumple las condiciones de Guaranteed, normalmente pertenece a Burstable.

BestEffort

Un Pod sin requests ni limits de CPU/memoria queda normalmente como:

1BestEffort

Ejemplo:

1resources: {}

QoS y eviction

Cuando existe node pressure, la clase QoS es relevante, pero no es el único factor.

Kubernetes también considera factores como el consumo del workload respecto a sus requests y la prioridad del Pod al seleccionar candidatos para eviction.

Por eso no deberíamos resumir el comportamiento como:

1BestEffort -> Burstable -> Guaranteed

y asumir que ese orden explica cualquier eviction.

QoS forma parte de una decisión más amplia.

7. Requests mal dimensionados

Existe otro problema frecuente.

Supongamos que tenemos:

1resources:
2  requests:
3    cpu: "50m"
4    memory: "64Mi"
5  limits:
6    cpu: "2"
7    memory: "2Gi"

pero normalmente el workload consume:

1CPU:     800m
2Memory:  900Mi

El Pod podría funcionar.

Pero los requests le están diciendo al scheduler que el workload necesita mucho menos de lo que realmente suele consumir.

En muchos Pods esto puede contribuir a:

1Node appears to have capacity
2        |
3Scheduler places more Pods
4        |
5Actual usage grows
6        |
7Node becomes saturated
8        |
9Resource pressure

Por eso requests no deberían escogerse únicamente para lograr que los Pods puedan ser scheduled.

Deberían reflejar de manera razonable el comportamiento real del workload.

8. ¿Qué pasa si los requests son demasiado altos?

El problema inverso también existe.

1requests:
2  cpu: "4"
3  memory: "8Gi"

para un workload que normalmente utiliza:

1CPU:     200m
2Memory:  300Mi

puede desperdiciar capacidad de scheduling.

Aunque:

1kubectl top nodes

muestre poca utilización, el scheduler puede no aceptar más Pods porque utiliza los recursos solicitados para determinar placement.

Para revisar allocation:

1kubectl describe node <node>

Busca:

1Allocated resources:

Esto permite comparar:

1Actual utilization
2        vs
3Requested resources

9. Métricas útiles con Prometheus

kubectl top es excelente para obtener una vista rápida.

Para un incidente real necesitamos normalmente observar el comportamiento en el tiempo.

Algunas métricas frecuentemente disponibles mediante kubelet/cAdvisor incluyen:

1container_cpu_usage_seconds_total
2
3container_memory_working_set_bytes
4
5container_cpu_cfs_throttled_periods_total
6
7container_cpu_cfs_periods_total
8
9container_cpu_cfs_throttled_seconds_total

Y mediante kube-state-metrics podemos obtener información declarativa de Kubernetes, como requests y limits.

La disponibilidad exacta y los labels dependen de nuestro stack de monitoring.

CPU usage

Ejemplo:

1sum by (namespace, pod) (
2  rate(
3    container_cpu_usage_seconds_total{
4      container!="",
5      container!="POD"
6    }[5m]
7  )
8)

Memory working set

1sum by (namespace, pod) (
2  container_memory_working_set_bytes{
3    container!="",
4    container!="POD"
5  }
6)

Para entender un incidente no queremos únicamente:

1current value

Queremos ver:

130 minutes before
2       |
3incident begins
4       |
5resource growth
6       |
7failure
8       |
9recovery

10. Correlacionar recursos con la aplicación

Supongamos:

114:00 CPU normal
214:05 Deployment
314:10 CPU increases
414:12 Latency increases
514:15 CPU throttling increases
614:20 5xx increases

Ahora tenemos una historia mucho más útil que:

"CPU is high."

Podemos correlacionar:

 1Deployment
 2    |
 3    v
 4CPU growth
 5    |
 6    v
 7Throttling
 8    |
 9    v
10Latency
11    |
12    v
13Errors

El siguiente paso podría ser revisar logs o traces para determinar qué parte del nuevo código está utilizando más CPU.

11. Revisar desde el nodo

Cuando sospechamos que el problema afecta al nodo completo:

1kubectl describe node <node>

y:

1kubectl top node <node>

son buenos puntos de partida.

Si necesitamos investigar más profundamente y tenemos permisos:

1kubectl debug node/<node> \
2  -it \
3  --image=ubuntu

Dentro del entorno de debugging podemos inspeccionar el host según los permisos y configuración disponibles.

Por ejemplo:

1free -h

1df -h

1df -i

Y para problemas del kubelet, en entornos donde tengamos acceso administrativo al host:

1journalctl -u kubelet

Flujo de troubleshooting

Podemos resumir nuestra investigación así:

 1               Performance issue
 2                       |
 3                       v
 4                Define impact
 5                       |
 6                       v
 7              kubectl top / metrics
 8                       |
 9             +---------+---------+
10             |                   |
11             v                   v
12            CPU                Memory
13             |                   |
14      +------+------+      +-----+------+
15      |             |      |            |
16 High usage    Throttling  Growth     OOMKilled
17      |             |      |            |
18      +------+------+      +-----+------+
19             |                   |
20             v                   v
21        Requests/limits      Requests/limits
22             |                   |
23             +---------+---------+
24                       |
25                       v
26                  Check node
27                       |
28          +------------+-------------+
29          |            |             |
30      CPU pressure MemoryPressure DiskPressure
31          |            |             |
32          +------------+-------------+
33                       |
34                       v
35              Correlate application
36                       |
37                       v
38             Logs / Metrics / Traces
39                       |
40                       v
41                   Root cause

Command reference

 1# Current usage
 2kubectl top pods -A
 3kubectl top nodes
 4
 5# Container-level usage
 6kubectl top pod <pod> \
 7  -n <namespace> \
 8  --containers
 9
10# Sort by usage
11kubectl top pods \
12  -n <namespace> \
13  --sort-by=cpu
14
15kubectl top pods \
16  -n <namespace> \
17  --sort-by=memory
18
19# Pod state
20kubectl describe pod <pod> \
21  -n <namespace>
22
23# Previous container state
24kubectl get pod <pod> \
25  -n <namespace> \
26  -o jsonpath='{.status.containerStatuses[*].lastState.terminated}'
27
28# Previous logs
29kubectl logs <pod> \
30  -n <namespace> \
31  --previous
32
33# Resource configuration
34kubectl get deployment <deployment> \
35  -n <namespace> \
36  -o yaml
37
38# Node investigation
39kubectl describe node <node>
40kubectl top node <node>
41
42# Pods on a node
43kubectl get pods -A \
44  --field-selector spec.nodeName=<node> \
45  -o wide
46
47# QoS
48kubectl get pod <pod> \
49  -n <namespace> \
50  -o jsonpath='{.status.qosClass}'
51
52# Node debugging
53kubectl debug node/<node> \
54  -it \
55  --image=ubuntu

Qué no hacer

Durante un incidente evita respuestas automáticas como:

1OOMKilled
2    -> increase memory
3
4High CPU
5    -> increase CPU
6
7Evicted
8    -> add another node

Esas acciones podrían mitigar temporalmente el problema, pero no necesariamente resolver su causa.

En su lugar:

 1Symptom
 2   |
 3   v
 4Measure
 5   |
 6   v
 7Correlate
 8   |
 9   v
10Find constraint
11   |
12   v
13Understand workload
14   |
15   v
16Change
17   |
18   v
19Validate

Después de realizar un cambio, vuelve a revisar:

• CPU;

• memory;

• throttling;

• restart count;

• latency;

• errors;

• node pressure;

• application behavior.

Conclusión

Los problemas de recursos en Kubernetes ocurren en diferentes niveles.

1Application
2     |
3Container
4     |
5Pod
6     |
7Node
8     |
9Cluster

Un Pod OOMKilled no significa automáticamente que el nodo se quedó sin memoria.

CPU alto no significa automáticamente que necesitamos más CPUs.

Y un Pod evicted no es lo mismo que un proceso eliminado por el OOM killer.

Para solucionar estos incidentes debemos conectar:

 1Requests + Limits
 2       +
 3Actual Usage
 4       +
 5Container State
 6       +
 7Node Conditions
 8       +
 9Historical Metrics
10       +
11Application behavior
12       |
13       v
14    Root Cause

En el siguiente artículo de esta serie vamos a investigar networking en Kubernetes:

• Services;

• EndpointSlices;

• DNS;

• Ingress y Gateway API;

• NetworkPolicy;

• CNI;

• conectividad entre Pods;

• conectividad hacia servicios externos.

Seguiremos la conexión paquete por paquete para encontrar exactamente dónde se rompe la comunicación.