Containers e orquestração

O problema

Tem dois erros comuns quando o assunto e container e orquestração.

O primeiro:

• achar que container resolveu toda a operação

O segundo:

• achar que sem dominar Kubernetes por dentro você não entendeu nada

Os dois atrapalham.

Porque o ponto forte desse tema não e decorar objeto da plataforma.

E entender o problema que ela esta tentando resolver.

Modelo mental

Separando de forma simples:

• imagem e o pacote da aplicação com seu contexto de execução
• container e uma instancia rodando dessa imagem
• orquestração e a camada que decide onde isso roda, como escala, como reinicia e como recebe tráfego

Ou seja:

container reduz variação de execução

orquestração reduz caos operacional de manter várias instancias vivas

Quebrando o problema

O que container ajuda a resolver

Container ajuda bastante quando o time sofre com:

• dependência local divergente
• runtime diferente por ambiente
• setup manual demais
• empacotamento inconsistente

Ele melhora a previsibilidade de como a aplicação sobe.

Mas isso não significa que ele resolva:

• configuração ruim
• observabilidade fraca
• deploy inseguro
• bug de código

O que orquestração ajuda a resolver

Quando você tem várias instancias, mais tráfego e mais falha real, aparece outro conjunto de perguntas:

• quantas replicas eu quero?
• onde elas vao rodar?
• o que acontece se uma morrer?
• como tiro uma do ar sem quebrar tudo?
• como o tráfego encontra a instancia certa?

Orquestração entra aqui.

Ela normalmente cuida de coisas como:

• scheduler
• health checks
• reinicio automático
• service discovery
• rollout

Não porque isso seja bonito.

Mas porque fazer tudo manualmente escala mal.

Health check importa mais do que parece

Muita gente subestima esse ponto.

Sem um jeito claro de dizer se a instancia esta pronta e saudavel, o sistema pode:

• mandar tráfego cedo demais
• manter no ar algo quebrado
• reiniciar sem critério

Health check ruim vira incidente silencioso.

Scheduler e service discovery em linguagem humana

Scheduler responde:

em qual maquina ou nodo isso vai rodar?

Service discovery responde:

como outro serviço ou o balanceador encontra essa instancia?

Você não precisa decorar API de plataforma para entender o valor dessas duas respostas.

Exemplo simples

Imagine uma API que antes rodava em uma VM manualmente.

Conforme cresce, o time quer:

• duas ou mais replicas
• restart automático se o processo cair
• deploy gradual
• distribuição de tráfego

Só com container, você melhora empacotamento.

Mas ainda sobra coordenar:

• onde subir
• quantas replicas manter
• qual esta pronta para receber tráfego
• como trocar versão sem corte bruto

E aqui que a orquestração deixa de parecer luxo e passa a parecer organização mínima.

Erros comuns

• Chamar qualquer uso de container de arquitetura madura.
• Achar que container substitui observabilidade e rollout.
• Tratar orquestrador como assunto proibido para quem não e SRE.
• Entrar em Kubernetes por objeto antes de explicar o problema.
• Ignorar readiness e health checks ao falar de operação.

Como um senior pensa

Quem tem mais experiência costuma ouvir “vamos usar container e Kubernetes” e perguntar:

“Que parte do nosso problema isso resolve: empacotamento, escalabilidade, recuperação, rollout ou descoberta de serviço?”

Essa pergunta filtra bastante exagero.

Porque obriga a ferramenta a responder a um problema real.

O que o entrevistador quer ver

Em entrevista, o avaliador normalmente não precisa de aula profunda de cluster.

Ele quer ver se você entende:

• o que container melhora
• o que orquestração adiciona
• por que isso importa em produção

Uma resposta forte costuma soar assim:

“Container ajuda a empacotar a execução com mais previsibilidade. Orquestração ajuda a manter replicas rodando, reiniciar falha, distribuir tráfego e conduzir rollout com menos trabalho manual.”

Não precisa dominar Kubernetes em detalhe para entender por que processo espalhado sem coordenação vira bagunca cara.