**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](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/capacity-reservation-overview.html). 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). **dica** Por padrão, o Modo Automático do EKS pode iniciar em ODCRs abertos por meio da correspondência de aberturas, mas não lhes dá prioridade. As instâncias iniciadas por meio do open-matching são rotuladas como `karpenter.sh/capacity-type: on-demand`, e não `reserved`. Para priorizar o uso do ODCR e ter instâncias rotuladas como `karpenter.sh/capacity-type: reserved`, configure `capacityReservationSelectorTerms` na definição NodeClass. Os blocos de capacidade para ML sempre exigem `capacityReservationSelectorTerms` e não são usados automaticamente. ## 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. **Atenção** Se você configurar `capacityReservationSelectorTerms` em um NodeClass em um cluster, o Modo Automático do EKS não usará mais automaticamente ODCRs abertas para *nenhum* NodeClass no 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. | Rótulo | Exemplo | Descrição | | --- | --- | --- | | `eks.amazonaws.com/capacity-reservation-id` | `cr-56fac701cc1951b03` | O ID de reserva de capacidade | | `eks.amazonaws.com/capacity-reservation-type` | `default` ou `capacity-block` | O tipo de reserva de capacidade | | `eks.amazonaws.com/capacity-reservation-interruptible` | `true` ou `false` | Se a reserva de capacidade é sujeita a interrupção | 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](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/interruptible-capacity-reservations.html) 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](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-blocks.html) 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: 1. Uma NodeClass que faz referência à sua reserva de bloco de capacidade 1. Um NodePool que usa a NodeClass e aplica um taint 1. Uma especificação de pod com tolerância a taint e que solicita recursos de GPU ### 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](create-node-class.md). ### Exemplo de NodePool Este NodePool se refere a NodeClass da `gpu` e especifica configurações importantes: + Utiliza **apenas** a capacidade reservada, definindo `karpenter.sh/capacity-type: reserved` + Solicita famílias de instâncias de GPU específicas, apropriadas para workloads de ML + Aplica um taint `nvidia.com/gpu` para garantir que apenas workloads de GPU sejam agendadas nesses nós ``` 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](create-node-pool.md). ### Exemplo de pod Este exemplo de pod demonstra como configurar uma workload para ser executada nos nós do bloco de capacidade: + Usa um **nodeSelector** para direcionar tipos específicos de GPU (neste caso, GPUs H200) + Inclui uma **tolerância** para o taint `nvidia.com/gpu` aplicado pelo NodePool + **Solicita explicitamente recursos de GPU** usando o tipo de recurso `nvidia.com/gpu` ``` 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](https://kubernetes.io/docs/concepts/workloads/pods/) na documentação do Kubernetes. ### Recursos relacionados + [Blocos de capacidade para ML](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-blocks.html) no Guia do usuário do Amazon EC2 + [Encontrar e comprar blocos de capacidade](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/capacity-blocks-purchase.html) no Guia do usuário do Amazon EC2 + [Reservas de capacidade sujeitas a interrupção](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/interruptible-capacity-reservations.html) no Guia do usuário do Amazon EC2 + [Gerencie recursos computacionais para workloads de IA/ML no Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/ml-compute-management.html) + [Otimização de recursos de GPU e gerenciamento de custos](https://docs.aws.amazon.com/eks/latest/best-practices/aiml-compute.html#_gpu_resource_optimization_and_cost_management) no Guia de práticas recomendadas do EKS