Atualizar um grupo de nós autogerenciados existente - Amazon EKS

Ajudar a melhorar esta página

Quer contribuir para este guia do usuário? Role até o final desta página e selecione Editar esta página no GitHub. Suas contribuições ajudarão a tornar nosso guia do usuário melhor para todos.

Atualizar um grupo de nós autogerenciados existente

Este tópico descreve como atualizar uma pilha de nós autogerenciados do AWS CloudFormation 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 utilizar o Grupos de nós gerenciados, consulte Atualizar um grupo de nós gerenciados.

O modelo do AWS CloudFormation mais recente do nó padrão do Amazon EKS é configurado para executar uma instância com a nova AMI no cluster, antes de remover um antigo, um 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 para um novo grupo de nós.

Para atualizar um grupo de nós existente

  1. Determine o provedor DNS de seu cluster.

    kubectl get deployments -l k8s-app=kube-dns -n kube-system

    Veja um exemplo de saída abaixo. O cluster está usando 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

  2. 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 retornou isso.

    kubectl scale deployments/coredns --replicas=2 -n kube-system

  3. (Opcional) Se você estiver usando o Cluster Autoscaler 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

  4. Determine o tipo de instância e a contagem de instâncias desejada do grupo de nós atual. Você poderá inserir esses valores superiormente ao atualizar o modelo do AWS CloudFormation para o grupo.

    1. Abra o console do Amazon EC2 em https://console.aws.amazon.com/ec2/.

    2. 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.

    3. No painel de navegação à esquerda, escolha Auto Scaling Groups (Grupos do Auto Scaling) e observe a contagem de instâncias Desired (Desejadas) para o grupo do Auto Scaling do nó existente.

  5. Abra o console do AWS CloudFormation em https://console.aws.amazon.com/cloudformation.

  6. Selecione a pilha do grupo de nós e escolha Update (Atualizar).

  7. Selecione Replace current template (Substituir modelo atual) e selecione Amazon S3 URL (URL do Simple Storage Service (Amazon S3)).

  8. Em Amazon S3 URL (URL do Amazon S3), cole o URL a seguir na área de texto para garantir que você esteja usando a versão mais recente do modelo do AWS CloudFormation do nó. Depois, escolha Next (Próximo):

    https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2022-12-23/amazon-eks-nodegroup.yaml

  9. Na página Specify stack details (Especificar detalhes da pilha), preencha os parâmetros a seguir e escolha Next (Próximo):

    • NodeAutoScalingGroupDesiredCapacity: insira a contagem de instâncias desejada que você registrou em uma etapa anterior. 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. Se preferir, escolha um tipo de instância diferente para os nós. Antes de escolher um tipo de instância diferente, revise Escolha de um tipo de instância do Amazon EC2. 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. Por exemplo, os tipos de instância m5.large oferecem suporte a no máximo 30 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 Amazon VPC CNI plugin for Kubernetes estão listados em vpc_ip_resource_limit.go no GitHub. Talvez seja necessário atualizar a versão do Amazon VPC CNI plugin for Kubernetes para usar os tipos de instâncias compatíveis mais recentes. Para ter mais informações, consulte Trabalhando com o complemento Amazon VPC CNI plugin for Kubernetes do Amazon EKS.

      Importante

      Alguns tipos de instância podem não estar disponíveis em cada 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 1.30 do Kubernetes.

      /aws/service/eks/optimized-ami/1.30/amazon-linux-2/recommended/image_id

      É possível substituir 1.30 por uma versão compatível do Kubernetes 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 plano de controle. Você também pode substituir amazon-linux-2 por um tipo de AMI diferente. Para ter mais informações, consulte IDs da AMI da AMI do Amazon Linux otimizada para Amazon EKS.

      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 o Amazon EKS recomendada para a versão do Kubernetes especificada. 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 os nós ou Pods agendados no grupo de nós usem IMDSv1. Para obter mais informações, consulte Configuring the instance metadata service (Configurar o serviço de metadados de instância). Se 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. Desse modo, nenhum dos Pods do cluster requer acesso ao IMDS por outros motivos, como, por exemplo, para recuperar a Região da AWS atual. Em seguida, 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 da instância atribuído ao nó de processamento.

  10. (Opcional) Na página Options (Opções), marque os recursos da pilha. Escolha Próximo.

  11. 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.

  12. Se o provedor de DNS do cluster for kube-dns, reduza a implantação kube-dns para uma réplica.

    kubectl scale deployments/kube-dns --replicas=1 -n kube-system

  13. (Opcional) Se você estiver usando o Kubernetes Cluster Autoscaler, reduza a implantação para a quantidade de réplicas desejada.

    kubectl scale deployments/cluster-autoscaler --replicas=1 -n kube-system

  14. (Opcional) Verifique se você está usando a versão mais recente do Amazon VPC CNI plugin for Kubernetes. Talvez seja necessário atualizar a versão do Amazon VPC CNI plugin for Kubernetes para usar os tipos de instâncias compatíveis mais recentes. Para ter mais informações, consulte Trabalhando com o complemento Amazon VPC CNI plugin for Kubernetes do Amazon EKS.