Migrar aplicações para um novo grupo de nós

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

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 Kubernetes do seu ambiente de gerenciamento. Além disso, não pode ultrapassar duas versões secundárias anteriores à versão Kubernetes do 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:

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

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

kubectl get nodes

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

Inicie um novo grupo de nós seguindo as etapas descritas em Criar nós autogerenciados do Amazon Linux.

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

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.

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 Exibir os requisitos para grupos de segurança do Amazon EKS em clusters.

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.

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. Então, salve e feche o arquivo para aplicar o configmap atualizado.

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

(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

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

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

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

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 estiver atualizando os nós para uma nova versão do Kubernetes, identifique e drene todos os nós de uma versão específica do Kubernetes (neste caso, 1.28) com o seguinte trecho de código.

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

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.

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.

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.

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

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

(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 Atribuir IPs a Pods com a CNI da Amazon VPC.

Se o seu cluster estiver usando o kube-dns para resolução de DNS (consulte [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