Depois que um cluster Kubernetes on-premise está de pé e operando, é comum, cedo ou tarde, precisar aumentar a capacidade disponível — seja para suportar mais carga, seja para melhorar a resiliência distribuindo aplicações entre mais workers. Neste artigo, mostro o processo de adicionar um novo nó a um cluster que já está em funcionamento.
Esse fluxo é parecido com o de ingressar os workers pela primeira vez, mas com alguns cuidados extras — principalmente em relação à identidade da máquina (hostname, chaves SSH) — já que, em ambientes virtualizados, é comum clonar uma máquina template existente para agilizar o provisionamento.
Partindo de um template
Se o seu ambiente usa virtualização (VMware, Proxmox, etc.), o caminho mais rápido costuma ser manter um template de nó já preparado — com o sistema operacional, o containerd e os pacotes do Kubernetes (kubelet, kubeadm) previamente instalados, seguindo os mesmos passos usados nos nós originais do cluster.
Para provisionar uma nova máquina, basta clonar esse template. No entanto, uma máquina clonada de um template carrega consigo algumas identidades que precisam ser regeneradas antes de entrar no cluster — caso contrário, o novo nó pode entrar em conflito com o nó original que deu origem ao template.
Regenerando as chaves SSH
Máquinas clonadas de um template compartilham as mesmas chaves SSH do host de origem, o que representa um risco de segurança (a mesma identidade SSH "existe" em duas máquinas diferentes). Regenere as chaves do zero:
ssh-keygen -t rsa -f ssh_host_rsa_key
ssh-keygen -t ecdsa -f ssh_host_ecdsa_key
ssh-keygen -t ed25519 -f ssh_host_ed25519_key
Esses comandos devem ser executados no diretório /etc/ssh/, sobrescrevendo as chaves herdadas do template.
Ajustando o hostname
Ainda copiando a identidade do template, o hostname da nova máquina provavelmente está duplicado com o da origem. Defina um novo hostname, único para esse nó:
hostnamectl set-hostname <new-name>
Em seguida, adicione o novo nó no arquivo /etc/hosts de todas as máquinas do cluster (master e demais workers) — assim como fizemos na configuração inicial do cluster —, garantindo que todos os nós consigam resolver o nome do novo servidor.
Atualizando os pacotes do sistema
Antes de integrar o novo nó ao cluster, é uma boa prática garantir que ele esteja com os pacotes do sistema operacional atualizados:
apt update
apt upgrade
Ingressando o novo nó no cluster
Com a identidade da máquina corrigida e o sistema atualizado, o processo de ingresso é o mesmo usado para adicionar qualquer worker: gerar um comando de join válido no master e executá-lo no novo nó.
No servidor master, gere um novo token e o comando de join completo:
kubeadm token create --print-join-command
No novo nó, execute o comando retornado (os valores de token e hash abaixo são apenas ilustrativos):
kubeadm join 192.168.121.100:6443 --token r5jtqh.pek7... --discovery-token-ca-cert-hash sha256:518233918ee0353672...
Confirmando a integração
De volta ao master, confira se o novo nó aparece na lista e está com status Ready:
kubectl get nodes
Se o novo worker aparecer com status NotReady por mais que alguns minutos, vale investigar se a rede de pods (CNI) foi propagada corretamente para ele e se o containerd está rodando sem erros na nova máquina.
Considerações finais
Adicionar nós a um cluster já em produção é, na essência, o mesmo processo usado na montagem inicial — a diferença está nos cuidados extras quando a máquina é provisionada a partir de um template ou clone, garantindo que ela tenha uma identidade própria (SSH e hostname) antes de entrar na rede do cluster. Manter um template atualizado com o containerd e o Kubernetes já instalados é uma forma prática de agilizar esse processo de escalonamento horizontal do cluster ao longo do tempo.
Top comments (0)