Migrar para um novo grupo de nós

Este tópico descreve como criar um novo grupo de nós, migrar facilmente as aplicações existentes para o novo grupo e remover o grupo de nós antigo do cluster. Você pode migrar para um novo grupo de nós usando o eksctl ou o AWS Management Console.

eksctl

Para migrar as aplicações para um novo grupo de nós com o eksctl

Para obter mais informações sobre o uso do eksctl para migração, consulte Unmanaged nodegroups (Grupos de nós não gerenciados) na documentação do eksctl.

Este procedimento exige a versão eksctl 0.183.0 ou superior. Você pode verificar a versão com o seguinte comando:

eksctl version

Para obter instruções sobre como instalar ou atualizar o eksctl, consulte Instalação na documentação do eksctl.

nota

Este procedimento funciona apenas para clusters e grupos de nós que foram criados com o eksctl.

1. Recupere o nome dos grupos de nós existentes substituindo my-cluster pelo nome do cluster.

   eksctl get nodegroups --cluster=my-cluster
   

   Veja um exemplo de saída abaixo.

   CLUSTER      NODEGROUP          CREATED               MIN SIZE      MAX SIZE     DESIRED CAPACITY     INSTANCE TYPE     IMAGE ID
   default      standard-nodes   2019-05-01T22:26:58Z  1             4            3                    t3.medium         ami-05a71d034119ffc12

2. Inicie um novo grupo de nós com eksctl usando o comando a seguir. No comando, substitua cada example value por seus próprios valores. O número da versão não pode ser superior à versão do Kubernetes de seu ambiente de gerenciamento. Além disso, não pode ultrapassar duas versões secundárias anteriores à versão do Kubernetes de seu ambiente de gerenciamento. Recomendamos usar a mesma versão do ambiente de gerenciamento.

   Convém bloquear o acesso para Pod ao IMDS se as condições a seguir forem verdadeiras:

   • Você planeja atribuir perfis do IAM a todas as contas de serviço do Kubernetes para que os Pods tenham apenas as permissões mínimas de que precisam.

   • Nenhum dos Pods do cluster requer acesso ao serviço de metadados de instâncias do Amazon EC2 (IMDS) por outros motivos, como recuperar a Região da AWS atual.

   Para obter mais informações, consulte Restringir o acesso ao perfil da instância atribuído ao nó de processamento.

   Para bloquear o acesso do Pod ao IMDS, adicione a opção --disable-pod-imds ao comando a seguir.

   nota

   Para obter mais sinalizadores disponíveis e suas descrições, consulte https://eksctl.io/.

   eksctl create nodegroup \
     --cluster my-cluster \
     --version 1.30 \
     --name standard-nodes-new \
     --node-type t3.medium \
     --nodes 3 \
     --nodes-min 1 \
     --nodes-max 4 \
     --managed=false
   

3. Quando o comando anterior for concluído, verifique se todos os nós atingiram o estado Ready com o seguinte comando:

   kubectl get nodes
   

4. Exclua cada grupo de nós original usando o comando a seguir. No comando, substitua cada example value pelos nomes de grupos de nós e de cluster:

   eksctl delete nodegroup --cluster my-cluster --name standard-nodes-old
   

AWS Management Console and AWS CLI

Para migrar as aplicações para um novo grupo de nós com o AWS Management Console e a AWS CLI

1. Inicie um novo grupo de nós seguindo as etapas que estão descritas em Lançar nós autogerenciados do Amazon Linux.

2. Quando a criação da pilha for concluída, selecione-a no console e escolha Outputs (Saídas).

3. Registre o valor de NodeInstanceRole para o grupo de nós criado. Você precisará dele para adicionar os novos nós do Amazon EKS ao cluster.

   nota

   Se você anexou qualquer outra política do IAM à função do IAM do antigo grupo de nós, anexe essas mesmas políticas à função do IAM do novo grupo de nós para manter essa funcionalidade no novo grupo. Isso se aplica a você se você adicionou permissões para o Kubernetes Cluster Autoscaler, por exemplo.

4. Atualize os grupos de segurança para ambos os grupos de nós, para que eles possam se comunicar um com o outro. Para ter mais informações, consulte Considerações e requisitos sobre grupos de segurança do Amazon EKS.

   1. Registre os IDs do grupo de segurança de ambos os grupos de nós. Isso é mostrado como o valor NodeSecurityGroup nas saídas da pilha do AWS CloudFormation.

      É possível usar os seguintes comandos da AWS CLI para obter os IDs do grupo de segurança dos nomes da pilha. Nesses comandos, oldNodes é o nome da pilha do AWS CloudFormation para a pilha de nós mais antiga, e newNodes é o nome da pilha para a qual você está migrando. Substitua cada example value por seus próprios valores.

      oldNodes="old_node_CFN_stack_name"
      newNodes="new_node_CFN_stack_name"
      
      oldSecGroup=$(aws cloudformation describe-stack-resources --stack-name $oldNodes \
      --query 'StackResources[?ResourceType==`AWS::EC2::SecurityGroup`].PhysicalResourceId' \
      --output text)
      newSecGroup=$(aws cloudformation describe-stack-resources --stack-name $newNodes \
      --query 'StackResources[?ResourceType==`AWS::EC2::SecurityGroup`].PhysicalResourceId' \
      --output text)
      

   2. Adicione regras de entrada a cada grupo de segurança do nó para que eles aceitem o tráfego uns dos outros.

      Os comandos da AWS CLI a seguir adicionam regras de entrada a cada grupo de segurança que permite todo o tráfego em todos os protocolos do outro grupo de segurança. Isso permite que os Pods de cada grupo de nós se comuniquem entre si enquanto você estiver migrando a workload para o novo grupo.

      aws ec2 authorize-security-group-ingress --group-id $oldSecGroup \
      --source-group $newSecGroup --protocol -1
      aws ec2 authorize-security-group-ingress --group-id $newSecGroup \
      --source-group $oldSecGroup --protocol -1
      

5. Edite o configmap do aws-auth para mapear a nova função da instância do nó no RBAC.

   kubectl edit configmap -n kube-system aws-auth
   

   Adicione uma nova entrada mapRoles para o novo grupo do nós. Se o cluster estiver nas Regiões da AWS: AWS GovCloud (EUA-Leste) ou AWS GovCloud (EUA-Oeste), substitua arn:aws: por arn:aws-us-gov:.

   apiVersion: v1
   data:
     mapRoles: |
       - rolearn: ARN of instance role (not instance profile)
         username: system:node:{{EC2PrivateDNSName}}
         groups:
           - system:bootstrappers
           - system:nodes>
       - rolearn: arn:aws:iam::111122223333:role/nodes-1-16-NodeInstanceRole-U11V27W93CX5
         username: system:node:{{EC2PrivateDNSName}}
         groups:
           - system:bootstrappers
           - system:nodes

   Substitua o trecho ARN of instance role (not instance profile) pelo valor NodeInstanceRole que você registrou em uma etapa anterior. Então, salve e feche o arquivo para aplicar o configmap atualizado.

6. Observe o status dos nós e aguarde até que os novos nós ingressem no cluster e atinjam o status Ready.

   kubectl get nodes --watch
   

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

8. Use o comando a seguir para aplicar taint em cada um dos nós que deseja remover com NoSchedule. Isso garante que novos Pods não sejam agendados ou reagendados nos nós que você está substituindo. Para obter mais informações, consulte Taints e Tolerâncias na documentação do Kubernetes.

   kubectl taint nodes node_name key=value:NoSchedule
   

   Se você estiver atualizando os nós para uma nova versão do Kubernetes, será possível identificar e aplicar taints em todos os nós de determinada versão do Kubernetes (neste caso, 1.28) com o trecho de código a seguir. O número da versão não pode ser superior à versão do Kubernetes do seu ambiente de gerenciamento. Também não pode ultrapassar duas versões secundárias anteriores à versão do Kubernetes do ambiente de gerenciamento. Recomendamos usar a mesma versão do ambiente de gerenciamento.

   K8S_VERSION=1.28
   nodes=$(kubectl get nodes -o jsonpath="{.items[?(@.status.nodeInfo.kubeletVersion==\"v$K8S_VERSION\")].metadata.name}")
   for node in ${nodes[@]}
   do
       echo "Tainting $node"
       kubectl taint nodes $node key=value:NoSchedule
   done
   

9. Determine o provedor DNS do 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:

   NAME      DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
   coredns   1         1         1            1           31m

10. Se a implantação atual estiver executando menos de duas réplicas, expanda-a para duas réplicas. Substitua coredns por kubedns se a saída do comando anterior retornou isso.

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

11. Drene cada um dos nós que você deseja remover do cluster com o seguinte comando:

    kubectl drain node_name --ignore-daemonsets --delete-local-data
    

    Se você estiver atualizando os nós para uma nova versão do Kubernetes, identifique e drene todos os nós de determinada versão do Kubernetes (neste caso, 1.28) com o trecho de código a seguir.

    K8S_VERSION=1.28
    nodes=$(kubectl get nodes -o jsonpath="{.items[?(@.status.nodeInfo.kubeletVersion==\"v$K8S_VERSION\")].metadata.name}")
    for node in ${nodes[@]}
    do
        echo "Draining $node"
        kubectl drain $node --ignore-daemonsets --delete-local-data
    done
    

12. Depois que os antigos nós forem esvaziados, revogue as regras de entrada do grupo de segurança que você autorizou anteriormente. Então, exclua a pilha do AWS CloudFormation para terminar as instâncias.

    nota

    Se anexou qualquer política adicional do IAM ao perfil do IAM no antigo grupo de nós (como adicionar permissões para o Cluster Autoscaler do Kubernetes), desvincule essas políticas adicionais da função antes de excluir a pilha do AWS CloudFormation.

    1. Revogue as regras de entrada criadas anteriormente para os grupos de segurança do nó. Nesses comandos, oldNodes é o nome da pilha do AWS CloudFormation para a pilha de nós mais antiga, e newNodes é o nome da pilha para a qual você está migrando.

       oldNodes="old_node_CFN_stack_name"
       newNodes="new_node_CFN_stack_name"
       
       oldSecGroup=$(aws cloudformation describe-stack-resources --stack-name $oldNodes \
       --query 'StackResources[?ResourceType==`AWS::EC2::SecurityGroup`].PhysicalResourceId' \
       --output text)
       newSecGroup=$(aws cloudformation describe-stack-resources --stack-name $newNodes \
       --query 'StackResources[?ResourceType==`AWS::EC2::SecurityGroup`].PhysicalResourceId' \
       --output text)
       aws ec2 revoke-security-group-ingress --group-id $oldSecGroup \
       --source-group $newSecGroup --protocol -1
       aws ec2 revoke-security-group-ingress --group-id $newSecGroup \
       --source-group $oldSecGroup --protocol -1
       

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

    3. Selecione a pilha antiga do nó.

    4. Escolha Excluir.

    5. Na caixa de diálogo de confirmação Delete stack (Excluir pilha), escolha Delete stack (Excluir pilha).

13. Edite o configmap aws-auth para remover a antiga função da instância do nó do RBAC.

    kubectl edit configmap -n kube-system aws-auth
    

    Exclua a entrada mapRoles do antigo grupo nós. Se o cluster estiver nas Regiões da AWS: AWS GovCloud (EUA-Leste) ou AWS GovCloud (EUA-Oeste), substitua arn:aws: por arn:aws-us-gov:.

    apiVersion: v1
    data:
      mapRoles: |
        - rolearn: arn:aws:iam::111122223333:role/nodes-1-16-NodeInstanceRole-W70725MZQFF8
          username: system:node:{{EC2PrivateDNSName}}
          groups:
            - system:bootstrappers
            - system:nodes
        - rolearn: arn:aws:iam::111122223333:role/nodes-1-15-NodeInstanceRole-U11V27W93CX5
          username: system:node:{{EC2PrivateDNSName}}
          groups:
            - system:bootstrappers
            - system:nodes>

    Salve e feche o arquivo para aplicar o configmap atualizado.

14. (Opcional) Se você estiver usando o Kubernetes Cluster Autoscaler, reduza a implantação para uma réplica.

    nota

    Você também deve etiquetar o novo grupo do Auto Scaling corretamente (por exemplo, k8s.io/cluster-autoscaler/enabled,k8s.io/cluster-autoscaler/my-cluster) e atualizar o comando da implantação do Cluster Autoscaler de modo a apontar para o grupo do Auto Scaling recém-marcado. Para obter mais informações, consulte Autoscaler do cluster na AWS.

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

15. (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 da CNI 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.

16. Se o cluster estiver usando o kube-dns para resolução de DNS (consulte a etapa anterior), reduza a implantação de kube-dns para uma réplica.

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