**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 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. **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. ## 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 + [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