Atualizar uma pilha de nós do AWS CloudFormation - Amazon EKS

Ajudar a melhorar esta página

Quer contribuir para este guia do usuário? Escolha o link Editar esta página no GitHub, disponível no painel direito de cada página. Suas contribuições ajudarão a tornar nosso guia do usuário melhor para todos.

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, consulte Atualizar um grupo de nós gerenciados para seu cluster.

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.

  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 tiver retornado 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. 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/.

    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.

  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. 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 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, consulte Escolha um tipo ideal de instância de nó 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 plugin Amazon VPC CNI para Kubernetes são mostrados 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 Atribuir IPs a Pods com a CNI da Amazon VPC.

      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 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 com o 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 ambiente de gerenciamento. Você também pode substituir o amazon-linux-2 por um tipo diferente de AMI. Para ter mais informações, consulte Recuperar IDs de AMI do Amazon Linux recomendadas.

      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 iniciará o AMI otimizado do Amazon EKS mais recente recomendado para a versão especificada 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 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). 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 Pods em seu cluster precisa acessar o IMDS por outros motivos, como recuperar a região 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 plugin CNI da Amazon VPC para 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 Atribuir IPs a Pods com a CNI da Amazon VPC.