Kubernetes Resource: Límites, Requests y HPA en Producción

Kubernetes Resource Management: Checklist Límites, Requests y HPA en Producción

La gestión eficiente de los recursos en Kubernetes es la piedra angular de cualquier infraestructura cloud-native estable y de alto rendimiento. Ignorar este aspecto puede transformar un entorno dinámico y resiliente en un campo minado de inestabilidad y tiempos de inactividad inesperados. Imaginen un escenario: un clúster Kubernetes bien dimensionado, con decenas de deployments que gestionan cargas de trabajo críticas. Todo parece funcionar correctamente, hasta que un solo pod, quizás debido a una fuga de memoria o un pico de tráfico inesperado, comienza a consumir recursos de forma desproporcionada. Sin los controles adecuados, este pod puede saturar completamente un nodo, provocando la expulsión forzada de todos los demás pods que residen en él. Esto no es un ejercicio teórico; he sido testigo personal de un clúster con 30 deployments que sufrió una interrupción de 20 minutos, precisamente por un pod con fuga de memoria que saturó la RAM del nodo. ¿La causa? La falta de apenas cinco líneas de configuración YAML relacionadas con los resource limits. Un error trivial que tuvo un impacto significativo en la disponibilidad del servicio. Este artículo pretende ser una guía práctica y una checklist operativa para configurar correctamente requests, limits, QoS classes y autoscaling, garantizando estabilidad y rendimiento a tu entorno Kubernetes en producción.

Tested on: Kubernetes 1.29 · kubectl 1.29 · 27 de julio de 2026

Requisitos Previos / Entorno de Prueba

Para seguir esta guía, necesitarás un clúster Kubernetes funcional y acceso con kubectl. No es necesario un entorno de producción; un clúster local como Minikube o Kind es suficiente para probar los conceptos. Asegúrate de tener kubectl configurado y autenticado en tu clúster.

1. Requests y Limits: Diferencia y Por Qué Ambos Son Obligatorios

La distinción entre requests y limits es fundamental para la estabilidad y eficiencia de tu clúster Kubernetes. Estos dos parámetros, definidos para CPU y memoria, guían al scheduler de Kubernetes en el posicionamiento de los pods en los nodos y al kubelet en la gestión de los recursos en el nodo.

• Requests: Indican la cantidad mínima de recursos (CPU y memoria) que un pod requiere para funcionar correctamente. El scheduler usa las requests para decidir en qué nodo colocar un pod, garantizando que el nodo tenga suficientes recursos disponibles para satisfacer esta solicitud mínima. Si un nodo no tiene los recursos solicitados, el pod no se programará en ese nodo. Lee también: Kubernetes Networking: DNS, Services, Ingress — Guía Práctica Sysadmin
• Limits: Representan la cantidad máxima de recursos (CPU y memoria) que un pod puede consumir. Si un pod intenta superar su limit de memoria, será terminado (OOMKilled – Out Of Memory Killed) por el kubelet. Si supera el limit de CPU, su ejecución será limitada (throttled), pero no será terminado. Los limits son cruciales para prevenir que un solo pod «mate de hambre» a los otros pods en el nodo, o incluso cause inestabilidad a todo el nodo, como en el ejemplo de la fuga de memoria que mencioné.

¿Por qué ambos son obligatorios? Sin requests, Kubernetes no puede garantizar una base mínima de recursos, lo que lleva a un sobreaprovisionamiento e inestabilidad. Sin limits, un pod que funciona mal puede comprometer todo el nodo. La combinación de ambos proporciona al scheduler y al kubelet la información necesaria para una gestión de recursos predecible y robusta.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp-container
        image: nginx:latest
        resources:
          requests:
            memory: "64Mi"
            cpu: "250m" # 0.25 CPU core
          limits:
            memory: "128Mi"
            cpu: "500m" # 0.5 CPU core

2. QoS Classes: Guaranteed, Burstable, BestEffort

Kubernetes asigna a cada pod una Quality of Service (QoS) Class en función de la configuración de sus requests y limits. Esta clase determina la prioridad de programación y, sobre todo, la gestión de la expulsión en situaciones de escasez de recursos en el nodo.

• Guaranteed: Un pod es Guaranteed si las requests de CPU y memoria son iguales a los limits para todos sus contenedores. Estos pods tienen la máxima prioridad y son los últimos en ser terminados en caso de recursos insuficientes en el nodo.
• Burstable: Un pod es Burstable si tiene al menos una request de CPU o memoria configurada, y las requests son inferiores a los limits (o los limits no están especificados). Estos pods tienen una prioridad intermedia y pueden ser terminados antes que los pods Guaranteed.
• BestEffort: Un pod es BestEffort si ninguno de sus contenedores especifica requests o limits para CPU o memoria. Estos pods tienen la prioridad más baja y son los primeros en ser terminados en caso de escasez de recursos.

Comprender las QoS Classes es crucial para la resiliencia. Asigna Guaranteed a las cargas de trabajo críticas, Burstable para la mayoría de las aplicaciones y BestEffort solo para servicios no esenciales o trabajos por lotes que pueden tolerar interrupciones.

3. LimitRange y ResourceQuota para Namespace

En entornos multi-tenant o con diferentes equipos que comparten un clúster, es esencial imponer políticas sobre el uso de los recursos a nivel de namespace. LimitRange y ResourceQuota son las herramientas para hacerlo.

• LimitRange: Define los default y los máximos requests y limits para los pods y los contenedores dentro de un namespace. Si un pod no especifica requests o limits, LimitRange puede inyectar los valores predeterminados. Esto evita que los desarrolladores olviden configurar los recursos.

apiVersion: v1
kind: LimitRange
metadata:
  name: cpu-mem-limit-range
spec:
  limits:
  - default:
      cpu: 500m
      memory: 256Mi
    defaultRequest:
      cpu: 200m
      memory: 128Mi
    type: Container

• ResourceQuota: Limita el consumo total de recursos para un namespace completo. Puedes limitar el número de pods, servicios, volúmenes persistentes y, sobre todo, el total de requests y limits para CPU y memoria. Esto evita que un solo namespace monopolice los recursos del clúster.

kubectl apply -f - <<EOF
apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-quota
spec:
  hard:
    requests.cpu: '4'
    requests.memory: 8Gi
    limits.cpu: '8'
    limits.memory: 16Gi
EOF

Estas herramientas, si están bien configuradas, te permiten dormir más tranquilo, sabiendo que los equipos no podrán involuntariamente (o intencionalmente) causar problemas a todo el clúster. Para una referencia completa, consulta la documentación oficial de Kubernetes sobre Resource Quotas.

4. HPA — Autoscaling Basado en CPU y Métricas Custom

El Horizontal Pod Autoscaler (HPA) es un controlador que escala automáticamente el número de réplicas de un Deployment, ReplicaSet o StatefulSet en función del uso observado de CPU, memoria u otras métricas custom. Esto te permite gestionar los picos de carga sin intervención manual.

El HPA monitorea las métricas a través de la API metrics.k8s.io (que requiere el metrics-server instalado) o API externas para métricas custom. Cuando el uso promedio de los recursos de un pod supera un umbral definido, el HPA aumenta el número de réplicas. Cuando desciende, las reduce.

Ejemplo de HPA basado en CPU:

kubectl autoscale deployment myapp --cpu-percent=70 --min=2 --max=10

Este comando crea un HPA que mantendrá el uso promedio de la CPU del deployment myapp al 70%, escalando entre un mínimo de 2 y un máximo de 10 pods. Puedes verificar el estado del HPA con:

kubectl get hpa

Para métricas custom, como el número de solicitudes HTTP por segundo o la longitud de una cola de mensajes, es necesario integrar un sistema de monitoreo como Prometheus y configurar una Custom Metrics API para exponer estas métricas al HPA.

5. VPA — Vertical Autoscaling para Optimizar las Solicitudes

Mientras el HPA escala horizontalmente (añadiendo o eliminando pods), el Vertical Pod Autoscaler (VPA) escala verticalmente, ajustando dinámicamente las requests y limits de CPU y memoria para los pods individuales. El VPA observa el uso histórico de los recursos de un pod y sugiere (o aplica directamente) configuraciones óptimas.

El VPA es particularmente útil para cargas de trabajo con patrones de uso de recursos variables que no se benefician de un escalado horizontal, o para optimizar los recursos y reducir el desperdicio. Puede operar en diferentes modos:

• Off: Solo sugiere los valores óptimos, no los aplica.
• Initial: Aplica las sugerencias solo al iniciar el pod.
• Recreate: Termina y recrea los pods para aplicar los nuevos valores.
• Auto: Ajusta dinámicamente los recursos sin recrear el pod (requiere funcionalidades beta de Kubernetes).

La implementación del VPA es más compleja que la del HPA y requiere una evaluación cuidadosa, especialmente para el modo Recreate que implica un tiempo de inactividad temporal para el pod.

6. kube-resource-report: Visión General del Clúster en un Comando

Para tener una visión general del uso de los recursos y la configuración en tu clúster, herramientas como kube-resource-report o incluso simples comandos kubectl son indispensables. Para un análisis rápido y sin complicaciones del uso actual de los recursos, puedes usar:

kubectl top pods --all-namespaces --sort-by=cpu

Este comando te dará una visión inmediata de los pods que están consumiendo más CPU, útil para identificar posibles problemas o pods mal configurados. Para un análisis más profundo y reportes agregados, herramientas externas como kube-resource-report o dashboards de monitoreo (ej. Grafana con Prometheus) son esenciales para un entorno de producción. Lee también: Prometheus Alerting: Telegram, Email, PagerDuty with AlertManager

Errores Comunes y Resolución de Problemas

• OOMKilled frecuentes: Indica que los limits de memoria son demasiado bajos o que hay una fuga de memoria en la aplicación. Aumentar el limit puede resolverlo temporalmente, pero es crucial investigar la causa del consumo excesivo.
• Pod Pending: A menudo significa que las requests de CPU o memoria son demasiado altas y no hay nodos con recursos suficientes para programar el pod. Revisa kubectl describe pod para los detalles.
• CPU Throttling: Si los limits de CPU son demasiado bajos, la aplicación podría experimentar ralentizaciones. Monitorea el uso de la CPU y aumenta los limits si es necesario, pero ten cuidado de no sobreaprovisionar.
• HPA no escala: Verifica que metrics-server esté instalado y funcionando (kubectl top pods debería funcionar). Revisa los eventos del HPA (kubectl describe hpa ) para entender por qué no está escalando.
• Olvidar los requests: Este es un error común que lleva a que los pods tengan QoS BestEffort, haciéndolos vulnerables a la expulsión en caso de escasez de recursos. Usa LimitRange para establecer valores predeterminados.

FAQ — Preguntas Frecuentes

¿Debo siempre establecer tanto requests como limits?

Sí, para la mayoría de las cargas de trabajo en producción es muy recomendable establecer tanto requests como limits. Las requests ayudan al scheduler a posicionar los pods correctamente, mientras que los limits evitan que un solo pod comprometa todo el nodo. Su combinación garantiza una QoS Guaranteed o Burstable, reduciendo el riesgo de expulsión.

¿Cuál es la diferencia práctica entre HPA y VPA?

El HPA (Horizontal Pod Autoscaler) aumenta o disminuye el número de pods (escalado horizontal) en función de la carga. El VPA (Vertical Pod Autoscaler) ajusta los recursos (CPU/memoria) de un solo pod (escalado vertical). El HPA es ideal para aplicaciones sin estado y escalables, mientras que el VPA es para optimizar el uso de los recursos de pods individuales o con estado.

¿Cómo puedo monitorear el uso de los recursos de mi clúster?

Para un monitoreo básico, kubectl top nodes y kubectl top pods son un buen comienzo. Para un monitoreo más avanzado y en producción, la integración con Prometheus y Grafana es el estándar de facto. Estas herramientas permiten visualizar el uso histórico, configurar alertas y analizar tendencias, esenciales para la planificación de la capacidad.

¿Es posible que un pod con Guaranteed QoS sea igualmente terminado?

Sí, incluso un pod Guaranteed puede ser terminado, pero es el último recurso. Esto puede ocurrir en situaciones extremas, como la falta de recursos críticos del sistema (ej. PIDs, espacio en disco) o si el nodo mismo falla (ej. crash de hardware, kernel panic). La clase Guaranteed ofrece la máxima protección, pero no la inmunidad absoluta en caso de fallos del nodo.

Conclusiones con Puntos Clave Operativos

La gestión de recursos en Kubernetes no es una opción, sino una práctica fundamental para la estabilidad y eficiencia de los entornos de producción. El incidente del tiempo de inactividad de 20 minutos por 5 líneas de YAML faltantes es una advertencia potente. Implementar correctamente requests y limits para cada pod, utilizar ResourceQuota y LimitRange para imponer políticas a nivel de namespace, y aprovechar el autoscaling con HPA y VPA, son pasos cruciales para construir una infraestructura Kubernetes robusta y resiliente. No dejes que un pod mal configurado arruine tu día. Invierte tiempo en la comprensión e implementación de estas mejores prácticas; se pagará en términos de uptime y tranquilidad.

Actualizado: julio de 2026