**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.
# Migrar aplicações 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 Console de gerenciamento da AWS.
+ [`eksctl`](#eksctl_migrate_apps)
+ [Console de gerenciamento da AWS e AWS CLI](#console_migrate_apps)
## `eksctl`
**Migre suas aplicações para um novo grupo de nós com `eksctl` **
Para obter mais informações sobre o uso do eksctl para migração, consulte [Unmanaged nodegroups](https://eksctl.io/usage/nodegroup-unmanaged/) (Grupos de nós não gerenciados) na documentação do `eksctl`.
Este procedimento exige a versão `eksctl` `0.215.0` ou superior. É possível verificar a versão com o seguinte comando:
```
eksctl version
```
Para obter instruções sobre como instalar ou atualizar o `eksctl`, consulte [Instalação](https://eksctl.io/installation) 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 abaixo um exemplo de saída.
```
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
```
1. Inicie um novo grupo de nós com `eksctl` usando o comando a seguir. No comando, substitua cada *valor de exemplo* por seus próprios valores. O número da versão não pode ser superior à versão do Kubernetes do ambiente de gerenciamento. Além disso, 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.
Recomendamos bloquear o acesso dos pods ao IMDS se as seguintes condições a forem verdadeiras:
+ Você planeja atribuir perfis do IAM a todas as suas contas de serviço do Kubernetes para que os pods tenham apenas as permissões mínimas de que precisam.
+ Nenhum pod no cluster exige acesso ao serviço de metadados de instância (IMDS) do Amazon EC2 por outros motivos, como recuperação da região atual da AWS.
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).
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.35 \
--name standard-nodes-new \
--node-type t3.medium \
--nodes 3 \
--nodes-min 1 \
--nodes-max 4 \
--managed=false
```
1. Quando o comando anterior for concluído, verifique se todos os nós atingiram o estado `Ready` com o seguinte comando:
```
kubectl get nodes
```
1. Exclua cada grupo de nós original usando o comando a seguir. No comando, substitua cada *valor de exemplo* pelos nomes do seu cluster e grupo de nós:
```
eksctl delete nodegroup --cluster my-cluster --name standard-nodes-old
```
## Console de gerenciamento da AWS e AWS CLI
**Migre suas aplicações para um novo grupo de nós com a CLI Console de gerenciamento da AWS e AWS**
1. Inicie um novo grupo de nós seguindo as etapas descritas em [Criar nós autogerenciados do Amazon Linux](launch-workers.md).
1. Quando a criação da pilha for concluída, selecione-a no console e escolha **Outputs (Saídas)**.
1. 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 ao perfil do IAM do antigo grupo de nós, anexe essas mesmas políticas ao perfil 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 [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler) do Kubernetes, por exemplo.
1. Atualize os grupos de segurança para ambos os grupos de nós, para que eles possam se comunicar um com o outro. Para obter mais informações, consulte [Exibir os requisitos para grupos de segurança do Amazon EKS em clusters](sec-group-reqs.md).
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.
Você pode usar os seguintes comandos da CLI AWS para obter os IDs de grupo de segurança dos nomes de 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 *valor de exemplo* 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)
```
1. Adicione regras de entrada a cada grupo de segurança do nó para que eles aceitem o tráfego uns dos outros.
Os seguintes comandos da CLI AWS adicionam regras de entrada a cada grupo de segurança que permitem todo o tráfego em todos os protocolos do outro grupo de segurança. Essa configuração permite que os pods em cada grupo de nós se comuniquem entre si enquanto 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
```
1. Edite o configmap do `aws-auth` para mapear o novo perfil 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.
```
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 snippet *ARN do perfil da instância (não do perfil da instância)* pelo valor **NodeInstanceRole** que você registrou em uma [etapa anterior](#node-instance-role-step). Então, salve e feche o arquivo para aplicar o configmap atualizado.
1. 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
```
1. (Opcional) Se você estiver usando o [Cluster Autoscaler do Kubernetes](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler), 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. Use o comando a seguir para aplicar taint em cada um dos nós que deseja remover com `NoSchedule`. Isso serve para que novos pods não sejam agendados ou reagendados nos nós que você está substituindo. Para obter mais informações, consulte [Taints and Tolerations](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) 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.33`) com o trecho de código a seguir. O número da versão não pode ser superior à versão do Kubernetes do 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.33
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
```
1. Determine o provedor DNS do 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 o cluster pode retornar `kube-dns`.
```
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 `kubedns` se a saída do comando anterior tiver retornado isso.
```
kubectl scale deployments/coredns --replicas=2 -n kube-system
```
1. 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 uma determinada versão do Kubernetes (neste caso, *1.33*) com o trecho de código a seguir.
```
K8S_VERSION=1.33
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
```
1. Depois que os antigos nós forem esvaziados, revogue as regras de entrada do grupo de segurança que você autorizou anteriormente. Em seguida, exclua a pilha do AWS CloudFormation para encerrar as instâncias.
**nota**
Se você anexou alguma política IAM adicional à perfil IAM do grupo de nós antigo, como a adição de permissões para o [Kubernetes Cluster Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler), desanexe essas políticas adicionais do perfil 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 sua 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
```
1. Abra o console do [AWS CloudFormation](https://console.aws.amazon.com/cloudformation/).
1. Selecione a pilha antiga do nó.
1. Escolha **Excluir**.
1. Na caixa de diálogo de confirmação **Delete stack** (Excluir pilha), escolha **Delete stack** (Excluir pilha).
1. Edite o configmap do `aws-auth` para remover o antigo perfil da instância do nó do RBAC.
```
kubectl edit configmap -n kube-system aws-auth
```
Exclua a entrada `mapRoles` do antigo grupo nós.
```
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.
1. (Opcional) Se você estiver usando o [Autoscaler do cluster](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler) do Kubernetes, 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](https://github.com/kubernetes/autoscaler/tree/cluster-autoscaler-release-1.3/cluster-autoscaler/cloudprovider/aws).
```
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 a versão da CNI 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).
1. Se o seu cluster estiver usando o `kube-dns` para resolução de DNS (consulte [[migrate-determine-dns-step]](#migrate-determine-dns-step)), dimensione a implantação do `kube-dns` para uma réplica.
```
kubectl scale deployments/kube-dns --replicas=1 -n kube-system
```