Montando um Cluster Kubernetes On-Premise — Parte 1: Preparando o Ambiente

🇺🇸 English version coming soon.

Esta é a primeira parte de uma série onde vou compartilhar, passo a passo, como montei meu cluster Kubernetes on-premise, sem depender de provedores de nuvem. A ideia é documentar o processo completo — desde a preparação do ambiente até um cluster funcional — para servir de referência tanto para quem está estudando quanto para quem quer replicar a mesma estrutura em casa ou no trabalho.

Eu usei VPS (Virtual Private Server) e VM (Virtual Machine) para este cluster. Mas pode ser montado em máquinas reais (Bare Metal) também.

Ao final desta série, ficará mais fácil entender os clusters em nuvens da AWS (EKS), Google (GKE) e Azure (AKS).

Nesta primeira parte, vamos cobrir o que é necessário antes de instalar qualquer componente do Kubernetes: os requisitos de hardware, a configuração de rede básica, o firewall e alguns ajustes obrigatórios no sistema operacional.

Requisitos mínimos

Para este cluster, eu utilizei 3 servidores com Debian 11 e 12:

• 3 servidores no total.
• 1 servidor master (control-plane): 2 CPUs (cores) e 2 GB de RAM
• 2 servidores slaves (workers/nodes): 1 CPU e 1 GB de RAM cada
• Acesso root em todas as máquinas

Essa é uma configuração mínima, ideal para ambientes de estudo, laboratório ou testes. Para produção, o recomendado escalar os recursos de acordo com a carga esperada.

Configurando o arquivo hosts

Antes de instalar qualquer coisa, é importante que as máquinas se enxerguem pela rede por nome, não somente por IP. Para isso, edite o arquivo /etc/hosts em todos os servidores e adicione as entradas correspondentes:

10.0.10.100  master.empresa.local    master
10.0.10.101  slav01.empresa.local    slav01
10.0.10.102  slav02.empresa.local    slav02

Isso garante que, mais adiante, os componentes do Kubernetes consigam resolver os nomes dos nós corretamente.

Configurando o Firewall

O Kubernetes depende de portas específicas abertas entre os nós para que o control-plane consiga se comunicar com os workers (e vice-versa). As portas variam conforme o papel do servidor no cluster.

No servidor master:

Porta	Protocolo
6443	TCP
2379-2380	TCP
10250	TCP
10251	TCP
10252	TCP
10253	TCP

Nos servidores slaves (workers):

Porta	Protocolo
10251	TCP
10255	TCP

Certifique-se de liberar essas portas na ferramenta de firewall utilizada (ufw, firewalld, iptables, etc.), de acordo com a distribuição Linux que você está usando.

Desabilitando o SWAP

O Kubernetes exige que o SWAP esteja desabilitado em todos os nós do cluster. Isso acontece porque o kubelet não gerencia corretamente a memória quando o SWAP está ativo, o que pode gerar comportamentos inesperados no agendamento de pods.

Primeiro, verifique se há SWAP ativo:

# swapon -s

Se houver, desative-o:

# swapoff -a

Essa desativação, é temporária — ela não sobrevive a um reboot. Para tornar a mudança permanente, edite o arquivo /etc/fstab e comente a linha referente ao SWAP:

#/dev/mapper/master--vg-swap_1 none swap    sw  0   0

Testando a comunicação entre os nós

Com o /etc/hosts configurado, confirme que os servidores conseguem se comunicar entre si antes de seguir em frente:

# ping slav01
# ping slav02
...

Se os pings forem bem-sucedidos (indo e voltando), o ambiente de rede está pronto.

Reiniciando os servidores

Para garantir que todas as alterações (principalmente a desativação do SWAP) foram aplicadas corretamente, reinicie todos os servidor:

# shutdown -r now

ou 

# reboot

Próximos passos

Com o ambiente preparado — hardware definido, rede configurada, firewall ajustado e SWAP desabilitado — já temos a base necessária para começar a instalação dos componentes do Kubernetes propriamente ditos.

Na Parte 2 desta série, vamos instalar o container runtime e os pacotes do Kubernetes (kubeadm, kubelet e kubectl) em todos os nós.

Continua na Parte 2.