**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. # Execução de workloads de amostra em clusters do modo automático do EKS Este capítulo fornece exemplos de como implantar diferentes tipos de workloads em clusters do Amazon EKS executados no Modo Automático. Os exemplos demonstram os principais padrões de workloads, incluindo aplicações de exemplo, aplicações Web com balanceamento de carga, workloads com estado usando armazenamento persistente e workloads com requisitos específicos de posicionamento de nós. Cada exemplo inclui manifestos completos e instruções de implantação passo a passo que você pode usar como modelos para suas próprias aplicações. Antes de prosseguir com os exemplos, certifique-se de que você tenha um cluster do EKS em execução no Modo Automático e que tenha instalado a AWS CLI e o kubectl. Para obter mais informações, consulte [Configurar para usar o Amazon EKS](setting-up.md). Os exemplos pressupõem familiaridade básica com os conceitos do Kubernetes e comandos do kubectl. Você pode usar essas amostras baseadas em casos de uso para executar workloads em clusters do Modo Automático do EKS. [Implantar uma workload de ampliação de exemplo em um cluster do Modo Automático do Amazon EKS](automode-workload.md) Mostra como implantar uma workload de exemplo em um cluster do Modo Automático do EKS usando comandos do `kubectl`. [Implantação de uma workload de amostra do balanceador de carga no modo automático do EKS](auto-elb-example.md) Mostra como implantar uma versão em contêiner do jogo 2048 no Amazon EKS. [Implantar uma workload com estado de exemplo no Modo Automático do EKS](sample-storage-workload.md) Mostra como implantar uma aplicação com estado de exemplo em um cluster do Modo Automático do EKS. [Implementar uma workload acelerada](auto-accelerated.md) Mostra como implantar workloads com aceleração de hardware em nós gerenciados pelo modo automático do EKS. [Controlar se uma workload é implantada nos nós do Modo Automático do EKS](associate-workload.md) Mostra como usar uma anotação para controlar se uma workload estiver implantada em nós gerenciados pelo Modo Automático do EKS. # Implantar uma workload de ampliação de exemplo em um cluster do Modo Automático do Amazon EKS Neste tutorial, você aprenderá como implantar uma workload de exemplo em um cluster do Modo Automático do EKS e observará como ela provisiona automaticamente os recursos computacionais necessários. Você usará os comandos do `kubectl` para observar o comportamento do cluster e acompanhar de perto como o Modo Automático simplifica as operações do Kubernetes na AWS. Ao final deste tutorial, você saberá como o Modo Automático do EKS responde às implantações de workloads gerenciando automaticamente os recursos computacionais subjacentes, sem exigir a configuração manual do grupo de nós. ## Pré-requisitos + Um cluster do Modo Automático do Amazon EKS. Registre o nome e a região da AWS do cluster. + Uma entidade principal do IAM, como um usuário ou perfil, com permissões suficientes para gerenciar recursos de rede, de computação e do EKS. + Para obter mais informações, consulte a [Criar perfis e anexar políticas](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions_create-policies.html) no Guia do usuário do IAM. + `aws` CLI instalada e configurada com uma identidade do IAM. + `kubectl` CLI instalada e conectada ao cluster. + Para obter mais informações, consulte [Configurar para usar o Amazon EKS](setting-up.md). ## Etapa 1: analisar os recursos computacionais existentes (opcional) Primeiro, use `kubectl` para listar os grupos de nós no cluster. ``` kubectl get nodepools ``` Exemplo de saída: ``` general-purpose ``` Neste tutorial, implantaremos uma workload configurada para usar o grupo de nós `general-purpose`. Esse grupo de nós é incorporado ao Modo Automático do EKS e inclui padrões razoáveis para workloads gerais, como microsserviços e aplicações Web. Você pode criar seu próprio grupo de nós. Para obter mais informações, consulte [Criar um grupo de nós para o Modo Automático do EKS](create-node-pool.md). Depois, use `kubectl` para listar os nós conectados ao cluster. ``` kubectl get nodes ``` Caso tenha acabado de criar um cluster do Modo Automático do EKS, você não terá nós. Neste tutorial, você implantará uma workload de exemplo. Se você não tiver nós ou se a workload não se adequar aos nós existentes, o Modo Automático do EKS provisionará um novo nó. ## Etapa 2: implantar uma aplicação de exemplo no cluster. Analise a implantação do Kubernetes a seguir e salve-a como `inflate.yaml` ``` apiVersion: apps/v1 kind: Deployment metadata: name: inflate spec: replicas: 1 selector: matchLabels: app: inflate template: metadata: labels: app: inflate spec: terminationGracePeriodSeconds: 0 nodeSelector: eks.amazonaws.com/compute-type: auto securityContext: runAsUser: 1000 runAsGroup: 3000 fsGroup: 2000 containers: - name: inflate image: public.ecr.aws/eks-distro/kubernetes/pause:3.7 resources: requests: cpu: 1 securityContext: allowPrivilegeEscalation: false ``` Observe que o seletor `eks.amazonaws.com/compute-type: auto` requer que a workload seja implantada em um nó do Modo Automático do Amazon EKS. Aplique a implantação ao cluster. ``` kubectl apply -f inflate.yaml ``` ## Etapa 3: observar os eventos do Kubernetes Use o comando a seguir para observar os eventos do Kubernetes, incluindo a criação de um nó. Use `ctrl+c` para parar de observar os eventos. ``` kubectl get events -w --sort-by '.lastTimestamp' ``` Use `kubectl` para listar novamente os nós conectados ao cluster. Registre o nó recém-criado. ``` kubectl get nodes ``` ## Etapa 4: visualizar nós e instâncias no console da AWS Você pode visualizar os nós do Modo Automático do EKS no console do EKS e as instâncias associadas do EC2 no console do EC2. As instâncias do EC2 implantadas pelo Modo Automático do EKS são restritas. Você não pode executar comandos arbitrários nos nós do Modo Automático do EKS. ## Etapa 5: excluir a implantação Use `kubectl` para excluir uma implantação de exemplo ``` kubectl delete -f inflate.yaml ``` Se você não tiver outras workloads implantadas no cluster, o nó criado pelo Modo Automático do EKS ficará vazio. Na configuração padrão, o Modo Automático do EKS detecta nós que ficaram vazios por trinta segundos e os encerra. Use `kubectl` ou o console do EC2 para confirmar que a instância associada foi excluída. # Implantação de uma workload de amostra do balanceador de carga no modo automático do EKS Este guia orienta você na implantação de uma versão em contêiner do jogo 2048 no Amazon EKS, completa com balanceamento de carga e acessibilidade à internet. ## Pré-requisitos + Um cluster do Modo Automático do EKS + `kubectl` configurado para interagir com o cluster + Permissões do IAM apropriadas para criar recursos do ALB ## Etapa 1: criar o namespace Primeiro, crie um namespace dedicado para a aplicação do jogo 2048. Crie um arquivo chamado `01-namespace.yaml`: ``` apiVersion: v1 kind: Namespace metadata: name: game-2048 ``` Aplique a configuração do namespace: ``` kubectl apply -f 01-namespace.yaml ``` ## Etapa 2: implantar uma aplicação A aplicação executa várias réplicas do contêiner do jogo 2048. Crie um arquivo chamado `02-deployment.yaml`: ``` apiVersion: apps/v1 kind: Deployment metadata: namespace: game-2048 name: deployment-2048 spec: selector: matchLabels: app.kubernetes.io/name: app-2048 replicas: 5 template: metadata: labels: app.kubernetes.io/name: app-2048 spec: containers: - image: public.ecr.aws/l6m2t8p7/docker-2048:latest imagePullPolicy: Always name: app-2048 ports: - containerPort: 80 resources: requests: cpu: "0.5" ``` **nota** Se você receber um erro ao carregar a imagem `public.ecr.aws/l6m2t8p7/docker-2048:latest`, verifique se o perfil do IAM do nó tem permissões suficientes para extrair imagens do ECR. Para obter mais informações, consulte [Perfil do IAM do nó](auto-learn-iam.md#auto-learn-node-iam-role). A imagem de `docker-2048` no exemplo também é uma imagem de `x86_64` e não será executada em outras arquiteturas. **Principais componentes:** + Implanta cinco réplicas da aplicação + Usa uma imagem pública do ECR + Solicita 0,5 núcleo de CPU por pod + Expõe a porta 80 para o tráfego HTTP Aplique a implantação: ``` kubectl apply -f 02-deployment.yaml ``` ## Etapa 3: criar o serviço O serviço expõe a implantação à rede do cluster. Crie um arquivo chamado `03-service.yaml`: ``` apiVersion: v1 kind: Service metadata: namespace: game-2048 name: service-2048 spec: ports: - port: 80 targetPort: 80 protocol: TCP selector: app.kubernetes.io/name: app-2048 ``` **Principais componentes:** + Cria um serviço do NodePort + Mapeia a porta 80 para a porta 80 do contêiner + Usa o seletor de rótulos para encontrar pods Aplique o serviço: ``` kubectl apply -f 03-service.yaml ``` ## Etapa 4: configurar o balanceamento de carga Você vai configurar uma entrada para expor a aplicação à internet. Primeiro, crie a `IngressClass`. Crie um arquivo chamado `04-ingressclass.yaml`: ``` apiVersion: networking.k8s.io/v1 kind: IngressClass metadata: labels: app.kubernetes.io/name: LoadBalancerController name: alb spec: controller: eks.amazonaws.com/alb ``` **nota** O Modo Automático do EKS precisa de tags de sub-rede para identificar sub-redes públicas e privadas. Se você criou o cluster com o `eksctl`, você já tem essas tags. Aprenda como [Marcar sub-redes para o Modo Automático do EKS](tag-subnets-auto.md). Em seguida, crie o recurso Ingress. Crie um arquivo chamado `05-ingress.yaml`: ``` apiVersion: networking.k8s.io/v1 kind: Ingress metadata: namespace: game-2048 name: ingress-2048 annotations: alb.ingress.kubernetes.io/scheme: internet-facing alb.ingress.kubernetes.io/target-type: ip spec: ingressClassName: alb rules: - http: paths: - path: / pathType: Prefix backend: service: name: service-2048 port: number: 80 ``` **Principais componentes:** + Cria um ALB voltado para a internet + Usa o tipo de destino IP para roteamento direto de pods + Roteia todo o tráfego (/) para o serviço do jogo Aplique as configurações de entrada: ``` kubectl apply -f 04-ingressclass.yaml kubectl apply -f 05-ingress.yaml ``` ## Etapa 5: verificar a implantação 1. Verifique se todos os pods estão em execução: ``` kubectl get pods -n game-2048 ``` 1. Verifique se o serviço foi criado: ``` kubectl get svc -n game-2048 ``` 1. Obtenha o endpoint do ALB: ``` kubectl get ingress -n game-2048 ``` O campo ADDRESS na saída da entrada mostrará o endpoint do ALB. Aguarde de dois a três minutos para que o ALB provisione e registre todos os destinos. ## Etapa 6: acessar o jogo Abra seu navegador da Web e navegue até o URL do endpoint do ALB da etapa anterior. Você deve ver a interface do jogo 2048. ## Etapa 7: limpeza Para remover todos os recursos criados neste tutorial: ``` kubectl delete namespace game-2048 ``` Isso excluirá todos os recursos no namespace, incluindo os recursos de implantação, serviço e entrada. ## O que está acontece por detrás 1. A implantação cria cinco pods que executam o jogo 2048 1. O serviço fornece acesso de rede estável a esses pods 1. Modo Automático do EKS: + Cria um Application Load Balancer na AWS + Configura grupos de destino para os pods + Configura as regras de roteamento para direcionar o tráfego ao serviço ## Solução de problemas Se o jogo não carregar: + Certifique-se de que todos os pods estejam em execução: `kubectl get pods -n game-2048` + Verifique o status de entrada: `kubectl describe ingress -n game-2048` + Confira as verificações de integridade do ALB: consulte a integridade do grupo de destino no Console da AWS # Implantar uma workload com estado de exemplo no Modo Automático do EKS Este tutorial o orientará na implantação de uma aplicação com estado de exemplo no cluster do Modo Automático do EKS. A aplicação grava carimbos de data e hora em um volume persistente, demonstrando os recursos automáticos de provisionamento e persistência de volume do EBS do Modo Automático do EKS. ## Pré-requisitos + Um cluster do Modo Automático do EKS + A AWS CLI configurada com as permissões apropriadas + `kubectl` instalado e configurado + Para ter mais informações, consulte [Configurar para usar o Amazon EKS](setting-up.md). ## Etapa 1: configurar o ambiente 1. Defina as variáveis de ambiente: ``` export CLUSTER_NAME=my-auto-cluster export AWS_REGION="us-west-2" ``` 1. Atualize o kubeconfig: ``` aws eks update-kubeconfig --name "${CLUSTER_NAME}" ``` ## Etapa 2: criar a classe de armazenamento A `StorageClass` define como o Modo Automático do EKS provisionará volumes do EBS. O Modo Automático do EKS não cria uma `StorageClass` para você. Você deve criar uma `StorageClass` referenciando `ebs.csi.eks.amazonaws.com` para usar o recurso de armazenamento do Modo Automático do EKS. 1. Crie um arquivo chamado `storage-class.yaml`: ``` apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: auto-ebs-sc annotations: storageclass.kubernetes.io/is-default-class: "true" provisioner: ebs.csi.eks.amazonaws.com volumeBindingMode: WaitForFirstConsumer parameters: type: gp3 encrypted: "true" ``` 1. Aplique a `StorageClass`: ``` kubectl apply -f storage-class.yaml ``` **Principais componentes:** + `provisioner: ebs.csi.eks.amazonaws.com`: usa o Modo Automático do EKS + `volumeBindingMode: WaitForFirstConsumer`: atrasa a criação do volume até que um pod precise dele + `type: gp3`: especifica o tipo de volume do EBS + `encrypted: "true"`: o EBS usará a chave `aws/ebs` padrão para criptografar volumes criados com essa classe. Isso é opcional, mas recomendado. + `storageclass.kubernetes.io/is-default-class: "true"`: o Kubernetes usará essa classe de armazenamento por padrão, a menos que você especifique uma classe de volume diferente em uma reivindicação de volume persistente. Tenha cuidado ao definir esse valor se estiver migrando de outro controlador de armazenamento. (opcional) ## Etapa 3: criar a declaração de volume persistente A PVC solicita armazenamento da `StorageClass`. 1. Crie um arquivo chamado `pvc.yaml`: ``` apiVersion: v1 kind: PersistentVolumeClaim metadata: name: auto-ebs-claim spec: accessModes: - ReadWriteOnce storageClassName: auto-ebs-sc resources: requests: storage: 8Gi ``` 1. Aplique a PVC: ``` kubectl apply -f pvc.yaml ``` **Principais componentes:** + `accessModes: ReadWriteOnce`: o volume pode ser montado por um nó por vez + `storage: 8Gi`: solicita um volume de 8 GiB + `storageClassName: auto-ebs-sc`: faz referência à `StorageClass` que criamos ## Etapa 4: implantar uma aplicação A implantação executa um contêiner que grava carimbos de data e hora no volume persistente. 1. Crie um arquivo chamado `deployment.yaml`: ``` apiVersion: apps/v1 kind: Deployment metadata: name: inflate-stateful spec: replicas: 1 selector: matchLabels: app: inflate-stateful template: metadata: labels: app: inflate-stateful spec: terminationGracePeriodSeconds: 0 nodeSelector: eks.amazonaws.com/compute-type: auto containers: - name: bash image: public.ecr.aws/docker/library/bash:4.4 command: ["/usr/local/bin/bash"] args: ["-c", "while true; do echo $(date -u) >> /data/out.txt; sleep 60; done"] resources: requests: cpu: "1" volumeMounts: - name: persistent-storage mountPath: /data volumes: - name: persistent-storage persistentVolumeClaim: claimName: auto-ebs-claim ``` 1. Aplique a implantação: ``` kubectl apply -f deployment.yaml ``` **Principais componentes:** + Contêiner bash simples que grava carimbos de data e hora em um arquivo + Monta o PVC em `/data` + Solicita um núcleo de CPU + Usa o seletor de nós para nós gerenciados pelo EKS ## Etapa 5: verificar a configuração 1. Verifique se o pod está em execução: ``` kubectl get pods -l app=inflate-stateful ``` 1. Verifique se a PVC está vinculada: ``` kubectl get pvc auto-ebs-claim ``` 1. Verifique o volume do EBS: ``` # Get the PV name PV_NAME=$(kubectl get pvc auto-ebs-claim -o jsonpath='{.spec.volumeName}') # Describe the EBS volume aws ec2 describe-volumes \ --filters Name=tag:CSIVolumeName,Values=${PV_NAME} ``` 1. Verifique se os dados estão sendo gravados: ``` kubectl exec "$(kubectl get pods -l app=inflate-stateful \ -o=jsonpath='{.items[0].metadata.name}')" -- \ cat /data/out.txt ``` ## Etapa 6: limpeza Execute o comando a seguir para remover todos os recursos criados neste tutorial: ``` # Delete all resources in one command kubectl delete deployment/inflate-stateful pvc/auto-ebs-claim storageclass/auto-ebs-sc ``` ## O que está acontece por detrás 1. A PVC solicita armazenamento da `StorageClass` 1. Quando o pod está programado: 1. O Modo Automático do EKS provisiona um volume do EBS 1. Cria um PersistentVolume 1. Anexa o volume ao nó 1. O pod monta o volume e começa a gravar carimbos de data e hora ## Controlador de snapshots O Modo Automático do EKS é compatível com o Kubernetes CSI Snapshotter, também conhecido como controlador de snapshots. No entanto, o Modo Automático do EKS não inclui o controlador de snapshots. Você é responsável por instalar e configurar o controlador de snapshots. Para ter mais informações, consulte [Habilitar a funcionalidade de snapshot para volumes CSI](csi-snapshot-controller.md). Analise a `VolumeSnapshotClass` a seguir que faz referência à capacidade de armazenamento do Modo Automático do EKS. ``` apiVersion: snapshot.storage.k8s.io/v1 kind: VolumeSnapshotClass metadata: name: auto-ebs-vsclass driver: ebs.csi.eks.amazonaws.com deletionPolicy: Delete ``` [Saiba mais sobre o Kubernetes CSI Snapshotter.](https://github.com/kubernetes-csi/external-snapshotter/blob/master/README.md#usage) # Implementar uma workload acelerada Este tutorial demonstra como o modo automático do Amazon EKS simplifica a inicialização de workloads com a aceleração de hardware. O Modo Automático do Amazon EKS simplifica as operações além do próprio cluster, automatizando os principais componentes da infraestrutura e fornecendo recursos de computação, rede, balanceamento de carga, armazenamento e do Identity and Access Management prontos para uso. O Modo Automático do Amazon EKS inclui os drivers e plug-ins de dispositivos necessários para determinados tipos de instância, como drivers NVIDIA e AWS Neuron. Você não precisa instalar ou atualizar esses componentes. O Modo Automático do EKS gerencia automaticamente os drivers destes aceleradores: + [AWS Trainium](https://aws.amazon.com/ai/machine-learning/trainium/) + [AWS Inferentia](https://aws.amazon.com/ai/machine-learning/inferentia/) + [GPUs NVIDIA em instâncias aceleradas do Amazon EC2](https://docs.aws.amazon.com/ec2/latest/instancetypes/ac.html) **nota** O Modo Automático do EKS inclui o plug-in de dispositivo NVIDIA para o Kubernetes. Esse plug-in é executado automaticamente e não fica visível como um conjunto de daemons no cluster. Suporte adicional de rede: + [Elastic Fabric Adapter (EFA)](https://aws.amazon.com/hpc/efa/) O Modo Automático do Amazon EKS elimina o trabalho de gerenciamento de drivers de aceleradores e plug-ins de dispositivos. Você também pode aproveitar uma redução de custos escalando o cluster para zero. Você pode configurar o Modo Automático do EKS para encerrar instâncias quando nenhuma workload estiver em execução. Essa configuração é útil para workloads de inferência baseadas em lotes. Veja a seguir um exemplo de como executar workloads aceleradas com o Modo Automático do Amazon EKS. ## Pré-requisitos + Um cluster do Kubernetes com o Modo Automático do Amazon EKS configurado. + Uma classe de nó `default` do EKS conforme criada quando os grupos de nós gerenciados `general-purpose` ou `system` estão habilitados. ## Etapa 1: implantar uma workload de GPU Neste exemplo, você criará um NodePool para workloads baseadas em NVIDIA que requer 45 GB de memória de GPU. Com o Modo Automático do EKS, você usa as restrições de agendamento do Kubernetes para definir os requisitos de sua instância. Para implantar o `NodePool` do Modo Automático do Amazon EKS e o exemplo de `workload`, consulte a seguinte definição de NodePool e pod e salve como `nodepool-gpu.yaml` e `pod.yaml`: **nodepool-gpu.yaml** ``` apiVersion: karpenter.sh/v1 kind: NodePool metadata: name: gpu spec: disruption: budgets: - nodes: 10% consolidateAfter: 1h consolidationPolicy: WhenEmpty template: metadata: {} spec: nodeClassRef: group: eks.amazonaws.com kind: NodeClass name: default requirements: - key: "karpenter.sh/capacity-type" operator: In values: ["on-demand"] - key: "kubernetes.io/arch" operator: In values: ["amd64"] - key: "eks.amazonaws.com/instance-family" operator: In values: - g6e - g6 taints: - key: nvidia.com/gpu effect: NoSchedule terminationGracePeriod: 24h0m0s ``` **pod.yaml** ``` apiVersion: v1 kind: Pod metadata: name: nvidia-smi spec: nodeSelector: 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: memory: "30Gi" cpu: "3500m" nvidia.com/gpu: 1 limits: memory: "30Gi" nvidia.com/gpu: 1 tolerations: - key: nvidia.com/gpu effect: NoSchedule operator: Exists ``` Observe que o seletor `eks.amazonaws.com/compute-type: auto` requer que a workload seja implantada em um nó do Modo Automático do Amazon EKS. O NodePool também define uma taint que só permite que pods com tolerâncias para GPUs Nvidia sejam programados. Aplique o NodePool e a workload ao cluster. ``` kubectl apply -f nodepool-gpu.yaml kubectl apply -f pod.yaml ``` A seguinte saída deverá ser mostrada: ``` nodepool.karpenter.sh/gpu configured created pod/nvidia-smi created ``` Aguarde alguns segundos e verifique os nós no cluster. Agora você deve ver um novo nó provisionado no cluster do Modo Automático do Amazon EKS: ``` > kubectl get nodes NAME TYPE CAPACITY ZONE NODE READY AGE gpu-dnknr g6e.2xlarge on-demand us-west-2b i-02315c7d7643cdee6 True 76s ``` ## Etapa 2: validar Você pode ver que o Modo Automático do Amazon EKS executou `g6e.2xlarge` em vez de `g6.2xlarge`, pois a workload exigia uma instância com `GPU` l40s, de acordo com as seguintes restrições de programação do Kubernetes: ``` ... nodeSelector: eks.amazonaws.com/instance-gpu-name: l40s ... requests: memory: "30Gi" cpu: "3500m" nvidia.com/gpu: 1 limits: memory: "30Gi" nvidia.com/gpu: 1 ``` Agora, veja os logs dos contêineres executando o seguinte comando: ``` kubectl logs nvidia-smi ``` Exemplo de resultado: ``` +---------------------------------------------------------------------------------------+ | NVIDIA-SMI 535.230.02 Driver Version: 535.230.02 CUDA Version: 12.2 | |-----------------------------------------+----------------------+----------------------+ | GPU Name Persistence-M | Bus-Id Disp.A | Volatile Uncorr. ECC | | Fan Temp Perf Pwr:Usage/Cap | Memory-Usage | GPU-Util Compute M. | | | | MIG M. | |=========================================+======================+======================| | 0 NVIDIA L40S On | 00000000:30:00.0 Off | 0 | | N/A 27C P8 23W / 350W | 0MiB / 46068MiB | 0% Default | | | | N/A | +-----------------------------------------+----------------------+----------------------+ +---------------------------------------------------------------------------------------+ | Processes: | | GPU GI CI PID Type Process name GPU Memory | | ID ID Usage | |=======================================================================================| | No running processes found | +---------------------------------------------------------------------------------------+ ``` Você pode ver que o contêiner detectou que está sendo executado em uma instância com uma GPU `NVIDIA` e que você não precisou instalar nenhum driver de dispositivo, pois é gerenciado pelo Modo Automático do Amazon EKS. ## Etapa 3: limpar Para remover todos os objetos criados, use o `kubectl` para excluir a implantação da amostra e o NodePool para que o nó seja encerrado: ``` kubectl delete -f nodepool-gpu.yaml kubectl delete -f pod.yaml ``` ## Exemplo de referência de NodePools ### Criar um NodePool NVIDIA O seguinte NodePool define: + Executa somente instâncias da família `g6e` e `g6` + Consolida os nós quando estiverem vazios por uma hora + O valor de 1 hora para `consolodateAfter` é compatível com workloads elevadas e reduz a rotatividade de nós. Você pode ajustar `consolidateAfter` com base em seus requisitos de workload. **Exemplo de NodePool com consolidação e família de instâncias de GPU** ``` apiVersion: karpenter.sh/v1 kind: NodePool metadata: name: gpu spec: disruption: budgets: - nodes: 10% consolidateAfter: 1h consolidationPolicy: WhenEmpty template: metadata: {} spec: nodeClassRef: group: eks.amazonaws.com kind: NodeClass name: default requirements: - key: "karpenter.sh/capacity-type" operator: In values: ["on-demand"] - key: "kubernetes.io/arch" operator: In values: ["amd64"] - key: "eks.amazonaws.com/instance-family" operator: In values: - g6e - g6 terminationGracePeriod: 24h0m0s ``` Em vez de definir `eks.amazonaws.com/instance-gpu-name`, você pode usar `eks.amazonaws.com/instance-family` para especificar a família de instâncias. Para outros rótulos conhecidos que influenciam a revisão da programação, consulte [Rótulos compatíveis com o Modo Automático do EKS](create-node-pool.md#auto-supported-labels). Se você tiver requisitos específicos de armazenamento, poderá ajustar `iops`, `size` e `throughput` do armazenamento temporário de nós criando o próprio [NodeClass](create-node-class.md) para referência no NodePool. Saiba mais sobre as [opções configuráveis do NodeClass](create-node-class.md). **Exemplo de configuração de armazenamento para NodeClass** ``` apiVersion: eks.amazonaws.com/v1 kind: NodeClass metadata: name: gpu spec: ephemeralStorage: iops: 3000 size: 80Gi throughput: 125 ``` ### Definir um AWS Trainium e AWS Inferentia NodePool O NodePool abaixo tem uma configuração de `eks.amazonaws.com/instance-category` que instrui a executar apenas instâncias da família Inferentia e Trainium: ``` - key: "eks.amazonaws.com/instance-category" operator: In values: - inf - trn ```