Mecanismos de ajuste de la carga de trabajo
CCE admite políticas de HPA y de CustomedHPA para escalar cargas de trabajo. En la siguiente tabla se describen las diferencias entre estos dos tipos de políticas.
|
Concepto |
Política de HPA |
Política de CustomedHPA |
|---|---|---|
|
Implementación |
Kubernetes Horizontal Pod Autoscaling |
Capacidades de ajuste automático mejoradas |
|
Reglas |
Escala las Deployments según metrics (el uso de la CPU y de la memoria). |
Escala las Deployments según metrics (el uso de la CPU y de la memoria) o en un intervalo de periodic (un punto de tiempo específico cada día, cada semana, cada mes o cada año). |
|
Mejoras |
Agrega la ventana de tiempo de enfriamiento a nivel de aplicación y las funciones de umbral de ajuste basadas en el HPA de Kubernetes. |
Metric-based:
Periodic: Puede seleccionar un punto de tiempo específico todos los días, cada semana, cada mes o cada año o un período como el tiempo de activación. |
Cómo funciona HPA
HPA es un controlador que controla el ajuste horizontal de pod. HPA comprueba periódicamente las métricas de pod, calcula el número de réplicas necesarias para cumplir con los valores de destino configurados para los recursos de HPA y, a continuación, ajusta el valor del campo replicas en el objeto de recurso de destino (como una Deployment).
Un requisito previo para el ajuste automático es que se puedan recopilar los datos de ejecución de contenedor, como el número de nodos/pods de clúster y el uso de CPU y de memoria de contenedores. Kubernetes no proporciona tales capacidades de supervisión en sí. Puede utilizar extensiones para monitorear y recopilar sus datos. CCE integra Prometheus y Metrics Server para realizar estas capacidades:
- Prometheus es un marco de monitoreo de código abierto y alarmante que puede recopilar múltiples tipos de métricas. Prometheus ha sido una solución de monitoreo estándar de Kubernetes.
- Metrics Server es un agregador de datos de uso de recursos para todo el clúster. Metrics Server recopila métricas de la API de resumen expuesta por kubelet. Estas métricas se establecen para los recursos principales de Kubernetes, como pods, nodos, contenedores y Services. Metrics Server proporciona un conjunto de API estándar para que los sistemas externos recopilen estas métricas.
HPA puede trabajar con Metrics Server para implementar el ajuste automático basado en el uso de CPU y memoria. También puede trabajar con Prometheus para implementar ajuste automático basado en métricas de monitoreo personalizadas.
Figura 1 muestra cómo funciona HPA.
Dos módulos principales de HPA:
- Supervisión del origen de datos
La comunidad solo proporcionaba HPA basado en CPU y en memoria en la etapa inicial. Con la población de Kubernetes y Prometheus, los desarrolladores necesitan más métricas personalizadas o información de monitorización en la capa de acceso para sus propias aplicaciones, por ejemplo, el QPS del balanceador de carga y el número de usuarios en línea del sitio web. En respuesta, la comunidad define un conjunto de API de métricas estándar para proporcionar servicios externamente con estas API agregadas.
- metrics.k8s.io proporciona métricas de monitorización relacionadas con la CPU y la memoria de pods y nodos.
- custom.metrics.k8s.io proporciona métricas de supervisión personalizadas relacionadas con los objetos de Kubernetes.
- external.metrics.k8s.io proporciona métricas que provienen de sistemas externos y son irrelevantes para cualquier métrica de recursos de Kubernetes.
- Algoritmos de toma de decisiones de ajuste
El controlador de HPA calcula la relación de ajuste en función de los valores métricos actuales y los valores métricos deseados utilizando la siguiente fórmula:
desiredReplicas = ceil[currentReplicas x (currentMetricValue/desiredMetricValue)]
Por ejemplo, si el valor métrico actual es 200m y el valor objetivo es 100m, el número deseado de pods se duplicará de acuerdo con la fórmula. En la práctica, los pods pueden agregarse o reducirse constantemente. Para garantizar la estabilidad, el controlador de HPA está optimizado desde los siguientes aspectos:
- Intervalo de enfriamiento: En la versión 1.11 y versiones anteriores, Kubernetes introdujo los parámetros de inicio horizontal-pod-autoscaler-downscale-stabilization-window y horizontal-pod-autoScaler-upscale-stabilization-window para indicar los intervalos de enfriamiento después de una reducción y una expansión respectivamente, en los que no se realizará ninguna operación de ajuste. En versiones posteriores a la v1.14, la cola de programación se introduce para almacenar todas las sugerencias de toma de decisiones detectadas dentro de un periodo de tiempo. A continuación, el sistema toma decisiones basadas en todas las sugerencias de toma de decisiones válidas para minimizar los cambios del número deseado de réplicas para garantizar la estabilidad.
- Tolerancia: Se puede considerar como una zona de búfer. Si se pueden tolerar cambios en el número de pods, el número de pods permanece sin cambios.
Utilice la fórmula: ratio = currentMetricValue/desiredMetricValue
Cuando |ratio – 1.0| ≤ tolerancia, no se realizará el ajuste.
Cuando |ratio – 1.0| > tolerancia, el valor deseado se calcula utilizando la fórmula mencionada anteriormente.
El valor predeterminado es 0.1 en la versión actual de la comunidad.
HPA realiza el ajuste basándose en los umbrales métricos. Las métricas comunes incluyen el uso de CPU y de memoria. También puede establecer métricas personalizadas, como el QPS y el número de conexiones, para activar el ajuste. Sin embargo, el ajuste basado en métricas trae la latencia de minutos generados durante las fases de recopilación, determinación y ajuste de datos. Tal latencia puede causar un alto uso de la CPU y una respuesta lenta. Para resolver este problema, CCE le permite configurar políticas programadas para escalar recursos regularmente para aplicaciones con los cambios periódicos.
