Modo automático de EKS frente a Karpenter Etiquetas conocidas de IA y ML comunes Etiquetas de programación para la capacidad reservada Comportamiento de vencimiento de la reserva NodePools de capacidad estática bloques de capacidad para ML Reservas de capacidad bajo demanda (ODCR)Bajo demanda Spot

Administración de la computación para cargas de trabajo de IA y ML con el modo automático de EKS y Karpenter

sugerencia

Regístrese en los próximos talleres de IA/ML de Amazon EKS.

En esta sección, se trata cómo administrar la computación acelerada (AWS Trainium, GPU de NVIDIA) para las cargas de trabajo de entrenamiento de IA e inferencia con el modo automático de Amazon EKS o Karpenter autoadministrado.

El modo automático de EKS y Karpenter admiten dos modos de aprovisionamiento: aprovisionamiento dinámico y aprovisionamiento estático. Con el aprovisionamiento dinámico, el modo automático de EKS y Karpenter aprovisionan y escalan las instancias de computación acelerada a medida que se programan las cargas de trabajo en el clúster. Con el aprovisionamiento estático, el modo automático de EKS y Karpenter aprovisionan y mantienen un número fijo de nodos. El aprovisionamiento dinámico y estático se puede utilizar en el mismo clúster para mantener un grupo de capacidad de línea de base constante y, al mismo tiempo, adaptarse a las demandas de la carga de trabajo.

El modo automático de EKS y Karpenter admiten las cuatro opciones de compra de capacidad (bajo demanda, spot, bloques de capacidad y ODCR) y siempre aprovisionan primero la capacidad reservada, seguida de spot o bajo demanda.

Modo automático de EKS frente a Karpenter

Ambos enfoques comparten la API NodePool, pero difieren en cuanto a la propiedad operativa, las API de recursos, la compatibilidad con los sistemas operativos, la gestión de las interrupciones de spot y la flexibilidad de configuración.

Característica	Modo automático de EKS	Karpenter autoadministrado
Lo mejor para	Equipos que prefieren una infraestructura administrada con costos operativos mínimos	Equipos que prefieren tener el control total sobre el ciclo de vida de los nodos, las AMI, el ajuste del SO y los parches.
Modelo operativo	AWS aprovisiona y administra el controlador de Karpenter, los controladores de GPU y Trainium, los complementos para dispositivos, los parches del SO y la gestión de interrupciones de spot.	Usted instala y opera el controlador de Karpenter en el clúster y es responsable de los controladores de GPU y Trainium, los complementos para dispositivos, el ciclo de vida de la AMI, los parches y la gestión de interrupciones de spot.
Opciones de computación	Bajo demanda, spot, ODCR y bloques de capacidad para ML	Bajo demanda, spot, ODCR y bloques de capacidad para ML
API de recursos	`NodePool` (`karpenter.sh/v1`), `NodeClass` (`eks.amazonaws.com/v1`).	`NodePool` (`karpenter.sh/v1`), `EC2NodeClass` (`karpenter.k8s.aws/v1`).
Sistema operativo del nodo	Solo Bottlerocket. Se incluyen las dependencias de GPU de NVIDIA, AWS Trainium y EFA.	AL2023, Bottlerocket, Windows o su propia AMI.
Duración del nodo	Duración máxima del nodo de 21 días para la aplicación de parches de seguridad. Las cargas de trabajo deben tolerar la rotación de nodos.	Define el ciclo de vida del nodo mediante los presupuestos de `expireAfter` y de interrupción del NodePool.
Gestión de interrupciones de spot	Nativo. No se requiere ninguna cola de SQS ni Node Termination Handler.	Es su responsabilidad configurarlo y habilitarlo.
Extracción rápida de contenedores	La extracción en paralelo de SOCI se incluye en todas las instancias de las familias G, P y Trn	Es su responsabilidad configurarlo y habilitarlo.
Grupos de ubicación de EC2	Clúster, partición, distribución	Clúster, partición, distribución
Configuración de la interfaz de red	Configuración por interfaz para el tipo `interface` o `EFA-only`	Configuración por interfaz para el tipo `interface` o `EFA-only`
Reparación de nodos	Habilitado de forma predeterminada, se incluye el agente de supervisión de nodos EKS	Habilitado de forma opcional, el agente de supervisión de nodos de EKS es autoadministrado
Precios	Cuota de administración del modo automático de EKS además del costo subyacente de la instancia de EC2.	Código abierto. Pagará por las instancias de EC2 subyacentes.

Etiquetas conocidas de IA y ML comunes

El modo automático de EKS y Karpenter muestran etiquetas de instancia que puede usar en requirements del NodePool y nodeSelector o nodeAffinity del pod para segmentar las cargas de trabajo sin necesidad de codificar de forma rígida los tipos de instancia. El prefijo de la etiqueta difiere entre ambos: el modo automático de EKS utiliza eks.amazonaws.com/, mientras que Karpenter autoadministrado usa karpenter.k8s.aws/.

En las siguientes tablas, se muestran las etiquetas relevantes que se pueden usar en NodePools. El modo automático de EKS y Karpenter también aplican las etiquetas que figuran en la documentación de Karpenter a los nodos como parte del proceso de aprovisionamiento, que pueden utilizarse posteriormente para segmentar las cargas de trabajo.

EKS Auto Mode

Para ver la lista completa, consulte Etiquetas compatibles con el modo automático de EKS.

Etiqueta	Ejemplo de valor	Descripción
`eks.amazonaws.com/instance-family`	`p5`	Tipos de instancias de propiedades similares, pero con diferentes cantidades de recursos.
`eks.amazonaws.com/instance-category`	`p`	Categoría de instancia, por lo general, con la letra antes del número de generación.
`eks.amazonaws.com/instance-generation`	`5`	Número de generación de tipo de instancia dentro de una categoría.
`eks.amazonaws.com/instance-gpu-name`	`h100`	Nombre de la GPU en la instancia.
`eks.amazonaws.com/instance-gpu-manufacturer`	`nvidia`	Nombre del fabricante de la GPU.
`eks.amazonaws.com/instance-gpu-count`	`8`	Cantidad de GPU en la instancia.
`eks.amazonaws.com/instance-gpu-memory`	`81920`	Mebibytes de memoria por GPU.
`karpenter.sh/capacity-type`	`reserved`	Tipo de capacidad: `spot`, `on-demand` o `reserved`.
`topology.kubernetes.io/zone`	`us-east-1a`	Zona de disponibilidad.

Self-managed Karpenter

Para ver la lista completa, consulte Etiquetas conocidas de Karpenter.

Etiqueta	Ejemplo de valor	Descripción
`karpenter.k8s.aws/instance-family`	`p5`	Tipos de instancias de propiedades similares, pero con diferentes cantidades de recursos.
`karpenter.k8s.aws/instance-category`	`p`	Categoría de instancia, por lo general, con la letra antes del número de generación.
`karpenter.k8s.aws/instance-generation`	`5`	Número de generación de tipo de instancia dentro de una categoría.
`karpenter.k8s.aws/instance-gpu-name`	`h100`	Nombre de la GPU en la instancia.
`karpenter.k8s.aws/instance-gpu-manufacturer`	`nvidia`	Nombre del fabricante de la GPU.
`karpenter.k8s.aws/instance-gpu-count`	`8`	Cantidad de GPU en la instancia.
`karpenter.sh/capacity-type`	`reserved`	Tipo de capacidad: `spot`, `on-demand` o `reserved`.
`topology.kubernetes.io/zone`	`us-east-1a`	Zona de disponibilidad.
`kubernetes.io/arch`	`amd64`	Arquitectura de la CPU.

Etiquetas de programación para la capacidad reservada

Cuando el modo automático de EKS o Karpenter lanzan un nodo en una reserva, agregan las siguientes etiquetas. Utilícelas en el nodeSelector, la afinidad de nodos o los requisitos del NodePool para dirigir las cargas de trabajo.

karpenter.sh/capacity-type: reserved, on-demand, o spot. Indica la capacidad que respalda el nodo.
karpenter.k8s.aws/capacity-reservation-id: ID de reserva específico en el que se lanzó el nodo.
karpenter.k8s.aws/capacity-reservation-type: default para ODCR, capacity-block para bloques de capacidad.

En los siguientes ejemplos, se muestran patrones de programación comunes:

Fijación de un pod a una reserva específica (sin alternativas):


spec:
  nodeSelector:
    karpenter.sh/capacity-type: reserved
    karpenter.k8s.aws/capacity-reservation-id: "cr-0123456789abcdef0"

Segmentación solo de nodos de ODCR (cualquier ODCR, no bloques de capacidad):


spec:
  nodeSelector:
    karpenter.sh/capacity-type: reserved
    karpenter.k8s.aws/capacity-reservation-type: default

Segmentación de cualquier capacidad reservada (ODCR o bloque de capacidad):


spec:
  nodeSelector:
    karpenter.sh/capacity-type: reserved

Preferencia de la capacidad reservada, pero spot o bajo demanda como alternativas si no está disponible:


spec:
  affinity:
    nodeAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
        - weight: 100
          preference:
            matchExpressions:
              - key: karpenter.sh/capacity-type
                operator: In
                values: ["reserved"]

Comportamiento de vencimiento de la reserva

Las ODCR y los bloques de capacidad se comportan de forma diferente cuando finaliza la reserva. Asegúrese de que la estrategia de programación y puntos de control coincida con el tipo de reserva que respalda su carga de trabajo.

ODCR

Una instancia lanzada en una ODCR no está en esa ODCR de forma indefinida. La ODCR puede vencer, cancelarse o la instancia puede eliminarse manualmente de la ODCR. Si ocurre alguna de estas situaciones y el modo automático de EKS o Karpenter detecta que la instancia ya no pertenece a una ODCR, actualiza la etiqueta karpenter.sh/capacity-type del nodo de reserved a on-demand. La instancia continúa funcionando con la capacidad bajo demanda estándar y los pods existentes continúan funcionando ininterrumpidamente.

nota

Los pods programados con un nodeSelector: karpenter.sh/capacity-type: reserved estricto no se programarán en el nodo si se han vuelto a etiquetar. Para que las cargas de trabajo sobrevivan al vencimiento o la cancelación de la ODCR, utilice el patrón preferredDuringSchedulingIgnoredDuringExecution que se muestra anteriormente en lugar de un nodeSelector.

Bloques de capacidad

A diferencia de las ODCR, los bloques de capacidad siempre tienen una hora de finalización y EC2 termina las instancias de los bloques de capacidad 30 minutos antes de la hora de finalización (60 minutos para los tipos de instancias UltraServer). Planifique los trabajos de entrenamiento e inferencia para completar o guardar el estado antes de que finalice el periodo de reserva. Los pods que utilicen un nodeSelector estricto para un capacity-reservation-id específico pasan a Pending una vez que el bloque venza y no se reprogramarán en ningún otro lugar. Combine los puntos de control con el patrón de afinidad flexible anterior si necesita que las cargas de trabajo pasen a otra capacidad durante el vencimiento del bloque de capacidad.

Puede usar instancias reservadas hasta 30 minutos antes de la hora de finalización del bloque de capacidad para la mayoría de los tipos de instancias, o 60 minutos antes de la hora de finalización para los tipos de instancias UltraServer.
El modo automático de EKS y Karpenter comienzan a vaciar de forma preventiva los nodos de un bloque de capacidad 10 minutos antes de que EC2 inicie la terminación, por lo que las cargas de trabajo tienen tiempo de guardar puntos de control y cerrarse de forma controlada.

NodePools de capacidad estática

El modo automático de EKS y Karpenter admiten NodePools de capacidad estática, que mantienen un número fijo de nodos independientemente de la demanda de la carga de trabajo. Los grupos estáticos eliminan los retrasos en el arranque en frío para inferencias sensibles a la latencia y permiten reservar una huella de infraestructura mínima para el clúster.

Para configurar la capacidad estática, se establece el campo replicas en el NodePool.

Consideraciones

Una vez que replicas está establecido en un NodePool, no se puede eliminar. Un solo NodePool no puede cambiar entre el aprovisionamiento de capacidad estática y dinámica.
Los NodePools de capacidad estática no se tienen en cuenta para la consolidación. Establezca limits.nodes por encima de replicas para permitir el escalado temporal durante el vencimiento o la desviación de la AMI.
Para una distribución predecible de las zonas de disponibilidad (AZ), cree un NodePool de capacidad estática por AZ en lugar de abarcar varias zonas en un solo grupo.

EKS Auto Mode

En el siguiente ejemplo, se muestra un NodePool de capacidad estática que utiliza el NodeClass del modo automático de EKS predeterminado y crea un NodePool estático con 4 nodos (replicas) que puede ser como máximo de 6 nodos (limits.nodes).


apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: gpu-static-inference
spec:
  replicas: 4
  template:
    spec:
      nodeClassRef:
        group: eks.amazonaws.com
        kind: NodeClass
        name: default
      requirements:
        - key: "karpenter.sh/capacity-type"
          operator: In
          values: ["on-demand"]
        - key: "karpenter.k8s.aws/instance-family"
          operator: In
          values: ["g6e"]
        - key: "topology.kubernetes.io/zone"
          operator: In
          values: ["us-east-1a"]
      taints:
        - key: nvidia.com/gpu
          value: "true"
          effect: NoSchedule
  limits:
    nodes: 6   # Allow temporary headroom during node replacement

Self-managed Karpenter

Con Karpenter autoadministrado, la capacidad estática se limita mediante la característica StaticCapacity alfa (lanzada en la versión v1.8 de Karpenter), que debe estar habilitada en los valores de Helm:


settings:
  featureGates:
    staticCapacity: true

El NodePool hace referencia a una EC2NodeClass personalizada denominada my-nodeclass y crea un NodePool estático con 4 nodos (replicas) que puede ser como máximo de 6 nodos (limits.nodes).


apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: gpu-static-inference
spec:
  replicas: 4
  template:
    spec:
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: my-nodeclass
      requirements:
        - key: "karpenter.sh/capacity-type"
          operator: In
          values: ["on-demand"]
        - key: "karpenter.k8s.aws/instance-family"
          operator: In
          values: ["g6e"]
        - key: "topology.kubernetes.io/zone"
          operator: In
          values: ["us-east-1a"]
      taints:
        - key: nvidia.com/gpu
          value: "true"
          effect: NoSchedule
  limits:
    nodes: 6   # Allow temporary headroom during node replacement

bloques de capacidad para ML

Los bloques de capacidad para ML le permiten reservar instancias de la familia P y Trainium para un periodo futuro definido. Son de prepago, por lo que el modo automático de EKS y Karpenter los consideran gratuitos y los priorizan frente a spot y bajo demanda. Los bloques de capacidad para ML pueden tener una duración de reserva de entre 1 y 14 días o un múltiplo de 7 días, hasta 182 días (6 meses).

Para usar bloques de capacidad para ML con el modo automático de EKS o Karpenter, configure capacityReservationSelectorTerms con el ID de reserva de capacidad en su NodeClass. No puede utilizar la coincidencia de reservas abiertas con bloques de capacidad para ML. Un término puede especificar un ID, un conjunto de etiquetas o criterios de coincidencia de instancias para llevar a cabo la selección. Al especificar las etiquetas, seleccionará todas las reservas de capacidad accesibles desde la cuenta que tengan etiquetas coincidentes. Esto se puede restringir aún más si se especifica el ID de la cuenta del propietario.

Para obtener más ejemplos, consulte la documentación de Karpenter.

EKS Auto Mode

Cree una NodeClass que haga referencia a la reserva de bloques de capacidad y, a continuación, cree un NodePool que la utilice.

Con consolidateAfter: Never establecido, Karpenter no intentará reemplazar, fusionar ni terminar los nodos para reducir los costos ni empaquetar las cargas de trabajo de manera más eficiente. Esto se recomienda para los bloques de capacidad, ya que la capacidad ya está prepagada.


apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
  name: capacity-block-gpu
spec:
  capacityReservationSelectorTerms:
    - id: "cr-0123456789abcdef0"   # Your Capacity Block reservation ID
    # Alternative: select by tags
    # - tags:
    #     role: "production-inference"
    #   owner: "012345678901"
---
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: gpu-capacity-block
spec:
  disruption:
    consolidationPolicy: WhenEmpty
    consolidateAfter: Never
  template:
    spec:
      nodeClassRef:
        group: eks.amazonaws.com
        kind: NodeClass
        name: capacity-block-gpu
      requirements:
        - key: "karpenter.sh/capacity-type"
          operator: In
          values: ["reserved"]
        - key: "karpenter.k8s.aws/instance-family"
          operator: In
          values: ["p5", "p5e", "p5en", "p4d"]
      taints:
        - key: nvidia.com/gpu
          value: "true"
          effect: NoSchedule

Self-managed Karpenter

Cree una EC2NodeClass que incluya selectores de AMI, subred y grupos de seguridad además de capacityReservationSelectorTerms y, a continuación, cree un NodePool que la utilice.


apiVersion: karpenter.k8s.aws/v1
kind: EC2NodeClass
metadata:
  name: capacity-block-gpu
spec:
  amiSelectorTerms:
    - alias: al2023@latest
  subnetSelectorTerms:
    - tags:
        karpenter.sh/discovery: ml-cluster
  securityGroupSelectorTerms:
    - tags:
        karpenter.sh/discovery: ml-cluster
  capacityReservationSelectorTerms:
    - id: "cr-0123456789abcdef0" # Your Capacity Block reservation ID
    # Alternative: select by tags
    # - tags:
    #     role: "production-inference"
    #   owner: "012345678901"
---
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: gpu-capacity-block
spec:
  disruption:
    consolidationPolicy: WhenEmpty
    consolidateAfter: Never
  template:
    spec:
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: capacity-block-gpu
      requirements:
        - key: "karpenter.sh/capacity-type"
          operator: In
          values: ["reserved"]
        - key: "karpenter.k8s.aws/instance-family"
          operator: In
          values: ["p5", "p5e", "p5en", "p4d"]
      taints:
        - key: nvidia.com/gpu
          value: "true"
          effect: NoSchedule

Reservas de capacidad bajo demanda (ODCR)

Las ODCR garantizan la capacidad en una zona de disponibilidad (AZ) específica sin un compromiso a largo plazo. Se le facturará según las tarifas estándar bajo demanda, tanto si utiliza la capacidad como si no. Las ODCR son compatibles con todas las familias de GPU de NVIDIA, incluidas las instancias de la familia G que no son compatibles con bloques de capacidad para ML. Las ODCR son de prepago, por lo que el modo automático de EKS y Karpenter los consideran gratuitos y los priorizan frente a spot y bajo demanda.

Las ODCR se comportan de forma diferente a los bloques de capacidad para ML al final de la reserva. Cuando una ODCR vence o se cancela, la instancia continúa ejecutándose de forma estándar bajo demanda. Para obtener más información, consulte Comportamiento de vencimiento de la reserva.

Para usar las ODCR con el modo automático de EKS o Karpenter, configure capacityReservationSelectorTerms con los términos de la reserva de capacidad en su NodeClass. Un término puede especificar un ID, un conjunto de etiquetas o criterios de coincidencia de instancias para llevar a cabo la selección. Al especificar las etiquetas, seleccionará todas las reservas de capacidad accesibles desde la cuenta que tengan etiquetas coincidentes. Al especificar los criterios de coincidencia de instancias, selecciona las reservas según su comportamiento de coincidencia: abiertas (coincide con todas las instancias compatibles) o segmentadas (solo coincide con las instancias segmentadas explícitamente). Esto se puede restringir aún más si se especifica el ID de la cuenta del propietario.

Para obtener más ejemplos, consulte la documentación de Karpenter.

EKS Auto Mode

Cree una NodeClass con capacityReservationSelectorTerms y un NodePool que priorice reserved con on-demand como alternativa. Fije topology.kubernetes.io/zone a la AZ de la ODCR:


apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
  name: odcr-gpu-production
spec:
  capacityReservationSelectorTerms:
    - id: "cr-0987654321fedcba0"
    # Alternative: select by tags
    # - tags:
    #     Purpose: "production-inference"
    #   owner: "012345678901"
---
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: gpu-reserved-production
spec:
  disruption:
    consolidationPolicy: WhenEmpty
    consolidateAfter: Never
  template:
    spec:
      nodeClassRef:
        group: eks.amazonaws.com
        kind: NodeClass
        name: odcr-gpu-production
      requirements:
        - key: "karpenter.sh/capacity-type"
          operator: In
          values: ["reserved", "on-demand"]
        - key: "karpenter.k8s.aws/instance-family"
          operator: In
          values: ["p5", "g6e"]
        - key: "topology.kubernetes.io/zone"
          operator: In
          values: ["us-east-1a"]
      taints:
        - key: nvidia.com/gpu
          value: "true"
          effect: NoSchedule

Self-managed Karpenter

Cree una EC2NodeClass con selectores de AMI, subred y grupos de seguridad además de capacityReservationSelectorTerms y, a continuación, cree un NodePool:


apiVersion: karpenter.k8s.aws/v1
kind: EC2NodeClass
metadata:
  name: odcr-gpu-production
spec:
  amiSelectorTerms:
    - alias: al2023@latest
  subnetSelectorTerms:
    - tags:
        karpenter.sh/discovery: ml-cluster
  securityGroupSelectorTerms:
    - tags:
        karpenter.sh/discovery: ml-cluster
  capacityReservationSelectorTerms:
    - id: "cr-0987654321fedcba0"
---
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: gpu-reserved-production
spec:
  disruption:
    consolidationPolicy: WhenEmpty
    consolidateAfter: Never
  template:
    spec:
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: odcr-gpu-production
      requirements:
        - key: "karpenter.sh/capacity-type"
          operator: In
          values: ["reserved", "on-demand"]
        - key: "karpenter.k8s.aws/instance-family"
          operator: In
          values: ["p5", "g6e"]
        - key: "topology.kubernetes.io/zone"
          operator: In
          values: ["us-east-1a"]
      taints:
        - key: nvidia.com/gpu
          value: "true"
          effect: NoSchedule

Bajo demanda

Bajo demanda es el tipo de capacidad predeterminado y se puede utilizar con aprovisionamiento estático o dinámico en el modo automático de EKS y Karpenter. Para solicitar instancias bajo demanda de forma explícita, establezca karpenter.sh/capacity-type: on-demand en su NodePool. El modo automático de EKS y Karpenter seleccionan la instancia de menor precio que satisfaga las solicitudes de recursos del pod. Utilice la opción bajo demanda para el desarrollo, la creación de prototipos, el escalado de inferencias impredecible y cualquier carga de trabajo que requiera disponibilidad inmediata sin riesgo de interrupción.

Spot

Instancias de spot ofrece hasta un 90 % de ahorro en comparación con las instancias bajo demanda al utilizar la capacidad sobrante de EC2. AWS puede reclamar instancias de spot con un aviso de interrupción de 2 minutos. Para maximizar la disponibilidad, incluya varias familias de instancias en el NodePool. Combine las cargas de trabajo de Spot con un PodDisruptionBudget y un punto de control en un almacenamiento duradero (Amazon S3 o Amazon EFS) a intervalos regulares para que los pods puedan guardar el estado durante el plazo de vaciado.

Spot es ideal para cargas de trabajo de entrenamiento e inferencia reanudables y tolerantes a errores, en las que se aceptan interrupciones ocasionales a cambio de un importante ahorro de costos.

Entre los candidatos comunes, se incluyen los siguientes:

Ajuste y barridos de hiperparámetros: muchas pruebas cortas y en paralelo que se pueden reintentar si se interrumpen.
Entrenamiento distribuido con puntos de control: trabajos de larga duración que guardan periódicamente el estado en S3 o FSx y que pueden reanudarse desde el último punto de control después de la pérdida del nodo.
Inferencia por lotes y sin conexión: trabajos de puntuación a gran escala sobre conjuntos de datos en los que la latencia de extremo a extremo se mide en horas en lugar de segundos.
Canalizaciones de preprocesamiento de datos e ingeniería de características: transformaciones en paralelo en grandes conjuntos de datos.
Punto de referencia y evaluación del modelo: tareas repetibles que producen resultados idempotentes.
Desarrollo, creación de prototipos y cuadernos: experimentación interactiva en la que los usuarios pueden tolerar reinicios ocasionales.

Evite spot para inferencias en tiempo real sensibles a la latencia, puntos de conexión de producción sujetos a SLA y cargas de trabajo que no utilizan puntos de control o que no toleran los reinicios.

Para solicitar instancias de spot de forma explícita, establezca karpenter.sh/capacity-type: spot en su NodePool.

EKS Auto Mode

El modo automático de EKS gestiona las interrupciones de spot de forma nativa. No se requiere ninguna cola de SQS ni Node Termination Handler.


apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: gpu-spot
spec:
  disruption:
    budgets:
      - nodes: 10%
    consolidationPolicy: WhenEmpty
    consolidateAfter: 1h
  template:
    spec:
      nodeClassRef:
        group: eks.amazonaws.com
        kind: NodeClass
        name: default
      requirements:
        - key: "karpenter.sh/capacity-type"
          operator: In
          values: ["spot"]
        - key: "karpenter.k8s.aws/instance-family"
          operator: In
          values: ["g6", "g6e", "g7e"]
        - key: "karpenter.k8s.aws/instance-gpu-manufacturer"
          operator: In
          values: ["nvidia"]
      taints:
        - key: nvidia.com/gpu
          value: "true"
          effect: NoSchedule
  limits:
    resources:
      nvidia.com/gpu: "64"

Self-managed Karpenter

Karpenter autoadministrado requiere que habilite la gestión nativa de las interrupciones en el controlador de Karpenter (no en el NodePool) mediante la configuración de una cola de interrupciones: una cola de SQS que recibe los eventos de interrupciones de spot de EC2 y de recomendación de reequilibrio. Lo configura una vez en el momento de la instalación.

Si instala Karpenter directamente con Helm, establezca settings.interruptionQueue en su values.yaml:


# karpenter values.yaml (Helm)
settings:
  clusterName: my-cluster
  interruptionQueue: my-queue   # Name of the SQS queue receiving Spot events

Si arrancas Karpenter con eksctl, establezca withSpotInterruptionQueue: true en el archivo de configuración del clúster. eksctl crea la cola de SQS y las reglas de EventBridge y configura el controlador de Karpenter para utilizarlas.


# eksctl ClusterConfig
karpenter:
  version: "${KARPENTER_VERSION}"
  withSpotInterruptionQueue: true

Una vez que el controlador está configurado para usar la cola, no es necesaria ninguna configuración adicional en los recursos individuales del NodePool. La gestión de las interrupciones se aplica a todo el clúster.


apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: gpu-spot
spec:
  disruption:
    budgets:
      - nodes: 10%
    consolidationPolicy: WhenEmpty
    consolidateAfter: 1h
  template:
    spec:
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: default
      requirements:
        - key: "karpenter.sh/capacity-type"
          operator: In
          values: ["spot"]
        - key: "karpenter.k8s.aws/instance-family"
          operator: In
          values: ["g6", "g6e", "g7e"]
        - key: "karpenter.k8s.aws/instance-gpu-manufacturer"
          operator: In
          values: ["nvidia"]
      taints:
        - key: nvidia.com/gpu
          value: "true"
          effect: NoSchedule
  limits:
    resources:
      nvidia.com/gpu: "64"

Aviso JavaScript está desactivado o no está disponible en su navegador.

Para utilizar la documentación de AWS, debe estar habilitado JavaScript. Para obtener más información, consulte las páginas de ayuda de su navegador.

Convenciones del documento

Administración de la capacidad

Grupos de nodos administrados y nodos autoadministrados