Executando verificação de segurança...
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
maniero

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
obrenoalvim
  • Autor
    Autor

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.

1
osnibjunior

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
Nilzao

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
LukaKuuhaku

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.