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 oferece suporte a reservas de capacidade sob demanda (ODCRs, na sigla em inglês) do EC2 e a blocos de capacidade do EC2 para ML.

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.

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