Ajudar a melhorar esta página

Para contribuir com este guia de usuário, escolha o link Editar esta página no GitHub, disponível no painel direito de cada página.

Controle da implantação de workloads em reservas de capacidade com o modo automático do EKS

É possível controlar a implantação de workloads em reservas de capacidade. O Modo Automático do EKS é compatível com reservas de capacidade sob demanda (ODCRs) do EC2, com blocos de capacidade do EC2 para ML e com reservas de capacidade interruptíveis (IODCRs).

Reservas de capacidade sob demanda (ODCRs) do EC2

As reservas de capacidade sob demanda (ODCRs) do EC2 permitem que você reserve capacidade computacional para suas instâncias do Amazon EC2 em uma determinada zona de disponibilidade por qualquer duração. Ao usar o Modo Automático do EKS, talvez você queira controlar se suas workloads do Kubernetes serão implantadas nessas instâncias reservadas para maximizar a utilização da capacidade pré-adquirida ou para garantir que workloads críticas tenham acesso aos recursos garantidos.

Por padrão, o Modo Automático do EKS é inicializado automaticamente em ODCRs abertas. No entanto, ao configurar capacityReservationSelectorTerms em um NodeClass, você pode controlar explicitamente quais ODCRs suas workloads usam. Os nós provisionados usando ODCRs configuradas terão karpenter.sh/capacity-type: reserved e serão priorizados em relação aos sob demanda e spot. Depois que esse recurso for habilitado, o Modo Automático do EKS não usará mais automaticamente ODCRs abertas. Elas deverão ser selecionadas explicitamente por um NodeClass, oferecendo controle preciso sobre o uso da reserva de capacidade em todo o cluster.

NodeClass de exemplo

apiVersion: eks.amazonaws.com/v1
kind: NodeClass
spec:
  # Optional: Selects upon on-demand capacity reservations and capacity blocks
  # for EKS Auto Mode to prioritize.
  capacityReservationSelectorTerms:
    - id: cr-56fac701cc1951b03
    # Alternative Approaches
    - tags:
        app: "my-app"
      # Optional owning account ID filter
      owner: "012345678901"

Este exemplo de NodeClass demonstra duas abordagens para selecionar ODCRs. O primeiro método faz referência direta a uma ODCR específica pelo seu ID (cr-56fac701cc1951b03). O segundo método usa a seleção baseada em tags, visando ODCRs com a tag Name: "targeted-odcr". Você também pode, opcionalmente, filtrar pela conta da AWS proprietária da reserva, o que é particularmente útil em cenários entre contas ou ao trabalhar com reservas de capacidade compartilhada.

Rótulos de agendamento para reservas de capacidade

Quando você configura capacityReservationSelectorTerms em um NodeClass, os nós provisionados de reservas de capacidade são rotulados com rótulos de agendamento adicionais. Você pode usar esses rótulos como requisitos do NodePool ou restrições de agendamento de pods (como afinidade de nós) para controlar o posicionamento de workloads.

Esses rótulos estão presentes apenas em nós com karpenter.sh/capacity-type: reserved.

Reservas de capacidade sujeitas a interrupção (IODCRs)

As reservas de capacidade sujeitas a interrupção permitem que você compartilhe a capacidade de reserva de capacidade sob demanda não utilizada com outras workloads em sua organização. Ao reaproveitar a capacidade não utilizada como ODCRs sujeitas a interrupção, as workloads adequadas para operações flexíveis e tolerantes a falhas, como processamento em lote e análise de dados, podem se beneficiar da capacidade temporariamente disponível. Os proprietários de reservas podem recuperar sua capacidade a qualquer momento, enquanto os consumidores de ODCRs sujeitas a interrupção receberão um aviso de interrupção antes do encerramento para permitir um desligamento ordenado ou pontos de verificação antes que o nó seja encerrado.

Você seleciona reservas de capacidade sujeitas a interrupção usando capacityReservationSelectorTerms da mesma forma que faria com um ODCR padrão: por ID ou por tags. Para controlar se as workloads são agendadas em uma capacidade reservada sujeita a interrupção ou em uma não sujeita a interrupção, use o rótulo de agendamento eks.amazonaws.com/capacity-reservation-interruptible.

Quando a capacidade é recuperada, as instâncias em execução recebem um aviso de interrupção de dois minutos por meio de eventos do EventBridge. Após o período de notificação, as instâncias em execução na capacidade recuperada entram em um estado de desligamento e são encerradas. O Modo Automático do EKS começará automaticamente a drenar os nós iniciados de reservas de capacidade sujeitas a interrupção quando o aviso de interrupção de dois minutos for recebido, permitindo que suas workloads sejam encerradas de forma ordenada antes que o nó seja recuperado.

Blocos de capacidade do EC2 para ML

Os blocos de capacidade para ML reservam instâncias de computação acelerada baseadas em GPU em uma data futura para fornecer suporte às workloads de machine learning (ML) de curta duração. As instâncias executadas em um bloco de capacidade são automaticamente colocadas próximas umas das outras nos Amazon EC2 UltraClusters para redes sem bloqueio de baixa latência com escala de petabits.

Para obter mais informações sobre as plataformas e os tipos de instância compatíveis, consulte Blocos de capacidade para ML no Guia do usuário do EC2.

Você pode criar uma NodeClass para o modo automático do EKS que usa um bloco de capacidade para ML, semelhante a um ODCR (descrito anteriormente).

As seguintes definições de amostra criam três recursos:

NodeClass de exemplo

Esta NodeClass faz referência a um bloco de capacidade específico para ML por meio do ID de reserva. Você pode obter esse ID no console do EC2.

apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
  name: gpu
spec:
  # Specify your Capacity Block reservation ID
  capacityReservationSelectorTerms:
    - id: cr-56fac701cc1951b03

Para obter mais informações, consulte Criar uma classe de nó para o Amazon EKS.

Exemplo de NodePool

Este NodePool se refere a NodeClass da gpu e especifica configurações importantes:

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: gpu
spec:
  template:
    spec:
      nodeClassRef:
        group: eks.amazonaws.com
        kind: NodeClass
        name: gpu
      requirements:
        - key: eks.amazonaws.com/instance-family
          operator: In
          values:
            - g6
            - p4d
            - p4de
            - p5
            - p5e
            - p5en
            - p6
            - p6-b200
        - key: karpenter.sh/capacity-type
          operator: In
          values:
            - reserved
            # Enable other capacity types
            # - on-demand
            # - spot
      taints:
        - effect: NoSchedule
          key: nvidia.com/gpu

Para obter mais informações, consulte Criar um grupo de nós para o Modo Automático do EKS.

Exemplo de pod

Este exemplo de pod demonstra como configurar uma workload para ser executada nos nós do bloco de capacidade:

apiVersion: v1
kind: Pod
metadata:
  name: nvidia-smi
spec:
  nodeSelector:
    # Select specific GPU type - uncomment as needed
    # eks.amazonaws.com/instance-gpu-name: l4
    # eks.amazonaws.com/instance-gpu-name: a100
    eks.amazonaws.com/instance-gpu-name: h200
    # eks.amazonaws.com/instance-gpu-name: b200
    eks.amazonaws.com/compute-type: auto
  restartPolicy: OnFailure
  containers:
  - name: nvidia-smi
    image: public.ecr.aws/amazonlinux/amazonlinux:2023-minimal
    args:
    - "nvidia-smi"
    resources:
      requests:
        # Uncomment if needed
        # memory: "30Gi"
        # cpu: "3500m"
        nvidia.com/gpu: 1
      limits:
        # Uncomment if needed
        # memory: "30Gi"
        nvidia.com/gpu: 1
  tolerations:
  - key: nvidia.com/gpu
    effect: NoSchedule
    operator: Exists

Para obter mais informações, consulte Pods na documentação do Kubernetes.

Recursos relacionados