Marcio Cunha

Como criar um cluster Kubernetes leve com k3s e banco externo

Aprenda a estruturar um cluster Kubernetes leve e resiliente voltado para edge computing utilizando k3s e um banco de dados relacional externo.

Marcio Cunha•4 min
Também disponível em:EnglishEspañol
Resumo
  • O k3s reduz drasticamente o consumo de memória ao remover componentes legados e pesados do Kubernetes tradicional
  • Utilizar um banco de dados relacional externo elimina a dependência do etcd interno no cluster
  • Ambientes de edge computing exigem resiliência alta contra falhas de rede e quedas de energia repentinas
  • Ferramentas como o Proxy Manager e bancos robustos garantem a integridade operacional das aplicações distribuídas
  • Monitorar o consumo energético e térmico dos nós evita paradas inesperadas em locais remotos de difícil acesso

Por que escolher o k3s para ambientes de borda e edge computing

Gerenciar servidores em locais remotos, conhecidos na tecnologia como edge computing, traz desafios únicos que vão desde a instabilidade na internet até restrições severas de hardware. O Kubernetes tradicional, criado para grandes data centers, costuma exigir recursos demais para rodar confortavelmente em computadores menores ou mini PCs instalados na ponta da rede. É exatamente nesse cenário que o k3s se destaca como uma alternativa inteligente e altamente enxuta para engenheiros e entusiastas de infraestrutura.

Na prática, o k3s remove componentes pesados e duplicados que o Kubernetes original carrega por padrão, substituindo-os por versões simplificadas e otimizadas para baixo consumo. Isso significa que você ganha toda a capacidade de orquestração de containers sem desperdiçar memória preciosa com processos desnecessários. Além disso, antes de projetar sua infraestrutura de borda, vale a pena entender como calcular o consumo elétrico real do seu homelab para evitar surpresas na conta de luz ou quedas por sobrecarga elétrica.

A arquitetura ideal separando o banco de dados do cluster

Quando montamos um cluster de alta disponibilidade, a forma como salvamos os dados do sistema faz toda a diferença para garantir que o serviço não caia. O método padrão do Kubernetes utiliza o etcd, um banco de dados chave-valor interno que exige conexões de rede extremamente rápidas e estáveis entre os nós para manter o consenso. Em ambientes de borda, onde os links de internet costumam oscilar, manter o etcd distribuído pode gerar instabilidades graves e perda de quorum no cluster.

A solução mais robusta para contornar esse problema consiste em desacoplar o banco de dados do plano de controle do Kubernetes, utilizando um banco relacional externo como o PostgreSQL ou MySQL gerenciado separadamente. Dessa forma, os nós do k3s apontam para um servidor de banco centralizado e altamente disponível, isolando o estado do cluster de eventuais quedas repentinas de nós individuais. Caso você enfrente desafios operacionais com dados corrompidos, é sempre útil consultar estratégias sobre como automatizar o recovery no PostgreSQL para manter a operação sempre protegida.

Preparando o ambiente e instalando o primeiro nó do k3s

Antes de colocar a mão na massa, certifique-se de que o seu servidor de banco de dados externo já esteja acessível pela rede local e com as regras de firewall devidamente configuradas para aceitar conexões nas portas corretas. O processo de instalação do k3s com banco externo utiliza uma string de conexão parecida com qualquer outra aplicação moderna, informando o endereço IP, a porta, o usuário, a senha e o nome do banco criado especificamente para o cluster.

Para iniciar a instalação no primeiro servidor que formará o painel de controle, execute o comando abaixo no terminal substituindo os dados de conexão pelos seus valores reais:

curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC="server" K3S_DATASTORE_ENDPOINT="postgres://usuario:[email protected]:5432/k3s_cluster" sh -

Esse comando faz o download automático do binário enxuto do k3s, configura o serviço no sistema operacional e conecta o painel de controle diretamente ao seu banco de dados externo. A partir desse instante, qualquer metadado sobre os pods, serviços e configurações do cluster será gravado com segurança fora dos nós efêmeros de borda.

Adicionando novos nós para garantir a alta disponibilidade

Com o primeiro nó mestre devidamente configurado e comunicando-se com o banco externo, o próximo passo consiste em adicionar nós adicionais para garantir que a aplicação continue rodando mesmo se um dos servidores físicos falhar. Para isso, você precisará do token secreto gerado automaticamente durante a instalação do primeiro servidor mestre, localizado geralmente no caminho interno do sistema.

Execute o comando abaixo nos demais nós que farão parte da infraestrutura, apontando para o IP do primeiro servidor mestre e utilizando o token correspondente:

curl -sfL https://get.k3s.io | K3S_URL="https://192.168.1.10:6443" K3S_TOKEN="K10a1b2c3d4e...::server:abc123xyz" sh -

Na prática, isso significa que você pode escalar sua infraestrutura de borda adicionando quantos computadores forem necessários de forma rápida e padronizada. Caso algum nó venha a sofrer uma pane física irreparável, basta substituir a máquina e repetir o processo de registro sem perder nenhuma configuração central, pois todo o estado do cluster está guardado no banco externo.

Boas práticas operacionais e monitoramento na borda

Manter um cluster rodando fora de um data pool centralizado exige atenção redobrada ao comportamento dos recursos físicos locais, como espaço em disco e temperatura dos processadores. Como os ambientes de edge computing costumam ficar em locais remotos, ferramentas de observabilidade e proxy reverso ajudam a diagnosticar falhas antes que elas afetem os usuários finais. Além disso, garantir uma rede estável e sem gargalos de I/O de disco é vital para que o banco de dados externo responda com agilidade às requisições constantes do Kubernetes.

Em resumo, estruturar um cluster com k3s utilizando um datastore externo transforma a complexidade tradicional do Kubernetes em uma solução enxuta, confiável e perfeitamente adequada para a realidade de projetos distribuídos na borda. Com uma arquitetura bem planejada, você obtém escalabilidade e resiliência sem sacrificar o desempenho dos servidores menores.