Introducción
El planificador necesita las solicitudes de recursos para ubicar los Pods, kubelet hace cumplir los límites y HorizontalPodAutoscaler necesita métricas junto con una referencia de utilización significativa. En conjunto, estos controles forman un flujo completo de gestión de capacidad.
Configurarás solicitudes y límites, inspeccionarás el uso en tiempo real, crearás un HPA, generarás carga y observarás los cambios en el número de réplicas.
Estas configuraciones forman una cadena de dependencias. La solicitud de CPU establece la referencia, metrics-server informa del uso reciente y HPA compara ambos valores para decidir si debe cambiar el número de réplicas. Si se omite la solicitud, el porcentaje de utilización de CPU carecería de sentido.
Establecer solicitudes y límites
En este paso, desplegarás el ejemplo de HPA de Kubernetes con recursos explícitos.
Una solicitud es la cantidad que se utiliza para la planificación y como denominador del escalado automático. Un límite es el máximo que se hace cumplir para el contenedor. La CPU se expresa en núcleos o milinúcleos (100m equivale a 0,1 núcleos); la memoria utiliza unidades de bytes como Mi.
cd /home/labex/project/resource-autoscaling
kubectl create namespace practice-capacity
kubectl create deployment cpu-demo -n practice-capacity --image=registry.k8s.io/hpa-example:latest --replicas=1
Añade el contrato de recursos al Deployment generado. kubectl set resources actualiza la plantilla de Pods y, por tanto, desencadena un nuevo despliegue:
kubectl set resources deployment/cpu-demo -n practice-capacity --requests=cpu=100m,memory=32Mi --limits=cpu=200m,memory=64Mi
kubectl expose deployment cpu-demo -n practice-capacity --port=80 --target-port=80
kubectl rollout status deployment/cpu-demo -n practice-capacity --timeout=60s
kubectl get deployment cpu-demo -n practice-capacity -o jsonpath='{.spec.template.spec.containers[0].resources}{"\n"}'
100m significa una décima parte de un núcleo de CPU. Las solicitudes influyen en la planificación y en los cálculos de utilización; los límites restringen el consumo del contenedor.
La salida de JSON debe contener tanto requests como limits. Declarar solo un límite no proporcionaría el denominador de utilización que necesita HPA.
deployment "cpu-demo" successfully rolled out
{"limits":{"cpu":"200m","memory":"64Mi"},"requests":{"cpu":"100m","memory":"32Mi"}}
Es posible que JSON muestre las claves en un orden diferente. Comprueba los cuatro valores, no su posición en la línea.
Inspeccionar las métricas de recursos
En este paso, verificarás la canalización de métricas preparada e inspeccionarás el uso.
kubectl top muestra una instantánea del uso reciente, parecida en concepto al comando top de los sistemas operativos. No muestra las solicitudes ni los límites configurados; estos siguen formando parte de la especificación de la carga de trabajo.
cd /home/labex/project/resource-autoscaling
kubectl get deployment metrics-server -n kube-system
for attempt in $(seq 1 18); do
if kubectl top nodes >/dev/null 2>&1 && kubectl top pods -n practice-capacity --containers >/dev/null 2>&1; then
break
fi
echo "Waiting for the first metrics sample (${attempt}/18)..."
sleep 5
done
kubectl top nodes
kubectl top pods -n practice-capacity --containers
kubectl top lee métricas recientes, no solicitudes de recursos. Las métricas pueden tardar un poco en aparecer; si un Pod nuevo todavía no tiene una muestra, vuelve a intentarlo después de varios segundos.
El bucle realiza ese reintento automáticamente. Comprueba silenciosamente el estado como máximo 18 veces, espera cinco segundos entre cada intento y, cuando hay una muestra disponible, ejecuta una vez los dos comandos top visibles. En las comprobaciones, >/dev/null descarta la salida normal y 2>&1 envía la salida de error al mismo destino; así se evita que los mensajes esperados de “las métricas aún no están listas” aparezcan en el terminal. Este retraso es normal en una canalización de uso reciente y no significa que el Pod haya fallado.
Los valores del nodo y del Pod variarán, así que céntrate en que aparezcan las columnas de CPU y memoria, no en los números exactos. --containers separa el uso cuando un Pod contiene más de un contenedor.
Por ejemplo, en el entorno de prueba se obtuvieron una tabla de nodos y otra tabla por contenedor similares a estas:
NAME CPU(cores) CPU(%) MEMORY(bytes) MEMORY(%)
labex-v135 182m 9% 1602Mi 44%
POD NAME CPU(cores) MEMORY(bytes)
cpu-demo-... hpa-example 1m 9Mi
Es normal que tus valores sean diferentes, ya que son mediciones y no valores de configuración.
Crear un HorizontalPodAutoscaler
En este paso, establecerás como objetivo una utilización media de CPU del 30 %, con entre una y cuatro réplicas.
Con una solicitud de 100m, un objetivo del 30 % corresponde aproximadamente a un uso medio de CPU de 30m por Pod. HPA ajusta el número deseado de réplicas del Deployment, pero nunca lo reduce por debajo de min=1 ni lo aumenta por encima de max=4.
cd /home/labex/project/resource-autoscaling
kubectl autoscale deployment cpu-demo -n practice-capacity --cpu=30% --min=1 --max=4
kubectl get hpa cpu-demo -n practice-capacity
kubectl describe hpa cpu-demo -n practice-capacity
La utilización se mide con respecto a la solicitud de CPU de 100m. Sin esa solicitud, un objetivo de CPU basado en porcentajes no tendría denominador.
La sintaxis actual de kubectl autoscale escribe explícitamente el porcentaje como --cpu=30%. Esto sustituye a la opción antigua --cpu-percent, que Kubernetes 1.35 marca como obsoleta.
Durante los primeros segundos, la columna TARGETS puede mostrar <unknown> mientras se recopila una nueva muestra de métricas. describe hpa muestra las condiciones y los eventos que indican si el controlador dispone de métricas utilizables.
Por tanto, la tabla inicial puede verse así sin que esto indique un error:
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS
cpu-demo Deployment/cpu-demo cpu: <unknown>/30% 1 4 0
Después de la siguiente sincronización del controlador, <unknown> se sustituye por un porcentaje medido y REPLICAS refleja el estado del Deployment.
Generar carga y observar el escalado
En este paso, ejecutarás un cliente temporal que realizará solicitudes repetidas al Service durante un máximo de 60 segundos.
El comando timeout de BusyBox ejecuta durante 60 segundos un bucle interno de solicitudes. El bucle while llama repetidamente al endpoint de demostración que consume CPU, y >/dev/null descarta los cuerpos de las respuestas para mantener legible el terminal. Al alcanzar el límite de tiempo, el comando normalmente devuelve un estado distinto de cero, por lo que || true trata esa detención planificada como una finalización normal.
cd /home/labex/project/resource-autoscaling
kubectl run load-generator -n practice-capacity --image=busybox:1.36 --image-pull-policy=IfNotPresent --restart=Never --rm -i -- sh -c 'timeout 60 sh -c "while true; do wget -qO- http://cpu-demo >/dev/null; done" || true'
kubectl get hpa cpu-demo -n practice-capacity
kubectl get deployment cpu-demo -n practice-capacity
HPA reacciona de forma asíncrona, por lo que los cambios en el número de réplicas pueden continuar después de que finalice el cliente. Inspecciona las condiciones y los eventos del HPA en lugar de asumir que el escalado será inmediato.
Si el escalado todavía no aparece en la primera tabla, ejecuta brevemente kubectl get hpa cpu-demo -n practice-capacity -w y pulsa Ctrl+C después de observar un cambio. -w supervisa las actualizaciones; no modifica el HPA. El momento exacto no forma parte de la verificación, ya que los bucles de control de métricas funcionan de manera asíncrona.
En la ejecución de prueba, HPA detectó un uso superior al objetivo y aumentó el Deployment a dos réplicas listas:
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS
cpu-demo Deployment/cpu-demo cpu: 55%/30% 1 4 2
NAME READY UP-TO-DATE AVAILABLE
cpu-demo 2/2 2 2
La utilización exacta y el número de réplicas pueden ser diferentes. La interpretación importante es la siguiente: el 55% actual superó el objetivo del 30%, por lo que la capacidad deseada aumentó sin salir de los límites de 1 a 4 réplicas.
Resumen
Has relacionado las solicitudes, los límites, las métricas en tiempo real, los objetivos de utilización y las decisiones de HPA. La gestión de capacidad funciona como un bucle de retroalimentación: declara una referencia, observa el uso, define límites e inspecciona las condiciones del controlador.
