Aprende a Aplicar límites de CPU y memoria en Kubernetes para evitar vecinos ruidosos

Los pods sin límites pueden consumir recursos del nodo y degradar servicios críticos dentro de un clúster. En Kubernetes, definir correctamente requests y limits ayuda a reducir este riesgo y a evitar que una carga de trabajo afecte a otras aplicaciones que comparten la misma infraestructura.

Esta guía propone una implementación base con enfoque conservador: cambios verificables, comandos claros, advertencias antes de acciones sensibles y una validación final para detectar errores antes de mover tráfico o datos reales.

Qué vas a construir

Vas a preparar una configuración base de recursos para Kubernetes que podrás adaptar a un Cloud Server de DonWeb Cloud, a una instancia Linux propia o a un entorno de laboratorio.

El resultado esperado es una configuración documentada, con comandos de prueba y recomendaciones para pasar de laboratorio a producción.

Cuándo conviene usarlo

Este enfoque es útil cuando:

• Necesitas una solución operativa y repetible, no solo una explicación conceptual.
• El servicio va a vivir en un servidor cloud y requiere seguridad básica desde el primer despliegue.
• Necesitas dejar evidencia de configuración, pruebas y criterios de mantenimiento.
• Quieres reducir configuraciones manuales difíciles de auditar.
• Buscas limitar el impacto de pods que podrían consumir demasiada CPU o memoria.

Requisitos previos

Antes de comenzar, asegúrate de contar con:

• Un Cloud Server o servidor Ubuntu/Debian actualizado.
• Un usuario con permisos sudo o rol equivalente.
• Acceso SSH o consola segura.
• Backup previo si el servidor ya tiene datos o tráfico real.
• Dominio o subdominio si el artículo publica un servicio web.
• Credenciales con mínimo privilegio si se usan comandos AWS.
• Ventana de mantenimiento para cambios de red, firewall, runtime, base de datos o credenciales.

Flujo de trabajo recomendado

El flujo recomendado es:

1. Preparar el entorno.
2. Instalar o activar los componentes necesarios.
3. Configurar los recursos de CPU y memoria.
4. Probar el comportamiento.
5. Reforzar seguridad y dejar criterios de mantenimiento.

Evita cambiar varias capas a la vez. Si algo falla, una modificación incremental es más fácil de revisar y revertir.

Comandos principales

Durante el procedimiento vas a usar comandos como los siguientes:

kubectl top nodes

kubectl apply -f resources.yaml

kubectl describe pod api -n apps

kubectl get resourcequota -n apps

kubectl rollout restart deploy/api -n apps

Configuración base de recursos

El siguiente bloque muestra una configuración base para definir requests y limits de CPU y memoria:

resources:
  requests:
    cpu: 100m
    memory: 128Mi
  limits:
    cpu: 500m
    memory: 512Mi

En este ejemplo, el pod solicita una cantidad mínima de recursos para poder programarse en un nodo y, al mismo tiempo, queda limitado para no superar ciertos valores máximos de consumo.

Paso 1: Preparar el servidor o entorno

Antes de ejecutar cualquier comando, revisa que estés en el servidor correcto y que tengas una ventana de mantenimiento si el servicio ya recibe tráfico.

Para comenzar, consulta el estado de los nodos:

kubectl top nodes

Verifica la salida antes de continuar. Si el comando forma parte de un cambio que modifica red, credenciales, firewall, base de datos o runtime de contenedores, toma una copia de seguridad y conserva una ruta de rollback.

Paso 2: Aplicar la configuración de recursos

Una vez preparada la configuración, aplica el manifiesto correspondiente:

kubectl apply -f resources.yaml

Revisa la salida del comando y confirma que el recurso se haya aplicado correctamente. Si estás trabajando sobre un entorno con tráfico real, valida el impacto antes de continuar.

Paso 3: Configurar requests y limits

Dentro del manifiesto, define los recursos del contenedor con una estructura como esta:

resources:
  requests:
    cpu: 100m
    memory: 128Mi
  limits:
    cpu: 500m
    memory: 512Mi

Esta configuración permite declarar una base mínima de recursos y un máximo permitido para el contenedor. Antes de aplicarla en producción, ajusta los valores al comportamiento real de la aplicación.

Paso 4: Probar que la configuración funciona

Después de aplicar los manifiestos, revisa los recursos del namespace:

kubectl get resourcequota -n apps

También puedes inspeccionar el pod para confirmar su configuración:

kubectl describe pod api -n apps

Verifica la salida antes de continuar. Si detectas un comportamiento inesperado, revisa el manifiesto aplicado, el namespace y el contexto activo de Kubernetes.

Paso 5: Reiniciar el despliegue y dejar mantenimiento

Si necesitas que el despliegue tome la nueva configuración, puedes reiniciarlo:

kubectl rollout restart deploy/api -n apps

Antes de ejecutar este paso, confirma que estás trabajando en el namespace correcto y que el servicio puede tolerar el reinicio. Luego revisa el estado del despliegue y conserva evidencia de la configuración aplicada.

Problemas frecuentes

Permisos insuficientes

Revisa el usuario, el grupo, el rol IAM o el contexto de Kubernetes antes de repetir comandos con más privilegios.

Puerto ocupado o cerrado

Valida con ss -tulpn, reglas de firewall y security groups antes de asumir que la aplicación falló.

Variables de entorno ausentes

Confirma .env, secretos del orquestador y que no se impriman credenciales en logs.

El servicio inicia, pero no responde

Revisa healthchecks, logs, dependencia de base de datos y resolución DNS.

Rollback no definido

Conserva la versión anterior, snapshot, backup o manifiesto previo antes de aplicar cambios sensibles.

Buenas prácticas para producción

Para llevar esta configuración a un entorno productivo, considera estas prácticas:

• Usa mínimo privilegio para usuarios, roles, contenedores y reglas de red.
• Versiona configuraciones sin incluir secretos.
• Prueba restauraciones de backup, no solo la creación del archivo.
• Activa logs y alertas antes de necesitar diagnosticar un incidente.
• Documenta quién puede ejecutar cambios y qué evidencia debe quedar.
• Revisa periódicamente dependencias, imágenes y paquetes del sistema.

Advertencias de seguridad

No ejecutes estos pasos contra infraestructura de terceros ni contra producción sin autorización.

Los comandos y recomendaciones de seguridad están orientados a defensa, mitigación y auditoría autorizada. Si detectas credenciales expuestas, rota primero y luego investiga el alcance.

Estado técnico

• Probado en entorno aislado: no.
• Validado contra documentación oficial: sí.
• Pendiente de validación: ejecutar el procedimiento completo en un servidor de laboratorio antes de publicarlo como probado.

Cloud Serversby Donweb

Todo el poder de la nube a tus proyectos y aplicaciones.
Alojamiento ultra rápido, escalable y con alta disponibilidad.

• Performance que te sorprenderá
• Rápida escalabilidad y sin limitaciones
• Arquitectura de alta disponibilidad
• Soporte experto y ejecutivos de cuenta
• Pagos en tu moneda y facturación local

Descubre la mejor solución de Cloud Hosting