4
obrenoalvim
1 min de leitura ·

Kubernetes para times pequenos: você realmente precisa ou é hype de currículo?

Kubernetes é a resposta certa para orquestração de containers em escala. Mas "em escala" é uma palavra que muita gente ignora.

O que K8s entrega

Orquestração, auto-scaling, self-healing, rollouts graduais, service discovery. Para times com dezenas de serviços e tráfego imprevisível, é poderoso.

O que K8s custa

Curva de aprendizado. Pods, Deployments, Services, Ingress, ConfigMaps, Secrets, RBAC, PersistentVolumes: essa é a lista de conceitos básicos. Existe um motivo pelo qual "Kubernetes administrator" é uma certificação.

Overhead operacional. Alguém precisa manter, atualizar e monitorar o cluster. Em um time pequeno, esse alguém vai ser tirado de produto.

Custo financeiro. Um cluster mínimo viável na AWS, GCP ou Azure não é barato. Você vai pagar por 3 nodes mínimos mesmo com tráfego zero.

O que times pequenos realmente precisam

Um container rodando em produção com restart automático em caso de falha. Railway, Fly.io, Render, ECS com Fargate, ou um VPS com Docker Compose e um processo de deploy simples resolvem isso por uma fração do custo e complexidade.

Quando K8s faz sentido

Quando você tem múltiplos serviços com requisitos de escala diferentes. Quando tem um time dedicado de infra. Quando a complexidade operacional cabe no orçamento do time.

Você usa Kubernetes por necessidade ou porque aparece bem no currículo?

Carregando publicação patrocinada...
3

Se você usar vários dockers, tem um fluxo complexo, é útil sim. A questão é se você precisa do fluxo complexo ou mesmo usar Docker.

camiseta: No Meu Container Funciona

Isso é meme, mas é real.

Ser tirado do produto é um pouco de exagero mas acontece mesmo o desvio de foco.

De fato, a maioria usa a metodologia orientada a currículo.

Muitas pessoas entraram na área por meios errados (influencers) e não sabem fazer o simples.

https://www.tabnews.com.br/maniero/faq-do-programador-perdidao.

S2

Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente (não vendo nada, é retribuição na minha aposentadoria) (links aqui).

1

O ponto do fluxo complexo é o divisor de águas. Quando você tem 10+ serviços com healthchecks encadeados, secrets diferentes e dependências de startup, o Compose começa a ficar ilegível e K8s passa a fazer sentido real. O problema é que a maioria adota antes de chegar nesse ponto. A parte da metodologia orientada a currículo é o que mais me preocupa: as pessoas aprendem K8s antes de entender o problema que ele resolve.

3

Existe um outro caso que não teve a devida atenção, usar o Kubernetes para aprendizado. O projeto pode não demandar o uso realmente vamos supor um side project, uma vps com 1vcpu e 4gb de ram resolve? Provavelmente sim. Fazer o deploy com um docker compose simples vai ser um grande aprendizado? Nas primeiras vezes mas depois nem tanto. Uma opção é contratar uma vps um pouco maior com 2vCPU e 8gb de ram e instalar uma distribuição mais leve como MicroK8s ou K3s que são boas opções para aprender a usar em um ambiente real sem gastar uma fortuna na AWS. Sim para projetos sem escala Kubernetes é um pouco over mas tambem é um aprendizado valido na area e existem alternativas para não ter que usar um kubernetes completo em cloud em um sistema simples.

1

Esse argumento de aprendizado em ambiente real é válido. K3s numa VPS de 8gb com projeto próprio é a forma mais barata de aprender sem gastar em EKS. A ressalva é que muita gente confunde aprendeu a subir com entende o que está operando, e aí o lado negativo do K8s aparece quando algo quebra em produção.

3

Menos de 3 meses com uma aplicação no ar nem pode falar que sabe o básico de kuberenetes pois ainde nem pegou um problema cabeludo em prod, mas realmente confundem muito subir com manter, subir um K3s é trivial, 5 minutos você sobe mas manter semanas com coisa rodando de verdade e recebendo update é outra história.

1

A distinção que você faz é exata. Subir é tutorial. Manter é onde a conta vem. Atualização de versão do K3s com workload real rodando, rotação de secrets, debugging de pod que não sobe por conta de limite de memória mal configurado: isso é o que os "aprendi K8s em 3 meses" não passaram. O problema é que o mercado confunde o certificado de "subi um cluster" com experiência real, e aí o time contrata alguém pra manter o que não sabe manter.

3

Pelo menos a discussão não é usar barriga da máquina vs containers.

Já é uma discussão mais elevada, entre usar k8s ou docker-compose.

Tudo tem tradeoffs, vou focar em defender o uso de k8s. Gitops com argocd, serviços self-hosted via helm chart como supabase ou n8n facil de fazer deploy, ingress, secrets.

Já usei barriga de máquina, docker, docker compose, docker swarm, e agora uso k8s.

Uma vps com 4gb de ram da pra rodar um k3s, os devs podem usar k3s local, uma máquina com mais recursos pode ter namespaces e ingress separados para ambiente dev/staging/prod.

Caso precise expandir ou escalar, já tem os manifestos yaml ou helm charts prontos para subir em um EKS ou um cluster próprio de talos.dev por exemplo.

Usar k8s te deixa mais próximo de ser agnóstico da cloud, diminuindo o risco de vendor-lockin.

Meu fluxo pessoal de uso de containers:

  • intellij/vscode/shell
  • docker
  • docker-compose
  • k3s
  • k8s prod
1

O argumento do vendor lock-in com manifests prontos é legítimo se você já está nessa jornada de qualquer jeito. Mas esse fluxo só funciona bem pra quem já passou pelo docker swarm e entende o que cada camada resolve. Pra quem vem do compose direto, o k3s ainda custa caro em curva de aprendizado antes de gerar valor.

3

"custa caro em curva de aprendizagem"

No meu caso, é tipo dirigir um carro popular durante a vida toda depois pilotar um carro de luxo, da pra voltar, mas fica o gostinho do luxo por um tempo.

Depois de ficar "fluente" em kubernetes, usar docker puro ou docker compose é como se eu estivesse voltando pra barriga da máquina ao invés de usar containers.

Assim como a W3C define padrões para a web, a CNCF atua como uma fundação neutra que organiza e "aprova" projetos de infraestrutura em nuvem.

https://landscape.cncf.io/

A discussão do uso de docker-compose é para cenário de desenvolvimento, sobre o swarm, tenho péssimas experiências práticas com ele rodando em 4 máquinas em produção, cuidar do deploy automatizado, ingress, batches ou jobs requer muito contorno, as secrets viram arquivos dentro dos container, resolução de nome dos serviços interno era instável.

Sugiro reavaliar o tal "custo de curva de aprendizagem" ainda mais com um monte de LLM para ajudar hoje em dia.

1

A experiência com Swarm faz sentido, esse problema de resolução de nomes e secrets como arquivo é clássico do ecossistema.

Mas o meu ponto sobre custo não é só a curva de aprendizado inicial. É o overhead contínuo depois que você já sabe: monitorar etcd, gerenciar certificados, debugar scheduling, entender por que um pod não subiu. LLM ajuda a aprender mais rápido, mas não opera o cluster por você no domingo de madrugada.

Sobre a analogia do carro de luxo: faz sentido quando você tem a estrada certa. Para um time de 2 devs com 3 serviços, o luxo vira manutenção que ninguém pediu e que ninguém no time tem contexto para resolver rápido.

O landscape CNCF é impressionante e também é parte do problema.

3

Salve meu bom, boa noite!
Excelente post, o mundo de TI sempre vive/mantém-se de hype. Eu sou CKA e te digo que Kubernetes não é uma bala de prata para todo e qualquer projeto.
Diria que em mais de 90% das vezes, alternativas (como as que você já citou no texto) funcionam perfeitamente.
Eu mesmo tenho dois projetos publicados que fazem uso de um docker padrão para rodar, sem compose. Colocar K8s nessa soma de uma aplicação/projeto simples só dificulta as coisas: você precisa tomar conta dos Nodes de Control Plane, rotação de certificados, atualização da versão do K8s, etc.
Se você tem um projeto pequeno ou que consegue mensurar a quantidade de usuários, Docker já resolve todos os problemas, não queira matar uma formiga com um canhão.

1

CKA e ainda recomendando Docker padrão pra projetos simples, isso vale mais que qualquer post. O argumento do canhão pra formiga é exato: não é só overkill técnico, é assumir responsabilidade operacional que não gera retorno. Dois projetos sem compose, roda direto na VPS?