Início / Serviços / Kubernetes & contêineres
Serviço

Kubernetes & contêineres — no tamanho certo para a sua operação

Colocamos suas aplicações em contêineres e as operamos em cluster — no tamanho que o seu ambiente pede hoje: Kubernetes completo quando há escala e ecossistema em jogo, k3s quando você quer Kubernetes de verdade rodando num único servidor e já pronto para virar cluster na nuvem, ou Docker Swarm quando a resposta certa é a solução mais enxuta possível.

apcode@cluster:~$
// mesma aplicação, dois orquestradores
$ kubectl apply -f k8s/
deployment.apps/api created
ingress.networking.k8s.io/api created
$ docker stack deploy -c stack.yml app
Creating service app_api
Creating service app_proxy
// a escolha depende do seu contexto,
// não da moda do momento.

Quando contêineres resolvem um problema real

Contêiner não é objetivo, é meio. Estes são os sintomas que costumam justificar o investimento — se você reconhece dois ou mais, provavelmente há ganho imediato.

"Na minha máquina funciona"Ambientes de desenvolvimento, homologação e produção divergem e cada deploy vira uma caça a diferenças de versão.

Deploy manual e arriscadoSubir uma versão exige janela noturna, passo a passo em documento e alguém de plantão para reverter na unha.

Servidor único como ponto de falhaSe a máquina cai, o sistema cai junto — não existe outro nó pronto para assumir a carga.

Picos de uso sem folgaEscalar significa comprar um servidor maior, não distribuir mais réplicas do serviço que está sofrendo.

Certificados e segredos manuaisTLS renovado à mão, senhas em arquivo .env versionado e nenhuma trilha de quem acessou o quê.

Máquinas ociosas e carasVários servidores usando 10% da CPU porque cada aplicação exige o seu próprio, sem compartilhar recursos.

Caminhos para rodar seu cluster

Kubernetes é o padrão da indústria e resolve praticamente tudo — ao custo de complexidade e de uma operação que precisa ser mantida. Docker Swarm entrega orquestração de verdade (alta disponibilidade, rolling update, service discovery, balanceamento) com uma fração dessa curva. E existe o meio-termo que mais recomendamos hoje, o k3s: Kubernetes certificado que roda até em um servidor só. Trabalhamos com os três e recomendamos o que couber no seu time, no seu orçamento e no seu SLA.

Escala & ecossistema

Kubernetes (k8s / k3s)

O orquestrador padrão do mercado, com ecossistema enorme e automação de sobra. Em nuvem, usamos a distribuição gerenciada do provedor; em servidor próprio, o k3s — Kubernetes certificado e leve, que roda até em um nó só e depois migra para a nuvem sem reescrita.

Indicado quando
  • Há muitos serviços, times distintos e necessidade de isolamento por namespace e RBAC granular
  • A carga oscila e o autoscaling (HPA/VPA, e de nós na nuvem) paga o próprio custo
  • O ambiente depende de ecossistema: cert-manager, operators de banco, service mesh, GitOps
  • Existe requisito de multi-cloud, compliance ou portabilidade entre provedores
  • O deploy precisa ser declarativo e reconciliado continuamente (ArgoCD/Flux)
Custo honesto: mais peças para manter (control plane, CNI, CSI, ingress controller, upgrades de versão). Faz sentido quando alguém — seu time ou nós — opera isso de forma contínua.
Simplicidade & baixo custo

Docker Swarm

Cluster nativo do próprio Docker Engine: docker swarm init e você já tem orquestração. Seus docker-compose.yml viram stacks quase sem reescrita, e a operação cabe na cabeça de um time pequeno.

Indicado quando
  • O ambiente tem de 2 a 6 nós e algumas dezenas de contêineres — não centenas
  • A equipe já domina Docker Compose e não tem banda para manter Kubernetes
  • Você quer alta disponibilidade e rolling update sem contratar uma stack inteira em volta
  • A infraestrutura é on-premise ou em VPS enxutas, com orçamento controlado
  • O objetivo é sair do servidor único agora, com caminho de evolução depois
Custo honesto: sem autoscaling nativo por métrica, ecossistema bem menor e evolução lenta do projeto. Para quem não precisa desses recursos, isso é economia; para quem precisa, é o sinal de ir de Kubernetes.

Falta o terceiro caminho — e ele costuma ser a resposta certa: k3s, Kubernetes certificado que roda em um único servidor e cresce sem trocar de tecnologia. Veja abaixo por quê.

A nossa recomendação mais frequente

k3s: começa em um servidor só, termina em cluster na nuvem — sem reescrever nada

O k3s é Kubernetes certificado pela CNCF — mesma API, mesmos manifestos, mesmo kubectl, mesmos charts Helm — empacotado num binário único que sobe em minutos e cabe em uma máquina modesta. Ele resolve o mesmo problema que leva as empresas a considerarem o Docker Swarm (rodar bem com pouca infraestrutura e pouca equipe), só que sem o beco sem saída: o dia em que o ambiente precisar de um cluster gerenciado em nuvem, o que muda é o destino do kubectl apply, não a sua aplicação.

A mesma tecnologia nos três estágios
1
Um único nó Um servidor no escritório, uma VPS barata ou até um mini-PC. Já entrega deploy declarativo, ingress com TLS, rollback e todo o ecossistema Kubernetes — sem alta disponibilidade, o que é uma escolha consciente de custo, não uma limitação da tecnologia.
mesmos YAML, mesmos charts
2
Cluster com alta disponibilidade Adiciona-se nós de controle e de carga (server e agent) com etcd embutido. A aplicação não sabe que mudou de casa: os mesmos manifestos passam a rodar distribuídos, agora tolerando a queda de um nó.
mesmos YAML, mesmos charts
3
Kubernetes gerenciado na nuvem EKS, GKE, AKS ou o k8s do provedor nacional que preferir. Como tudo sempre foi Kubernetes padrão, a migração é apontar o pipeline para o novo cluster e ajustar o que é específico de provedor — storage class, load balancer, DNS —, não reescrever a plataforma.
k3s — do zero ao cluster
// 1. um nó, uma linha
$ curl -sfL https://get.k3s.io | sh -
k3s is up and running
$ kubectl get nodes
alphaserver Ready control-plane,master
// 2. virou cluster: novo nó entra
$ k3s agent --server https://... --token ...
// 3. subiu pra nuvem: mesmo comando,
// outro kubeconfig
$ kubectl apply -f k8s/ --context prod-eks
deployment.apps/api configured
Já vem montado Ingress (Traefik), balanceador de serviço, provisionador de volume local, containerd e controlador de Helm vêm embutidos — o que num Kubernetes completo seriam vários componentes a instalar e manter.
Leve de verdade Binário único, consumo de memória na faixa do que um Swarm exige e sem dependências externas. Roda bem em hardware modesto, em filial, em edge e até em ARM.
Homologação igual à produção O ambiente de teste do desenvolvedor pode ser um k3s local com os mesmos manifestos da produção — o que elimina a classe de erro "funcionou em homologação".
Por que isso importa na comparação com o Swarm

Os dois rodam bem em um nó só e ambos são simples de operar — a diferença aparece depois. No Swarm, o seu investimento está em arquivos de stack no formato do Compose: crescer para um Kubernetes gerenciado significa reescrever esses arquivos como manifestos e refazer rede, volumes e segredos. No k3s, o investimento desde o primeiro dia já é Kubernetes padrão — portável entre qualquer cluster, on-premise ou de qualquer nuvem. Swarm continua sendo a escolha certa quando a simplicidade máxima é o objetivo e não há horizonte de nuvem; k3s é a escolha quando você quer começar pequeno sem fechar portas.

Kubernetes gerenciado, k3s ou Docker Swarm, item a item

Sem torcida por ferramenta. A tabela abaixo é o resumo que usamos na conversa de diagnóstico para chegar a uma decisão em uma reunião, não em três semanas de prova de conceito.

Critério Kubernetes gerenciado
EKS / GKE / AKS
k3s
Kubernetes leve, on-premise
Docker Swarm
nativo do Docker Engine
Curva de aprendizado Alta — conceitos próprios (pods, services, ingress, CRDs) e vocabulário extenso A mesma do Kubernetes, com bem menos peças para instalar e manter Baixa — quem usa Docker Compose migra em dias
Instalação Provisionado pelo provedor via Terraform; exige planejamento de rede e IAM Um comando em qualquer Linux, cluster no ar em minutos docker swarm init + docker swarm join — já vem no Docker Engine
Roda em um nó só Fora do propósito — há custo fixo de control plane e balanceador Sim, caso de uso de primeira classe — um servidor já entrega Kubernetes completo Sim, com o mesmo custo mínimo de infraestrutura
Formato do manifesto YAML da API do Kubernetes, empacotado com Helm ou Kustomize Idêntico ao gerenciado — é Kubernetes certificado, sem dialeto próprio docker-compose.yml v3 com a seção deploy:
Caminho de crescimento Já é o topo: autoscaling de nós e multi-AZ por conta do provedor Nó único → cluster com HA → nuvem gerenciada, sem reescrever manifestos Cresce em nós; ir para Kubernetes depois exige reescrever os stacks
Escalonamento HPA por métrica + autoscaler de nós do provedor HPA por métrica; autoscaling de nós depende do ambiente Manual (docker service scale) — automático só com ferramenta externa
Entrada HTTP e TLS Ingress Controller + cert-manager, com balanceador do provedor Traefik já embutido; cert-manager para Let's Encrypt automático Routing mesh publica a porta; Traefik/Caddy no stack resolvem ACME
Armazenamento persistente CSI do provedor (EBS, PD, Disk) com snapshots gerenciados Provisionador local embutido; NFS ou Longhorn quando precisa replicar Volumes locais, NFS ou plugins — modelo mais simples e mais limitado
Segredos e configs Secrets/ConfigMaps com KMS do provedor e integração com Vault Secrets/ConfigMaps, integração com Vault, cifragem em repouso configurável docker secret / docker config nativos, montados em memória
Consumo de recursos Control plane cobrado à parte, além dos nós e do balanceador Binário único, pegada de memória na faixa de um Swarm; roda até em ARM Sem componente extra — o próprio Docker Engine já faz o papel
Ecossistema Completo: Helm, operators, GitOps, service mesh, políticas O mesmo do Kubernetes — nada do ecossistema fica de fora Pequeno e estável — o que existe funciona, mas há menos peças de prateleira
Multi-tenant / RBAC Namespaces, RBAC fino, quotas por time, network policies Igual ao gerenciado, com integração a identidade corporativa Isolamento básico por rede e por nó; sem RBAC granular
Esforço de operação Provedor cuida do control plane; nós, versões e custo continuam com você Upgrade é trocar o binário; a operação é sua (ou nossa) Baixo: o cluster tende a "sumir do radar" depois de estabilizado
Melhor cenário Plataforma para vários times, cargas variáveis e requisitos de compliance PME, on-premise e edge que querem Kubernetes sem o peso — e sem fechar a porta da nuvem De 1 a poucas aplicações saindo do servidor único, com simplicidade máxima

Nossa regra prática

Comece pelo requisito mais duro do ambiente. Cargas variáveis, vários times e compliance pesado, tudo em nuvem? Kubernetes gerenciado. Infraestrutura própria, orçamento controlado, mas com chance real de crescer ou migrar para a nuvem depois? k3s — é o ponto de equilíbrio na maioria dos casos. Uma ou duas aplicações que só precisam sair do servidor único, com o mínimo possível para manter? Docker Swarm resolve sem drama.

Começar em um e migrar para o outro

É um caminho legítimo — e comum. Como a imagem do contêiner é a mesma nos três casos, migrar de Swarm para Kubernetes é reescrever manifestos, não a aplicação. Saindo de k3s para um cluster gerenciado nem isso é preciso: os manifestos já são os mesmos. De todo modo, entregamos build, registry e pipeline de forma neutra, sem prender você ao orquestrador escolhido hoje.

O que entregamos no projeto

Tudo versionado em repositório Git — cluster, manifestos e pipeline. O que existe no ambiente é exatamente o que está no código, e a mesma entrega vale para Kubernetes ou Swarm.

Containerização das aplicações

Dockerfiles enxutos (multi-stage, imagem base mínima, usuário sem privilégio), healthchecks e configuração por variável de ambiente.

Registry de imagens

Registry privado (Gitea, GitLab, Harbor ou o do provedor) com versionamento por tag, credenciais no cluster e política de retenção.

Provisionamento do cluster

Nós, rede, firewall e alta disponibilidade provisionados como código (Terraform/Ansible) — nuvem ou servidores próprios.

Entrada HTTP com TLS automático

Ingress/proxy publicando seus domínios com certificados Let's Encrypt emitidos e renovados sozinhos, redirecionamento e HSTS.

Armazenamento e estado

Volumes persistentes para bancos e arquivos, com definição clara do que roda no cluster e do que fica fora dele por decisão de arquitetura.

Gestão de segredos

Senhas, tokens e chaves fora do repositório — Secrets do orquestrador integrados a um cofre (Vault) e injetados em tempo de execução.

Pipeline de deploy

CI/CD que constrói a imagem, publica no registry e atualiza o cluster com rolling update — rollback a um comando, sem janela de indisponibilidade.

Observabilidade e alertas

Métricas do cluster e das aplicações, logs centralizados e alertas acionáveis por WhatsApp, e-mail ou chat antes do usuário perceber.

Backup e recuperação

Rotina de backup dos dados e do estado do cluster, com procedimento de restauração testado — não só documentado.

Documentação e transferência

Runbook das operações do dia a dia e sessão de handover com o seu time — você opera sozinho se quiser, ou deixa a operação contínua conosco.

Como o projeto acontece

Sem big bang: a produção só muda depois que o ambiente novo já provou que funciona.

1
Diagnóstico e escolha

Levantamos aplicações, dependências, volume de tráfego e maturidade do time — e definimos junto se o caminho é Kubernetes, k3s ou Swarm.

2
Contêineres e pipeline

Empacotamos as aplicações, publicamos no registry e montamos o build automatizado, ainda sem tocar na produção atual.

3
Cluster e migração

Subimos o cluster, replicamos os serviços em paralelo, validamos carga e certificados, e viramos o DNS com plano de rollback pronto.

4
Operação contínua

Monitoração ativa, atualizações de versão, ajuste de capacidade e evolução do ambiente conforme a aplicação cresce.

A stack que colocamos em pé

Ferramentas abertas e consolidadas, sem dependência de fornecedor. Se o seu time já usa alguma delas, aproveitamos o que existe em vez de recomeçar do zero.

Kubernetes k3s Docker Docker Swarm Docker Compose Helm Traefik NGINX Ingress cert-manager Vault Prometheus Grafana Loki GitLab CI / Gitea Actions Terraform Ansible Registry privado

O que perguntam antes de começar

Sim, com uma ressalva honesta: o Swarm mode continua embarcado no Docker Engine e recebendo manutenção, mas evolui devagar e tem ecossistema pequeno. Na prática isso significa que ele é ótimo para o que já faz — cluster com alta disponibilidade, rolling update, service discovery e segredos — e ruim como aposta para requisitos que virão daqui a alguns anos (autoscaling por métrica, operators, políticas finas). Recomendamos Swarm quando o escopo é claro e estável, e Kubernetes/k3s quando há sinal de que o ambiente vai crescer em complexidade, não só em tamanho.

Com dois ou três nós já se ganha o essencial: se um servidor cai, os serviços sobem no outro, e o deploy passa a ser sem downtime. Nesse porte, Swarm ou k3s costumam ser a resposta certa — Kubernetes completo seria mais infraestrutura para manter do que aplicação rodando. Com um único servidor, o cluster ainda organiza o deploy, mas não entrega alta disponibilidade; é bom deixar isso claro desde o começo.

Serve para produção — inclusive é o que roda a nossa própria infraestrutura. O k3s é uma distribuição Kubernetes certificada pela CNCF: passa na mesma bateria de conformidade das distribuições grandes, e as diferenças estão em empacotamento e nos padrões escolhidos (componentes embutidos, banco de estado mais simples no modo de nó único), não em ser "Kubernetes pela metade". O que muda em relação a um cluster gerenciado é quem cuida da infraestrutura embaixo — e é exatamente aí que entramos.

Na maioria dos casos, não. O que costuma mudar são pontos de acoplamento com o servidor: configuração passa a vir de variável de ambiente, log vai para a saída padrão em vez de arquivo, sessão sai da memória local e arquivos enviados por usuário vão para um volume ou storage de objetos. São ajustes pontuais, e mapeamos todos eles ainda no diagnóstico — antes de qualquer compromisso de prazo.

Pode, mas é decisão de arquitetura, não padrão. Banco em contêiner exige storage persistente confiável, backup testado e cuidado com failover. Em muitos projetos a recomendação é manter o banco fora do cluster (serviço gerenciado ou máquina dedicada) e deixar o cluster para a camada de aplicação — que é onde o ganho de elasticidade realmente aparece. Avaliamos caso a caso, considerando volume de dados, RPO/RTO e custo.

Dá, e é bem menos traumático do que parece. A imagem do contêiner, o registry e o pipeline de build continuam os mesmos; o trabalho está em traduzir os arquivos de stack em manifestos do Kubernetes e reproduzir rede, volumes e segredos. Por isso mantemos, desde o primeiro dia, o build separado do orquestrador — decidir por Swarm hoje não fecha a porta do Kubernetes amanhã. Vale dizer: se essa migração já parece provável, começar direto em k3s elimina o trabalho de tradução, porque os manifestos escritos hoje são os mesmos que rodarão no cluster gerenciado depois.

Como você preferir. Entregamos tudo documentado e versionado para que o seu time assuma a operação, e oferecemos contrato de operação contínua para quem prefere terceirizar monitoração, atualizações e resposta a incidentes. Não usamos ferramenta proprietária nem trancamos acesso: a infraestrutura é sua, no seu repositório e na sua conta.

Não sabe se o seu caso pede Kubernetes ou Swarm?

Em uma conversa de diagnóstico a gente chega à resposta — com o desenho do ambiente e uma estimativa de esforço, sem compromisso.

Falar com um especialista