Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Al ejecutar aplicaciones en Azure Kubernetes Service (AKS), puede escalar pods, recursos de pod, nodos o cargas de trabajo controladas por eventos para que coincidan con los cambios en la demanda. AKS admite el escalado manual, el escalado automático horizontal de pods (HPA), el escalador automático vertical de pods (VPA), el escalador automático de clústeres, el escalado automático controlado por eventos de Kubernetes (KEDA), el aprovisionamiento automático de nodos y el escalado de ráfagas con Azure Container Instances (ACI).
Elección del método de escalado adecuado
| Método de escalado | Más adecuado para | Métrica clave | Guide |
|---|---|---|---|
| Escalador automático horizontal de pods (HPA) | Cargas de trabajo sin estado o particionables con demanda variable | Uso de CPU, RPS, profundidad de cola | ¿Cuándo debo usar el escalado automático horizontal de pods (HPA) en Kubernetes? |
| Escalador automático de pods verticales (VPA) | Cargas de trabajo no paralelizables; ajuste del tamaño de las solicitudes de recursos de los pods | Uso de recursos de CPU/memoria | Uso del escalador automático vertical de pods en AKS |
| Escalador automático de clústeres | Capacidad a nivel de nodo cuando los pods permanecen en estado Pendiente | Pods pendientes | Uso del escalador automático de clústeres en AKS |
| Aprovisionamiento automático de nodos (NAP) | Cargas de trabajo pendientes que necesitan capacidad de máquina virtual de tamaño correcto | Requisitos de recursos del pod pendientes | Introducción al aprovisionamiento automático de nodos |
| KEDA | Cargas de trabajo controladas por eventos; se requiere el escalado a cero | Longitud de la cola, trabajo acumulado de eventos | Introducción al complemento KEDA |
| Escalado de ráfagas de ACI | Cargas de trabajo de Linux con demanda de ráfaga que cumplen las limitaciones del nodo virtual | Pico de demanda | Creación de nodos virtuales con Azure Container Instances |
Cuándo usar cada método de escalado
- Use HPA cuando la carga de trabajo pueda ejecutar varias réplicas idénticas y la demanda fluctúa en función de la CPU, la memoria o la tasa de solicitudes.
- Use VPA cuando la carga de trabajo no se pueda escalar horizontalmente (no paralelizable) o tenga que ajustar el tamaño de las solicitudes de recursos para una mejor programación.
- Use Cluster Autoscaler cuando tenga grupos de nodos predefinidos y necesite añadir o quitar nodos en función de la demanda de pods pendientes.
- Use NAP cuando desee la selección automática de SKU de máquina virtual y el aprovisionamiento de nodos sin configurar manualmente grupos de nodos.
- Utilice KEDA cuando el escalado deba responder a eventos externos (colas, flujos, mensajes) o si necesita capacidad de escalado a cero.
- Use el escalado de ráfagas de ACI cuando necesite una rápida expansión de la capacidad para cargas de trabajo de Linux sin esperar al aprovisionamiento de máquinas virtuales (normalmente de 2 a 5 minutos).
Recomendación rápida
Para la mayoría de las cargas de trabajo de producción, comience con AKS Automatic, que preconfigura NAP, VPA y KEDA. En AKS Standard, habilita y configura estas funcionalidades de forma explícita.
Escalado manual de pods o nodos
Puede escalar manualmente réplicas y nodos de pod para probar cómo responde la aplicación a los cambios en los recursos disponibles o para mantener una cantidad fija de capacidad. Para escalar manualmente, defina el número de nodos o réplica necesarios. Después, Kubernetes crea o elimina pods, mientras que AKS agrega o elimina nodos del grupo de nodos correspondiente.
Cuando se reduce el número de nodos, AKS llama a la API pertinente de Azure Compute para el tipo de computación del clúster. En el caso de los clústeres basados en Virtual Machine Scale Sets, la API de Virtual Machine Scale Sets determina qué nodos se van a quitar. Para obtener más información, consulte las preguntas más frecuentes sobre Virtual Machine Scale Sets.
Para empezar, consulte:
Escalador horizontal automático de pods
Utiliza HPA cuando tu carga de trabajo pueda ejecutarse en varias réplicas idénticas y la demanda fluctúe. Puede escalar en función de la CPU o la memoria, de las métricas de la aplicación (solicitudes por segundo, latencia) o de métricas externas de cola y de acumulación de trabajo. Cuando las réplicas pueden superar la capacidad de nodo existente, use la funcionalidad NAP preconfigurada en AKS Automatic o configure Cluster Autoscaler o NAP en AKS Standard.
No use HPA y VPA en las mismas métricas de CPU o memoria. Para usar ambos escaladores automáticos, use VPA en modo de recomendación o configure HPA para usar métricas personalizadas distintas.
Más información: ¿Cuándo debo usar el escalado automático horizontal de pods (HPA) en Kubernetes?
Consulte también: Uso del escalador automático vertical de pods en AKS para ajustar el tamaño de las solicitudes de CPU y memoria de los pods.
Escalador automático de pod vertical
Vertical Pod Autoscaler analiza el uso de cpu y memoria del pod y recomienda o aplica las solicitudes de recursos adecuadas. Use VPA para ajustar el tamaño de las cargas de trabajo que no se pueden escalar de forma eficaz mediante la adición de réplicas o para mejorar la programación y el uso de recursos.
Según su modo de actualización, VPA puede aplicar recomendaciones cuando se crean pods, o bien expulsar y volver a crear pods con solicitudes de recursos actualizadas. Revise los requisitos de disponibilidad de la carga de trabajo antes de permitir que el VPA aplique automáticamente los cambios.
Para empezar, consulte Uso del escalador automático vertical de pods en AKS.
Escalador automático de clústeres
El escalador automático del clúster ajusta el número de nodos de un grupo de nodos en función de los requisitos de programación de los pods. Agrega nodos cuando los pods no se pueden programar debido a una capacidad insuficiente de los nodos y elimina los nodos infrautilizados cuando sus cargas de trabajo se pueden ejecutar en otro lugar.
El escalador automático de clústeres se usa normalmente con HPA. HPA ajusta el número de réplicas de pods en función de la demanda de la carga de trabajo, mientras que el escalador automático del clúster ajusta la capacidad de los nodos para dar cabida a esos pods.
Para empezar, consulte Uso del escalador automático de clústeres en AKS.
Eventos de escalado horizontal
Si un grupo de nodos no tiene suficientes recursos de computación para un pod, el pod permanece en estado Pending. Cuando el escalador automático de clúster detecta pods que no se pueden programar debido a restricciones de recursos del grupo de nodos, aumenta el número de nodos en dicho grupo. Kubernetes programa los pods pendientes una vez que los nuevos nodos se aprovisionan y están listos.
El aprovisionamiento de nodos basados en máquinas virtuales puede tardar varios minutos. En el caso de las cargas de trabajo con una demanda repentina de ráfaga, considere la posibilidad de usar nodos virtuales y Azure Container Instances.
Eventos de reducción de escala
El escalador automático de clúster supervisa los nodos en busca de infrautilización y determina si sus pods se pueden ejecutar en otros nodos. Cuando ya no se requiere un nodo, Kubernetes vuelve a programar sus pods y AKS quita el nodo del grupo de nodos.
Las operaciones de reducción horizontal pueden interrumpir las cargas de trabajo a medida que los pods se mueven entre los nodos. Ejecute varias réplicas de pods y configure los controles de disponibilidad adecuados para minimizar las interrupciones.
Escalado automático controlado por eventos de Kubernetes
El escalado automático controlado por eventos (KEDA) de Kubernetes es un componente de código abierto que escala las cargas de trabajo basadas en eventos. KEDA amplía Kubernetes con recursos personalizados, incluidos ScaledObject, que describen cómo una carga de trabajo debe responder a un origen o métrica de eventos.
KEDA es útil para cargas de trabajo que procesan colas, flujos, mensajes u otras acumulaciones de eventos. Puede escalar las cargas de trabajo admitidas a cero cuando no hay eventos disponibles y aumentar las réplicas a medida que crece el trabajo pendiente.
No combine una KEDA ScaledObject con un HPA independiente para la misma carga de trabajo. KEDA crea y utiliza un HPA internamente, por lo que los mecanismos de escalado automático entrarían en conflicto entre sí.
Para empezar, consulte la introducción al complemento KEDA.
Aprovisionamiento automático de nodos
El aprovisionamiento automático de nodos (NAP) usa el proyecto Karpenter de código abierto para aprovisionar y administrar nodos según los requisitos de pod pendientes. NAP selecciona una SKU de máquina virtual adecuada y una cantidad de nodos para satisfacer la demanda de cargas de trabajo en tiempo real.
NAP comienza con un conjunto permitido de SKU de máquina virtual y selecciona capacidad para cargas de trabajo pendientes. Puede definir límites de recursos y preferencias de programación para controlar cómo aprovisiona nodos y distribuye cargas de trabajo.
Escalado y medidas de seguridad del plano de control
AKS escala automáticamente los componentes del plano de control en función del tamaño del clúster y el uso de recursos del servidor de API. Esta guía se aplica a AKS Automatic y AKS Standard. Use el nivel de precios Estándar o Premium para cargas de trabajo de producción o de gran escala.
Kubernetes tiene un sobre de escala multidimensional en el que cada tipo de recurso coloca diferentes demandas en el plano de control. Por ejemplo, los secretos suelen ser observados por varios controladores y pods que hacen una llamada inicial LIST, lo que genera más carga en el plano de control que otros recursos que se observan con menos frecuencia. El escalado en gran medida en una dimensión puede reducir la capacidad en otros. Por ejemplo, la ejecución de cientos de miles de pods puede reducir a la tasa de mutación de pods que admite el plano de control. Para obtener recomendaciones, consulte los procedimientos recomendados del cliente de Kubernetes para clústeres de AKS a gran escala.
Para comprobar si el plano de control se ha escalado verticalmente, inspeccione configMap large-cluster-control-plane-scaling-status :
kubectl describe configmap large-cluster-control-plane-scaling-status -n kube-system
La presencia de este ConfigMap confirma que AKS amplía el plano de control.
Medidas de seguridad del plano de control
Si el escalado automático del servidor de API no lo estabiliza bajo una carga alta, AKS puede implementar una protección de servidor de API administrada. Esta salvaguarda de último recurso limita las solicitudes de clientes que no son del sistema para evitar que el plano de control deje de responder. Las llamadas al servidor de API críticas para el sistema desde componentes como kubelet continúan funcionando.
Para determinar si se ha aplicado la protección del servidor API gestionado, compruebe si están presentes aks-managed-apiserver-guard, FlowSchema y PriorityLevelConfiguration:
kubectl get flowschemas
kubectl get prioritylevelconfigurations
La protección está activa cuando aks-managed-apiserver-guard aparece en ambas salidas de comando.
Si estos recursos están presentes, consulte la guía de solución de problemas del servidor de API y etcd para obtener instrucciones de mitigación.
Ráfaga en Azure Container Instances (ACI)
Puede integrar AKS con Azure Container Instances para controlar los aumentos rápidos de la demanda. El escalado automático de pods puede crear más réplicas de las que el grupo de nodos existente puede admitir, mientras que el aprovisionamiento de nodos adicionales basados en máquinas virtuales puede tardar varios minutos. ACI proporciona capacidad de proceso sin necesidad de nodos de máquina virtual adicionales.
Los nodos virtuales (nodos virtuales de Kubernetes respaldados por ACI) admiten pods y nodos Linux y requieren un clúster de AKS que use redes de Azure CNI. No admiten algunos escenarios comunes, como intervalos IP autorizados del servidor de API, volúmenes persistentes y notificaciones de volumen persistentes, IPv6 e identidades administradas asociadas a nodos virtuales. Revise las limitaciones del nodo virtual antes de usar el escalado de ráfagas de ACI.
El componente de nodos virtuales de AKS se basa en Virtual Kubelet y presenta ACI como un nodo de Kubernetes virtual. Kubernetes puede programar la ejecución de pods compatibles a través del nodo virtual para que se ejecuten como instancias de contenedor de ACI en lugar de hacerlo directamente en nodos de máquina virtual de AKS.
Los nodos virtuales usan otra subred en la misma red virtual que el clúster de AKS. Esta configuración proporciona conectividad de red privada entre AKS y ACI, al tiempo que permite que ACI actúe como una extensión lógica del clúster.
Contenido relacionado
Use los siguientes recursos para implementar el método de escalado que se adapte a la carga de trabajo:
- Escalado manual de pods o nodos
- ¿Cuándo debo usar el escalado automático horizontal de pods (HPA) en Kubernetes?
- Uso del escalador automático vertical de pods en AKS
- Uso del escalador automático de clústeres en AKS
- Uso del complemento KEDA
- Uso del aprovisionamiento automático de nodos
- Creación de nodos virtuales con Azure Container Instances
Para más información sobre los conceptos básicos de Kubernetes y AKS, consulte: