**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.
# Criar nós autogerenciados com blocos de capacidade para ML
Os blocos de capacidade para machine learning (ML) permitem que você reserve instâncias com GPU para uma data futura, a fim de dar suporte a workloads de ML de curta duração. Para obter mais informações, consulte [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 para Instâncias Linux*.
## Considerações
**Importante**
Os blocos de capacidade estão disponíveis apenas para determinados tipos de instância do Amazon EC2 e para regiões da AWS. Para obter informações sobre compatibilidade, consulte [Trabalhar com pré-requisitos de blocos de capacidade](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/capacity-blocks-using.html#capacity-blocks-prerequisites) no *Guia do usuário do Amazon EC2 para instâncias Linux*.
Se você criar o grupo de nós autogerenciados antes de a reserva de capacidade se tornar ativa, defina a capacidade desejada como `0`.
Para permitir tempo suficiente para a drenagem adequada do(s) nó(s), sugerimos que você agende o dimensionamento para reduzir para zero mais de 30 minutos antes do horário de término da reserva do bloco de capacidade.
Para que os pods sejam drenados facilmente, recomendamos definir o AWS Node Termination Handler, conforme explicado nas próximas etapas.
## Usar blocos de capacidade com nós autogerenciados
Você pode usar blocos de capacidade com o Amazon EKS para provisionar e escalar seus nós autogerenciados. As etapas a seguir fornecem um exemplo geral de visão geral. Os exemplos de modelos do AWS CloudFormation não abrangem todos os aspectos necessários em uma workload de produção. Normalmente, você também vai querer um script de bootstrapping para unir o nó ao cluster, especificar a AMI acelerada do Amazon EKS e um perfil de instância apropriado para unir ao cluster. Para obter mais informações, consulte [Criar nós autogerenciados do Amazon Linux](launch-workers.md).
1. Crie um modelo de execução que seja aplicável à workload. Para obter mais informações, consulte [Usar blocos de capacidade para workloads de machine learning](https://docs.aws.amazon.com/autoscaling/ec2/userguide/launch-template-capacity-blocks.html) no *Guia do usuário do Amazon EC2 Auto Scaling*.
Certifique-se de que `LaunchTemplateData` inclua o seguinte:
+ `InstanceMarketOptions` com `MarketType` definido como `"capacity-block"`
+ `CapacityReservationSpecification: CapacityReservationTarget` com `CapacityReservationId` definido como bloco de capacidade (por exemplo:`cr-02168da1478b509e0 `)
+ `IamInstanceProfile` com o `Arn` definido como o *iam-instance-profile-arn* aplicável
+ `ImageId` definido como o *image-id* aplicável
+ `InstanceType` definido como um tipo de instância que oferece suporte a blocos de capacidade (por exemplo: *p5.48xlarge*)
+ `SecurityGroupIds` definido para as IDs aplicáveis (por exemplo: *sg-05b1d815d1EXAMPLE*)
+ `UserData` definido como os *dados de usuário* aplicáveis ao seu grupo de nós autogerenciado
Veja a seguir um trecho de um modelo do CloudFormation para criar um modelo de execução direcionado a um bloco de capacidade.
```
NodeLaunchTemplate:
Type: "aws::EC2::LaunchTemplate"
Properties:
LaunchTemplateData:
InstanceMarketOptions:
MarketType: "capacity-block"
CapacityReservationSpecification:
CapacityReservationTarget:
CapacityReservationId: "cr-02168da1478b509e0"
IamInstanceProfile:
Arn: iam-instance-profile-arn
ImageId: image-id
InstanceType: p5.48xlarge
KeyName: key-name
SecurityGroupIds:
- sg-05b1d815d1EXAMPLE
UserData: user-data
```
Você deve passar a sub-rede na zona de disponibilidade na qual a reserva é feita porque os blocos de capacidade são zonais.
1. Use o modelo de execução para criar um grupo de nós autogerenciados. Se você estiver criando o grupo de nós autogerenciados antes de a reserva de capacidade se tornar ativa, defina a capacidade desejada como `0`. Ao criar o grupo de nós, certifique-se de especificar apenas a sub-rede correspondente à Zona de Disponibilidade na qual a capacidade está reservada.
Veja abaixo um modelo do CloudFormation de exemplo que pode ser utilizado como referência ao criar um modelo que seja aplicável à sua workload. Esse exemplo obtém o `LaunchTemplateId` e a `Version` do recurso ` AWS::Amazon EC2::LaunchTemplate` mostrado no exemplo anterior. Ele também obtém os valores para`DesiredCapacity`, `MaxSize`, `MinSize` e `VPCZoneIdentifier` que são declarados em outro lugar no mesmo modelo.
```
NodeGroup:
Type: "AWS::AutoScaling::AutoScalingGroup"
Properties:
DesiredCapacity: !Ref NodeAutoScalingGroupDesiredCapacity
LaunchTemplate:
LaunchTemplateId: !Ref NodeLaunchTemplate
Version: !GetAtt NodeLaunchTemplate.LatestVersionNumber
MaxSize: !Ref NodeAutoScalingGroupMaxSize
MinSize: !Ref NodeAutoScalingGroupMinSize
VPCZoneIdentifier: !Ref Subnets
Tags:
- Key: Name
PropagateAtLaunch: true
Value: !Sub ${ClusterName}-${NodeGroupName}-Node
- Key: !Sub kubernetes.io/cluster/${ClusterName}
PropagateAtLaunch: true
Value: owned
```
1. Depois que o grupo de nós for criado com sucesso, certifique-se de registrar o `NodeInstanceRole` para o grupo de nós que foi criado. Você precisa disso para garantir que, quando o grupo de nós for escalado, os novos nós se associem ao cluster e o Kubernetes seja capaz de reconhecer os nós. Para obter mais informações, consulte as instruções do Console de gerenciamento da AWS em [Criar nós autogerenciados do Amazon Linux](launch-workers.md).
1. Recomendamos que você crie uma política de escalabilidade programada para o grupo do Auto Scaling que se alinhe aos horários de reserva do bloco de capacidade. Para obter mais informações, consulte [Escalabilidade agendada para o Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-scheduled-scaling.html) no *Manual do usuário do Amazon EC2 Auto Scaling*.
Você pode usar todas as instâncias reservadas até 30 minutos antes do horário final do bloco de capacidade. As instâncias que ainda estiverem em execução nesse momento começarão a ser encerradas. Para permitir tempo suficiente para a drenagem adequada do(s) nó(s), sugerimos que você agende o dimensionamento para reduzir para zero mais de 30 minutos antes do horário de término da reserva do bloco de capacidade.
Se, em vez disso, quiser aumentar a escala manualmente sempre que a reserva de capacidade chegar a `Active`, você precisará atualizar a capacidade desejada do grupo do Auto Scaling no horário de início da reserva do bloco de capacidade. Em seguida, você também precisaria reduzir a escala manualmente mais de 30 minutos antes do horário de término da reserva do bloco de capacidade.
1. O grupo de nós agora está pronto para que as workloads e os pods sejam agendados.
1. Para que os pods sejam drenados normalmente, recomendamos que você configure o AWS Node Termination Handler. Esse manipulador poderá observar os eventos do ciclo de vida "ASG Scale-in" do Amazon EC2 Auto Scaling usando o EventBridge e permitir que o ambiente de gerenciamento do Kubernetes execute as ações necessárias antes que a instância fique indisponível. Do contrário, seus objetos do Kubernetes e dos pods ficarão presos em um estado pendente. Para obter mais informações, consulte [Manipulador do término do nó da AWS](https://github.com/aws/aws-node-termination-handler) no GitHub.
Se você não configurar um Node Termination Handler, recomendamos que comece a drenar seus pods manualmente antes de chegar à janela de trinta minutos, para que haja tempo suficiente para a drenagem adequada.