O Kubernetes completou 12 anos e consolidou-se como o "sistema operacional" das infraestruturas modernas, operando desde mainframes até ambientes de borda (Edge). Embora o ecossistema CNCF tenha evoluído drasticamente para cobrir lacunas operacionais, a gestão de clusters em ambientes on-premise ainda é um desafio crítico para muitas empresas brasileiras que buscam estabilidade sem sacrificar a flexibilidade da nuvem.
Este artigo analisa a interseção estratégica entre K3s (lightweight Kubernetes) e k0rdent para alcançar uma gestão multi-cluster declarativa. Se você opera infraestrutura local, conhece bem os gargalos: criação manual de VMs, scripts Bash legados que geram silos de conhecimento e clusters "intocáveis" que morrem após o primeiro deployment. A transição para uma abordagem declarativa, replicável e limpa é a chave para a sobrevivência operacional.
O Panorama Geral
O objetivo é claro: transformar o ambiente on-prem em uma extensão nativa da nuvem. A arquitetura proposta utiliza:
- VM Templates Existentes: Evitando a criação constante de novas imagens.
- k0rdent: Orquestração do ciclo de vida completo do cluster.
- K3s: O backbone do plano de controle.
O fluxo de trabalho segue o modelo de reconciliação:
User → k0rdent
↓
Proxmox Infrastructure (BYOT VMs)
↓
Control Plane Provider
↓
Bootstrap Provider (K3s)
↓
Running Kubernetes Cluster
Por que On-Prem + k0rdent faz sentido?
O grande problema do Kubernetes on-prem é a falta de padronização. O k0rdent altera essa mentalidade ao separar as responsabilidades em três pilares: Infraestrutura (provisão de VMs), Control Plane (configuração de topologia) e Bootstrap (instalação do K3s). Essa separação permite uma integração limpa com hipervisores como Proxmox.
Passo 1: Provedor de Infraestrutura (BYOT)
O conceito de Bring Your Own Template (BYOT) é vital para a eficiência.
Ao usar templates de VM pré-configuradas (com cloud-init, SSH e hardening de SO), garantimos:
- Agilidade no Provisionamento: Sem builds demorados no pipeline.
- Segurança: Governança sobre o SO gerenciada fora da camada de Kubernetes.
- Observability simplificada: Quando o problema reside na VM, ele é mais fácil de isolar e diagnosticar.
Passo 2: Provedor de Control Plane
Para times que buscam evitar configurações "acidentais", a via declarativa é mandatória. O Control Plane Provider assume a gestão assim que as VMs estão disponíveis, coordenando a topologia do cluster.
Passo 3: Bootstrapping com K3s
O K3s é a escolha ideal devido à sua pegada reduzida (lightweight). Abaixo, a estrutura de definição dos providers:
apiVersion: operator.cluster.x-k8s.io/v1alpha2
kind: BootstrapProvider
metadata:
name: k3s
spec:
version: v0.3.0
fetchConfig:
url: https://github.com/k3s-io/cluster-api-k3s/releases/v0.3.0/bootstrap-components.yaml
O Bootstrap Provider automatiza a instalação, a geração do cluster token e a união dos nós (control plane e workers), resultando em um ambiente prontamente funcional.
O Poder da Reconciliação Contínua
Com o k0rdent, o sistema monitora constantemente o estado desejado: provisiona, verifica conectividade, injeta o bootstrap e corrige qualquer drift de configuração. O resultado para o seu time de engenharia não é apenas um cluster on-prem, mas um serviço escalável que pode ser descartado ou replicado via código.
Executar Kubernetes on-prem não é mais sinônimo de "gambiarras" ou scripts bash frágeis. Com a abordagem correta, sua infraestrutura local torna-se um cidadão de primeira classe no seu stack tecnológico.
Artigo originalmente publicado por Shivani Rathod (Improwised Tech) & Prithvi Raj (CNCF Ambassador) em Cloud Native Computing Foundation
