**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. # Implantação de nós do modo automático do EKS em zonas locais O modo automático do EKS fornece gerenciamento simplificado de clusters com provisionamento automático de nós. As zonas locais da AWS ampliam a infraestrutura da AWS para locais geográficos mais próximos dos seus usuários finais, reduzindo a latência para aplicações sensíveis a esse atraso. Este guia orienta você no processo de implantação de nós do modo automático do EKS em zonas locais da AWS, permitindo a execução de aplicações conteinerizadas com menor latência para usuários em áreas geográficas específicas. Este guia também demonstra como usar taints e tolerâncias do Kubernetes para garantir que apenas workloads específicas sejam executadas em nós das zonas locais, ajudando você a controlar custos e otimizar o uso de recursos. ## Pré-requisitos Antes de começar a implantar nós do modo automático do EKS em zonas locais, certifique-se de que os seguintes pré-requisitos estejam configurados: + [Um cluster existente no modo automático do EKS](create-auto.md) + [Zonas locais ativadas em sua conta da AWS](https://docs.aws.amazon.com/local-zones/latest/ug/getting-started.html#getting-started-find-local-zone) ## Etapa 1: criação de uma sub-rede na zona local A primeira etapa para a implantação de nós do modo automático do EKS em uma zona local é criar uma sub-rede nessa zona local. Essa sub-rede fornece a infraestrutura de rede aos seus nós e permite que eles se comuniquem com o restante da VPC. Siga as instruções presentes em [Criação de uma sub-rede em uma zona local](https://docs.aws.amazon.com/local-zones/latest/ug/getting-started.html#getting-started-create-local-zone-subnet) (no Guia do usuário das zonas locais da AWS) para criar uma sub-rede na zona local escolhida. **dica** Anote o nome da sua sub-rede da zona local. ## Etapa 2: criação de uma NodeClass para a sub-rede na zona local Após criar a sub-rede da zona local, é necessário definir uma NodeClass que faça referência a essa sub-rede. A NodeClass é um recurso personalizado do Kubernetes que especifica os atributos de infraestrutura para os seus nós, incluindo quais sub-redes, grupos de segurança e configurações de armazenamento devem ser usados. No exemplo abaixo, criamos uma NodeClass chamada “local-zone” que direciona para uma sub-rede da zona local com base em seu nome. Você também pode usar o ID da sub-rede. Será necessário adaptar essa configuração para direcionar para a sua sub-rede da zona local. Para obter mais informações, consulte [Criar uma classe de nó para o Amazon EKS](create-node-class.md). ``` apiVersion: eks.amazonaws.com/v1 kind: NodeClass metadata: name: local-zone spec: subnetSelectorTerms: - id: ``` ## Etapa 3: criação do NodePool com NodeClass e Taint Com sua NodeClass configurada, agora você precisa criar um NodePool que utilize essa NodeClass. Um NodePool define as características de computação dos seus nós, incluindo os tipos de instância. O NodePool emprega a NodeClass como referência para determinar em qual local as instâncias devem ser iniciadas. No exemplo abaixo, criamos um NodePool que faz referência à NodeClass “local-zone”. Também adicionamos um taint aos nós para garantir que apenas pods com uma tolerância correspondente possam ser agendados nesses nós das zonas locais. Isso é particularmente importante para nós das zonas locais, que normalmente têm custos mais elevados e devem ser usados apenas por workloads que se beneficiam especificamente da latência reduzida. Para obter mais informações, consulte [Criar um grupo de nós para o Modo Automático do EKS](create-node-pool.md). ``` apiVersion: karpenter.sh/v1 kind: NodePool metadata: name: my-node-pool spec: template: metadata: labels: node-type: local-zone spec: nodeClassRef: group: eks.amazonaws.com kind: NodeClass name: local-zone taints: - key: "aws.amazon.com/local-zone" value: "true" effect: NoSchedule requirements: - key: "eks.amazonaws.com/instance-category" operator: In values: ["c", "m", "r"] - key: "eks.amazonaws.com/instance-cpu" operator: In values: ["4", "8", "16", "32"] ``` O taint com a chave `aws.amazon.com/local-zone` e o efeito `NoSchedule` garante que pods sem uma tolerância correspondente não sejam agendados nesses nós. Isso evita que workloads comuns sejam executadas acidentalmente na zona local, o que poderia gerar custos inesperados. ## Etapa 4: implantação de workloads com tolerância e afinidade de nó Para um controle ideal sobre a alocação de workloads em nós das zonas locais, use taints e tolerâncias e a afinidade de nó simultaneamente. Essa abordagem combinada oferece os seguintes benefícios: 1. **Controle de custos**: o taint garante que apenas pods com tolerâncias explícitas possam usar recursos das zonas locais, que podem ser mais caros. 1. **Posicionamento garantido**: a afinidade de nó garante que suas aplicações sensíveis à latência sejam executadas exclusivamente na zona local, e não em nós comuns do cluster. A seguir, apresentamos um exemplo de uma Deployment configurada para ser executada especificamente em nós das zonas locais: ``` apiVersion: apps/v1 kind: Deployment metadata: name: low-latency-app namespace: default spec: replicas: 2 selector: matchLabels: app: low-latency-app template: metadata: labels: app: low-latency-app spec: tolerations: - key: "aws.amazon.com/local-zone" operator: "Equal" value: "true" effect: "NoSchedule" affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: "node-type" operator: "In" values: ["local-zone"] containers: - name: application image: my-low-latency-app:latest resources: limits: cpu: "1" memory: "1Gi" requests: cpu: "500m" memory: "512Mi" ``` Esta Deployment conta com duas configurações de agendamento fundamentais: 1. A **tolerância** permite que os pods sejam agendados em nós que contam com o taint `aws.amazon.com/local-zone`. 1. O requisito de **afinidade de nó** garante que esses pods sejam executados apenas em nós com o rótulo `node-type: local-zone`. Juntas, essas configurações garantem que sua aplicação sensível à latência seja executada apenas em nós das zonas locais, e que as aplicações comuns não consumam os recursos dessas zonas locais, a menos que sejam explicitamente configuradas para isso. ## Etapa 5: verificação com o Console da AWS Após configurar a NodeClass, o NodePool e as Deployments, você deve verificar se os nós estão sendo provisionados na zona local conforme o esperado e se as workloads estão sendo executadas neles. É possível usar o Console de Gerenciamento da AWS para verificar se as instâncias do EC2 estão sendo iniciadas na sub-rede mais adequada da zona local. Além disso, você pode verificar a lista de nós do Kubernetes usando o comando `kubectl get nodes -o wide` para confirmar se os nós estão sendo integrados ao cluster com os rótulos e os taints configurados corretamente: ``` kubectl get nodes -o wide kubectl describe node | grep -A 5 Taints ``` Você também pode verificar se os pods das workloads estão agendados nos nós das zonas locais: ``` kubectl get pods -o wide ``` Essa abordagem garante que apenas workloads com tolerância específica para o taint da zona local sejam agendadas nesses nós, ajudando você a controlar custos e a fazer o uso mais eficiente dos seus recursos de zonas locais.