Montando um Cluster Kubernetes On-Premise — Parte 4: Ingressando os Nós Workers Nodes

🇺🇸 English version coming soon.

Nas partes anteriores, preparamos o ambiente (Parte 1), instalamos o containerd e o Kubernetes (Parte 2) e inicializamos o control-plane no servidor master, incluindo a rede de pods (Parte 3). Agora vamos fechar o ciclo básico do cluster: unir os servidores workers ao master e confirmar que tudo está funcionando corretamente.

Ingressando os nós workers nodes

Em cada servidor worker que você deseja adicionar ao cluster, execute o comando kubeadm join gerado no final da inicialização do master (Parte 3). Ele tem o seguinte formato:

kubeadm join 10.0.10.100:6443 --token 9e0xeu.s0if3... --discovery-token-ca-cert-hash sha256:3a328e56729515d...

Esse comando usa o token e o hash do certificado para autenticar o worker junto ao control-plane e permitir que ele se junte ao cluster com segurança.

E se perdeu o token?

Tokens do kubeadm expiram por padrão após 24 horas. Se você não guardou o token (ou ele já expirou), não tem problema — é possível gerar um novo comando de join a qualquer momento, direto no master:

# kubeadm token create --print-join-command

Esse comando cria um novo token e já retorna o comando completo, pronto para ser copiado e executado nos workers.

Verificando os nós do cluster

Depois de rodar o kubeadm join em todos os workers, volte para o master e confira se os nós foram adicionados corretamente:

kubectl get nodes

Ou, para uma saída com mais detalhes (endereço IP interno, versão do kernel, container runtime, etc.) acrescente -o wide ao final do comando:

kubectl get nodes -o wide

A opção -o wide acrescenta informações extras à saída padrão.

A saída deve ser parecida com esta:

Todos os nós devem aparecer com o status Ready. Se algum worker aparecer como NotReady, vale conferir se a rede de pods (CNI) foi aplicada corretamente e se o containerd está rodando sem erros nesse nó.

Lidando com taints indesejados

Em alguns casos, um nó pode ficar marcado com um taint que impede o agendamento de novos pods nele — por exemplo, quando o Kubernetes detecta pressão de disco (disk-pressure). Isso é comum em ambientes de laboratório com discos pequenos ou pouco espaço livre.

Para verificar se um nó específico está com esse taint (no exemplo abaixo, o node3):

kubectl --kubeconfig=/home/celso/.kube/config.bagarote describe node node3 | grep Taint

Se o taint disk-pressure estiver presente e você quiser remover essa restrição manualmente (ciente de que o nó pode estar com pouco espaço em disco), execute:

kubectl --kubeconfig=/home/celso/.kube/config.bagarote taint node node3 node.kubernetes.io/disk-pressure:NoSchedule-

O sinal de - no final do comando é o que remove o taint — sem ele, o comando adicionaria um novo taint em vez de remover.

⚠️ Remover um taint de disk-pressure manualmente é uma medida paliativa. O ideal é investigar e resolver a causa raiz (liberar espaço em disco, aumentar o armazenamento, etc.), já que o Kubernetes aplica esse taint como proteção contra falhas por falta de espaço.

Fechando o ciclo

Com os workers ingressados e todos os nós no estado Ready, o cluster Kubernetes on-premise está oficialmente de pé: control-plane funcionando, rede de pods ativa e workers prontos para receber cargas de trabalho.

Isso encerra a base desta série — preparação do ambiente, instalação dos componentes, inicialização do master e ingresso dos workers. A partir daqui, o cluster está pronto para os próximos passos naturais de qualquer ambiente Kubernetes: deploy de aplicações, configuração de armazenamento persistente, ingress controllers, monitoramento, entre outros.

Se você seguiu essa série até aqui, já tem em mãos um cluster Kubernetes on-premise funcional, construído do zero, sem depender de nenhum provedor de nuvem.

Agora na Parte 5 desta série, vamos subir containers e testar se tudo está funcioando e recebendo carga de trabalho normalmento.

Continua na Parte 5.