Escalar Kubernetes: HPA, métricas y disponibilidad
Kubernetes puede aumentar o reducir réplicas manualmente o mediante un autoscaler. Para que eso ayude, la aplicación debe soportar varias instancias y el clúster debe tener capacidad. Más pods no resuelven automáticamente un cuello de botella en una base de datos.
Esta guía utiliza una aplicación de práctica y separa escalado de pods de crecimiento de nodos.
Prepara la aplicación
Define readiness y recursos adecuados. Para HPA por utilización de CPU, los requests correspondientes permiten calcular el porcentaje de uso. Los limits no son un requisito universal equivalente para todas las métricas.
Comprueba que sesiones, archivos y tareas compartidas no dependan de una única instancia. De lo contrario, escalar puede duplicar trabajo o producir resultados inconsistentes.
Verifica métricas
kubectl top nodes
kubectl -n practica top podsSi no hay métricas, revisa la API y el componente instalado para tu clúster. No desactives verificación TLS de metrics-server como arreglo genérico; identifica la causa de certificados o conectividad.
Escalado manual
kubectl -n practica scale deployment web-lab --replicas=3
kubectl -n practica rollout status deployment/web-lab
kubectl -n practica get pods -o wideEl deployment debe existir. Comprueba si las réplicas se distribuyen y están preparadas. Un pod Pending indica que la solicitud de escala no se pudo satisfacer completamente.
Un HPA basado en CPU
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: web-lab
namespace: practica
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: web-lab
minReplicas: 2
maxReplicas: 5
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 70El porcentaje y las réplicas son decisiones de laboratorio, no recomendaciones universales. El deployment necesita requests apropiados y la API de métricas debe funcionar.
Evita administrar a la vez la misma cantidad de réplicas con herramientas que se contradigan. Revisa cómo tu flujo declarativo y el HPA interactúan.
Prueba carga con límites
Genera carga controlada y observa métricas, decisión del HPA y tiempo que tarda la aplicación en estar preparada. Después retira la carga y observa la reducción.
No crees un generador infinito sin plan de parada ni lo ejecutes sobre un servicio ajeno. En nube, el escalado puede aumentar costos.
PDB no es una garantía de disponibilidad
Un PodDisruptionBudget limita ciertas interrupciones voluntarias cuando se utilizan mecanismos que lo respetan. No evita todos los fallos ni sustituye el diseño de actualizaciones del controlador.
La disponibilidad también depende de readiness, distribución entre nodos o zonas, capacidad y tolerancia de la aplicación. No la deduzcas de un único YAML.
Nodos y datos
Si no hay recursos para nuevos pods, necesitas revisar capacidad y, cuando corresponda, autoscaling de nodos. Ese mecanismo tiene configuración y límites propios.
Para servicios con estado, comprende requisitos de almacenamiento y replicación antes de aumentar réplicas.
Preguntas frecuentes
¿HPA crea máquinas nuevas?
No por sí solo. Ajusta réplicas del objetivo; ampliar nodos requiere otro mecanismo compatible.
¿Los limits son obligatorios para todo HPA?
No como regla general. Los requisitos dependen de las métricas; para utilización de recursos necesitas los requests pertinentes.
¿Un PDB evita cualquier caída durante cambios?
No. Controla un conjunto de interrupciones y no reemplaza arquitectura y pruebas de disponibilidad.
En pocas palabras
Escalar pods y ampliar nodos son operaciones diferentes. HPA necesita métricas y configuración apropiadas; disponibilidad también depende de aplicación, distribución y datos.
Conclusión
Prueba carga controlada y observa demanda, réplicas y capacidad disponible. Conserva límites de presupuesto y revisa qué ocurre cuando la aplicación reduce tamaño o pierde un nodo.
Para continuar, revisa Instalar Kubernetes en Ubuntu desde cero: guía completa y Docker: qué es y cómo usarlo para ejecutar contenedores.