Ayude a mejorar esta página
Para contribuir a esta guía del usuario, elija el enlace Edit this page on GitHub que se encuentra en el panel derecho de cada página.
Optimización de costos en el modo automático de EKS
El modo automático de EKS optimiza de forma continua los costos de computación del clúster mediante la consolidación, el empaquetado en contenedores y el dimensionamiento correcto. Sin embargo, determinadas configuraciones de carga de trabajo pueden impedir estas optimizaciones. En este tema se explica cómo funciona la optimización de costos, qué puede bloquearla y cómo configurar el clúster para mantener la rentabilidad.
Cómo optimiza los costos el modo automático de EKS
El modo automático de EKS reduce los costos de computación mediante los siguientes mecanismos:
-
Empaquetado de contenedores: al programar los pods en los nodos, el modo automático de EKS selecciona los tipos de instancias que mejor se ajustan a las solicitudes de recursos agregadas, lo que minimiza la capacidad no utilizada.
-
Consolidación: el modo automático de EKS evalúa periódicamente los nodos en ejecución y los sustituye o elimina cuando las cargas de trabajo pueden ejecutarse en menos instancias o en instancias menos costosas.
-
Dimensionamiento correcto: a medida que las cargas de trabajo se reducen verticalmente, el modo automático de EKS consolida los pods en nodos más pequeños y termina las instancias infrautilizadas.
Estas optimizaciones se ejecutan de forma continua sin intervención manual. Sin embargo, determinadas anotaciones de pods y configuraciones de NodePool pueden impedir que la consolidación se lleve a cabo.
Grupos de nodos integrados y barreras de protección de costos
Los grupos de nodos general-purpose y system integrados ya aplican varios valores predeterminados de protección de costos:
-
Familias de instancias restringidas a C, M y R: no se permiten tipos de instancias aceleradas (P, G, Inf, Trn) o exóticas.
-
Solo capacidad bajo demanda: sin instancias de spot, lo que evita el abandono provocado por interrupciones, pero también significa que no hay ahorros de spot.
-
Generación 5 o más reciente: se excluyen las generaciones de instancias más antiguas y menos rentables.
Si solo utiliza los grupos de nodos integrados, ya se beneficia de estas barreras de protección. La guía de este tema sobre la exclusión de las familias de instancias y la restricción del tamaño de las instancias es más relevante al crear NodePools personalizados, que no heredan estas restricciones.
Sin embargo, incluso con grupos de nodos integrados, las siguientes secciones se le continúan aplicando:
-
Qué bloquea la consolidación: la anotación
do-not-disrupty los PDB restrictivos bloquean la consolidación independientemente del NodePool que haya aprovisionado el nodo. -
Uso de los límites de NodePool como límite de costo: los grupos de nodos integrados no tienen el recurso
limitsconfigurado. Si las cargas de trabajo se pueden escalar de manera significativa, considere la posibilidad de crear un NodePool personalizado con límites en lugar de confiar en los grupos integrados no vinculados. -
Costo y ciclo de vida de los nodos: la superposición de reemplazo de nodos se aplica a todos los nodos, incluidos los aprovisionados por grupos integrados.
| Barrera de protección | Grupos de nodos integrados | NodePools personalizados |
|---|---|---|
|
Exclusión de instancias aceleradas |
Forzada |
Debe configurar |
|
Límites de tamaño de instancia |
No configurado |
Debe configurar |
|
Recurso |
No configurado |
Debe configurar |
|
Solo bajo demanda |
Forzada |
Debe elegir (spot o bajo demanda) |
|
Protección de consolidación ( |
Su responsabilidad |
Su responsabilidad |
Qué bloquea la consolidación
La consolidación se bloquea cuando el modo automático de EKS determina que interrumpir un nodo infringiría los requisitos de disponibilidad de una carga de trabajo. Las siguientes configuraciones impiden la consolidación:
La anotación do-not-disrupt
La anotación karpenter.sh/do-not-disrupt indica al modo automático de EKS que conserve un nodo mientras el pod anotado se ejecute en él. Esto evita que el nodo se consolide, reemplace o termine, incluso si el nodo está infrautilizado.
metadata: annotations: karpenter.sh/do-not-disrupt: "true"
importante
Implicación de costos: cuando un pod contiene la anotación do-not-disrupt, el nodo en el que se ejecuta queda exento de consolidación. Esto significa:
-
El nodo continúa ejecutándose con su tamaño de instancia actual, independientemente de su uso real.
-
El uso de vCPU y memoria en ese nodo puede permanecer elevado incluso cuando la demanda de la carga de trabajo disminuya.
-
Si varios pods repartidos en varios nodos contienen esta anotación, la consolidación en todo el clúster se reduce considerablemente, lo que se traduce en un aumento sostenido de los costos.
La anotación do-not-disrupt es un mecanismo de disponibilidad. No tiene en cuenta el costo. Úsela solo para cargas de trabajo en las que una interrupción a mitad de la ejecución provoque la pérdida de datos o una modificación significativa del trabajo, por ejemplo, en trabajos por lotes de larga duración o procesos con estado sin puntos de control.
Alternativas que tener en cuenta:
-
Presupuestos de interrupción de pods (PDB): utilice los PDB para controlar la tasa de interrupciones en lugar de bloquearla por completo. Los PDB permiten continuar con la consolidación y, al mismo tiempo, garantizan que quede disponible un número mínimo de réplicas.
-
Cargas de trabajo de menor duración: en el caso de los ejecutores de CI/CD y los agentes de compilación, permita las interrupciones y confíe en la lógica de reintento integrada del sistema de CI en lugar de utilizar
do-not-disrupt. -
Anotaciones por tiempo limitado: aplique
do-not-disruptsolo durante una operación crítica y, después, elimínelas mediante programación cuando se complete la operación.
Presupuestos de interrupción de pods (PDB)
Los PDB que establecen maxUnavailable: 0 o minAvailable igualan el recuento de réplicas actual bloquean de manera efectiva toda la consolidación de los pods afectados. Revise los PDB para asegurarse de que permiten interrumpir al menos un pod a la vez.
Uso de los límites de NodePool como límite de costo
El NodePool limits estableció un límite estricto para los recursos de computación totales que un NodePool puede aprovisionar. Cuando se alcanza el límite, el modo automático de EKS deja de lanzar nuevos nodos para ese NodePool. Esto sucede incluso si los pods están pendientes.
Utilice limits como barrera de protección de costos, especialmente para NodePools que atienden cargas de trabajo que no son de producción, de prueba o en ráfagas, en las que el escalado no vinculado no es adecuado.
apiVersion: karpenter.sh/v1 kind: NodePool metadata: name: ci-runners spec: template: spec: nodeClassRef: group: eks.amazonaws.com kind: NodeClass name: default requirements: - key: "eks.amazonaws.com/instance-category" operator: In values: ["c", "m"] limits: cpu: "500" memory: 1000Gi
En este ejemplo, el NodePool ci-runners no puede superar las 500 vCPU ni los 1000 GiB de memoria en total en todos los nodos que aprovisiona. Los pods que superen este límite permanecen en estado Pending hasta que se libere capacidad.
sugerencia
Establezca limits en función del tamaño máximo de ráfaga esperado más un búfer para reemplazar los nodos. Revise el uso de NodePool con regularidad y ajuste los límites según cambien los patrones de la carga de trabajo.
Exclusión de familias de instancias para controlar los costos
De forma predeterminada, el modo automático de EKS selecciona entre una amplia gama de tipos de instancias para maximizar la flexibilidad de programación. Para las cargas de trabajo que no requieren hardware especializado, restrinja las familias de instancias para evitar que se lancen tipos de instancias costosos.
Exclusión de instancias aceleradas
Si las cargas de trabajo no solicitan recursos de aceleradores ni GPU, excluya las familias de instancias aceleradas del NodePool. Esto evita situaciones en las que se seleccionan instancias aceleradas durante las restricciones de capacidad.
spec: template: spec: requirements: - key: "eks.amazonaws.com/instance-category" operator: In values: ["c", "m", "r"]
Al especificar solo las categorías optimizadas para la computación, de uso general y optimizadas para la memoria, se excluyen de la selección las familias de instancias aceleradas (P, G, Inf, Trn) y otras familias de instancias especializadas.
Cómo interactúa la selección de instancias con las restricciones de capacidad
El modo automático de EKS deja de priorizar los tipos de instancias aceleradas y exóticas durante la selección de instancias normales. Sin embargo, cuando se producen errores de lanzamiento continuos, el modo automático de EKS se lanzará desde cualquier otro tipo de instancia disponible para priorizar la disponibilidad de la carga de trabajo. Por ejemplo, esto ocurre cuando las Service Quotas de EC2 se agotan temporalmente para todos los tipos de instancias preferidos.
Para evitar este comportamiento alternativo, restrinja explícitamente los requisitos de NodePool a solo las categorías de instancias que necesite la carga de trabajo. Cuando los tipos preferidos no estén disponibles y la configuración del NodePool no permita ningún otro tipo, los pods permanecen en estado Pending en lugar de programarse en instancias costosas.
Restricción de tamaños de instancias
Además de restringir las familias de instancias, puede limitar el tamaño máximo de las instancias en el NodePool. Restringir el tamaño de las instancias limita la exposición a los costos de cualquier nodo individual que no se pueda consolidar. Por ejemplo, un nodo bloqueado por una anotación do-not-disrupt no puede reducirse aunque su carga de trabajo sea pequeña.
Use la etiqueta eks.amazonaws.com/instance-cpu para limitar el tamaño máximo de las instancias en los requisitos de NodePool:
requirements: - key: "eks.amazonaws.com/instance-cpu" operator: Lte values: ["32"]
Esta configuración impide que el modo automático de EKS lance instancias de más de 32 vCPU en este NodePool.
Para identificar las oportunidades de optimización en un clúster existente, revise las instancias en ejecución más grandes. Si se bloquea constantemente la consolidación de nodos grandes, el costo por nodo de esa capacidad inactiva es proporcionalmente mayor.
Patrones recomendados para cargas de trabajo en ráfagas
Las canalizaciones de CI/CD, los trabajos por lotes y los ejecutores efímeros crean patrones de ráfaga e inactividad que requieren una configuración específica para mantener la rentabilidad.
Valores predeterminados recomendados para cargas de trabajo en ráfagas
| Configuración | Recomendación |
|---|---|
|
|
No los utilice para ejecutores de CI/CD. En su lugar, confíe en los mecanismos de reintento y cola del sistema de CI. |
|
NodePool |
Establezca un límite máximo de CPU y memoria en función de la simultaneidad máxima esperada más el búfer para la superposición de reemplazo de nodos. |
|
Categorías de instancias |
Restrinja a familias |
|
Tamaños de instancias |
Considere la posibilidad de restringir a tamaños moderados (por ejemplo, de 4 a 32 vCPU) para limitar la exposición a los costos de cualquier nodo único que no pueda consolidarse. |
|
Periodo de consolidación |
Utilice la configuración |
|
Capacity type (Tipo de capacidad) |
Utilice instancias de spot para ejecutores con tolerancia a errores. Combínelas con instancias bajo demanda para crear agentes que mantengan el estado durante la ejecución. |
Ejemplo: NodePool de ejecutor de CI
apiVersion: karpenter.sh/v1 kind: NodePool metadata: name: ci-runners spec: template: spec: nodeClassRef: group: eks.amazonaws.com kind: NodeClass name: default requirements: - key: "eks.amazonaws.com/instance-category" operator: In values: ["c", "m"] - key: "eks.amazonaws.com/instance-cpu" operator: Lte values: ["32"] - key: "karpenter.sh/capacity-type" operator: In values: ["spot", "on-demand"] limits: cpu: "500" memory: 1000Gi disruption: consolidationPolicy: WhenEmptyOrUnderutilized consolidateAfter: 30s
Esta configuración:
-
Restringe a familias de instancias rentables
-
Limita la capacidad total del NodePool a 500 vCPU
-
Permite una consolidación agresiva (30 segundos después de eliminar los pods)
-
Permite la capacidad de spot y bajo demanda
Costo y ciclo de vida de los nodos
El modo automático EKS sustituye los nodos mediante una interrupción controlada cuando se desvían de las especificaciones deseadas (por ejemplo, tras el lanzamiento de una nueva AMI del modo automático) o cuando la vida útil del nodo se acerca a su fin. Durante una sustitución controlada:
-
Se lanza un nuevo nodo de reemplazo y queda listo.
-
Los pods se vacían del nodo anterior mientras se respetan los presupuestos de interrupción de pods.
-
Durante un breve periodo, tanto el nodo antiguo como el de reemplazo se ejecutarán simultáneamente.
En el caso de los clústeres con nodos grandes o numerosos, esta superposición puede generar aumentos periódicos de los costos. Para minimizar el impacto:
-
Revise los presupuestos de interrupción: asegúrese de que los presupuestos de interrupción permitan el agotamiento puntual. Los presupuestos restrictivos amplían el periodo de superposición durante el cual funcionan los nodos antiguos y los nuevos.
-
Dimensione instancias con el tamaño correcto: las instancias más pequeñas reducen el costo absoluto del plazo de superposición.
-
Reduzca la vida útil máxima de los nodos: los valores de expiración más cortos (por ejemplo, 7 días) crean eventos de reemplazo más frecuentes, pero más pequeños. Esto distribuye el costo de manera más uniforme a lo largo del tiempo en lugar de concentrarlo.
Para obtener más información sobre el ciclo de vida de los nodos, consulte Más información sobre las instancias administradas del modo automático de Amazon EKS.
