**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. # Atualizar uma pilha de nós do AWS CloudFormation Este tópico descreve como você pode atualizar uma pilha de nós autogerenciados do AWS CloudFormation existente com uma nova AMI. Você pode usar esse procedimento para atualizar os nós para uma nova versão do Kubernetes após uma atualização do cluster. Senão, é possível atualizar para a AMI otimizada do Amazon EKS mais recente para uma versão existente do Kubernetes. **Importante** Este tópico aborda as atualizações do nó para nós autogerenciados. Para obter informações sobre como usar [Simplificar o ciclo de vida dos nós com grupos de nós gerenciados](managed-node-groups.md), consulte [Atualizar um grupo de nós gerenciados para seu cluster](update-managed-node-group.md). O modelo padrão mais recente do Amazon EKS node AWS CloudFormation está configurado para iniciar uma instância com a nova AMI em seu cluster antes de remover uma antiga, uma de cada vez. Essa configuração garante que você esteja com a contagem desejada do grupo do Auto Scaling de instâncias ativas no cluster durante a implantação da atualização. **nota** Esse método não é compatível com grupos de nós que foram criados com o `eksctl`. Se você criou o cluster ou o grupo de nós com o `eksctl`, consulte [Migrar aplicações para um novo grupo de nós](migrate-stack.md). 1. Determine o provedor DNS de seu cluster. ``` kubectl get deployments -l k8s-app=kube-dns -n kube-system ``` Veja abaixo um exemplo de saída. O cluster está usando o CoreDNS para a resolução de DNS, mas, em vez disso, o cluster pode retornar `kube-dns`. Sua saída pode parecer diferente dependendo da versão do `kubectl` que você está usando. ``` NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE coredns 1 1 1 1 31m ``` 1. Se a implantação atual estiver executando menos de duas réplicas, expanda-a para duas réplicas. Substitua *coredns* por `kube-dns` se a saída do comando anterior tiver retornado isso. ``` kubectl scale deployments/coredns --replicas=2 -n kube-system ``` 1. (Opcional) Se você estiver usando o [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md) do Kubernetes, reduza a implantação para zero (0) réplica para evitar ações de escalabilidade conflitantes. ``` kubectl scale deployments/cluster-autoscaler --replicas=0 -n kube-system ``` 1. Determine o tipo de instância e a contagem de instâncias desejada do grupo de nós atual. Esses valores são inseridos posteriormente quando você atualiza o modelo do AWS CloudFormation para o grupo. 1. Abra o console do Amazon EC2 em https://console.aws.amazon.com/ec2/. 1. No painel de navegação à esquerda, escolha **Launch Configurations** (Configurações de execução) e anote o tipo de instância da configuração de execução do nó existente. 1. No painel de navegação à esquerda, escolha **Grupos do Auto Scaling** e observe a contagem de instâncias **Desejadas** para o grupo do Auto Scaling do nó existente. 1. Abra o console do [AWS CloudFormation](https://console.aws.amazon.com/cloudformation/). 1. Selecione a pilha do grupo de nós e escolha **Atualizar**. 1. Selecione **Substituir modelo atual** e selecione **URL do Amazon S3**. 1. Para o **URL do Amazon S3**, cole o seguinte URL na área de texto para garantir que você esteja usando a versão mais recente do modelo do node AWS CloudFormation. Depois, escolha **Próximo**: ``` https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2022-12-23/amazon-eks-nodegroup.yaml ``` 1. Na página **Especificar detalhes da pilha**, preencha os parâmetros a seguir e escolha **Próximo**: + **NodeAutoScalingGroupDesiredCapacity**: insira a contagem de instâncias desejada que você registrou em uma [etapa anterior](#existing-worker-settings-step). Ou insira o novo número desejado de nós para o qual escalar quando a pilha for criada. + **NodeAutoScalingGroupMaxSize**: digite o número máximo de nós para o qual o grupo Auto Scaling de nós pode ser aumentado. Esse valor deve ser pelo menos um nó a mais do que a capacidade desejada. Assim, você pode realizar uma atualização contínua dos nós sem reduzir a contagem de nós durante a atualização. + **NodeInstanceType**: escolha o tipo de instância registrada em uma [etapa anterior](#existing-worker-settings-step). Se preferir, escolha um tipo de instância diferente para os nós. Antes de escolher um tipo de instância diferente, consulte [Escolha um tipo ideal de instância de nó do Amazon EC2](choosing-instance-type.md). Cada tipo de instância do Amazon EC2 suporta um número máximo de interfaces elásticas de rede (interfaces de rede) e cada interface de rede oferece suporte a um número máximo de endereços IP. Como cada nó de processamento e pod recebe seu próprio endereço IP, é importante escolher um tipo de instância que ofereça suporte ao número máximo de pods que você deseja executar em cada nó do Amazon EC2. Para obter uma lista do número de interfaces de rede e endereços IP compatíveis com tipos de instância, consulte [Endereços IP por interface de rede por tipo de instância](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#AvailableIpPerENI). Por exemplo, o tipo de instância `m5.large` é compatível com um máximo de trinta endereços IP para o nó de processamento e pods. **nota** Os tipos de instâncias compatíveis com a versão mais recente do [plugin CNI da Amazon VPC para Kubernetes](https://github.com/aws/amazon-vpc-cni-k8s) estão exibidos em [vpc\$1ip\$1resource\$1limit.go](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/pkg/vpc/vpc_ip_resource_limit.go) no GitHub. Talvez seja necessário atualizar o plug-in CNI da Amazon VPC para Kubernetes para usar os tipos de instâncias compatíveis mais recentes. Para obter mais informações, consulte [Atribuir IPs a pods com a CNI da Amazon VPC](managing-vpc-cni.md). **Importante** Alguns tipos de instância podem não estar disponíveis em todas as regiões da AWS. + **NodeImageIdSSMParam**: o parâmetro do Amazon EC2 Systems Manager do ID da AMI para o qual você deseja atualizar. O valor a seguir usa a AMI otimizada para o Amazon EKS mais recente para a versão do Kubernetes `1.35`. ``` /aws/service/eks/optimized-ami/1.35/amazon-linux-2/recommended/image_id ``` É possível substituir *1.35* por uma [versão da plataforma](https://docs.aws.amazon.com/eks/latest/userguide/platform-versions.html) que seja a mesma. Ou deve ser até uma versão anterior à versão do Kubernetes em execução no ambiente de gerenciamento. Recomendamos que você mantenha seus nós na mesma versão do ambiente de gerenciamento. Você também pode substituir *o amazon-linux-2* por um tipo diferente de AMI. Para obter mais informações, consulte [Recuperar IDs de AMI do Amazon Linux recomendadas](retrieve-ami-id.md). **nota** O uso do parâmetro do Amazon EC2 Systems Manager permite atualizar os nós no futuro sem precisar pesquisar e especificar um ID de AMI. Se a pilha do AWS CloudFormation estiver usando esse valor, qualquer atualização da pilha sempre executará a AMI otimizada para Amazon EKS recomendada para a versão específica do Kubernetes. Isso se aplica mesmo que você não altere nenhum valor no template. + **NodeImageId**: para usar sua própria AMI personalizada, insira o ID da AMI a ser usada. **Importante** Esse valor substitui qualquer valor especificado para **NodeImageIdSSMParam**. Se você quiser usar o valor de **NodeImageIdSSMParam**, verifique se o valor de **NodeImageId** está em branco. + **DisableIMDSv1**: por padrão, cada nó oferece suporte ao serviço de metadados de instância versão 1 (IMDSv1) e IMDSv2. No entanto, você pode desabilitar o IMDSv1. Selecione **true** se você não quiser que nós ou pods agendados no grupo de nós usem IMDSv1. Para obter mais informações, consulte [Configurar o serviço de metadados da instância](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html). Você implementou perfis do IAM para contas de serviço e atribuiu as permissões necessárias diretamente a todos os pods que exigem acesso aos serviços da AWS. Dessa forma, nenhum pod no cluster precisa acessar o IMDS por outros motivos, como recuperar a região atual da AWS. Então, você também pode desabilitar o acesso ao IMDSv2 para pods que não usam redes de host. Para obter mais informações, consulte [Restringir o acesso ao perfil de instância atribuído ao nó de processamento](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node). 1. (Opcional) Na página **Opções**, marque os recursos da sua pilha. Escolha **Próximo**. 1. Na página **Review** (Revisão), analise suas informações, confirme se a pilha pode criar recursos do IAM e selecione **Update stack** (Atualizar pilha). **nota** A atualização de cada nó no cluster leva vários minutos. Aguarde até que a atualização de todos os nós seja concluída antes de executar as próximas etapas. 1. Se o seu provedor de DNS do cluster for `kube-dns`, reduza a escala horizontalmente da implantação de `kube-dns` para uma réplica. ``` kubectl scale deployments/kube-dns --replicas=1 -n kube-system ``` 1. (Opcional) Se você estiver usando o [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md) do Kubernetes, reduza a implantação para a quantidade de réplicas desejada. ``` kubectl scale deployments/cluster-autoscaler --replicas=1 -n kube-system ``` 1. (Opcional) Verifique se você está usando a versão mais recente do [plugin CNI da Amazon VPC para Kubernetes](https://github.com/aws/amazon-vpc-cni-k8s). Talvez seja necessário atualizar o plug-in CNI da Amazon VPC para Kubernetes para usar os tipos de instâncias compatíveis mais recentes. Para obter mais informações, consulte [Atribuir IPs a pods com a CNI da Amazon VPC](managing-vpc-cni.md).