Kubernetes só quando há plataforma: um caminho feliz para publicar, identidade, rede, observabilidade e um dono de cluster. Sem isso, “vamos de K8s” é palavra mágica — cada squad vira administrador, o YAML vira ticket, o diagrama na sala não tem operação. Este artigo é sobre plataforma de entrega, não sobre alocar gente para “fazer cluster”.

Junho puxa moda de orquestração no planejamento. Platform engineering é o pré-requisito. Observabilidade no workload publicado. Quando o agente publica piora o ruído se o cluster já era opaco.

O que “há plataforma” significa aqui

  • o squad publica sem abrir chamado de manifesto;
  • upgrade e backup não são herói de sexta;
  • política de recurso (limite, namespace) existe;
  • log e métrica do workload saem no padrão;
  • exceção (DaemonSet especial, privilégio) tem prazo.

Se o time de produto edita CNI na terça, vocês não têm plataforma. Têm um cluster compartilhado com sorte. Sorte não é operação.

Não misturamos este tema com alocação de agentes nem com perfil de squad. O recorte é: orquestrador como produto interno. Quem opera o produto interno é time de plataforma (interno ou fábrica), com golden path.

Quando o monolito no VM ainda ganha

Poucos serviços, um deploy, time pequeno, sem necessidade de densidade. Kubernetes antecipado é custo de complexidade. Complexidade pede plataforma. Plataforma pede produto. Produto pede usuário interno e aceite. Pule a moda se a cadeia não existe.

Diagrama de cluster sem logos — capa — deveria mostrar o fluxo de publish, não o marketing do projeto. Se o desenho não tem o squad como usuário, o desenho mente.

O anti-padrão do YAML artesanal

Cada time com seu chart, sua versão, seu ingress. Drift de manifesto é primo do drift de Terraform. Padronize um. Só um. Depois o segundo.

Fábrica que herda “já temos cluster” começa pelo path: como o serviço X sobe hoje de verdade. Muitas vezes a resposta é kubectl no laptop. Esse é o diagnóstico, não o julgamento.

Plataforma é produto interno com usuário (o squad) e aceite. Cluster gerenciado tira o etcd; não tira o ticket de manifesto. Um serviço só raramente paga essa complexidade. Vários serviços sofrendo o mesmo deploy — aí o catálogo curto e o dono. Este artigo não mistura o tema com alocação de gente nem com governança de agente. O recorte é o trilho de publicar.

Como a Tech Coders trata orquestração na fábrica

Na fábrica de software, cluster só entra se o trilho de publicar estiver no sprint: golden path, dono, observabilidade. Sprint de 15 dias. Não vendemos Kubernetes como palavra. Vendemos o recorte de plataforma que o time de produto usa. Sustentação 24×7 no trilho, não no YAML de cada um.

Perguntas frequentes

Managed Kubernetes já é plataforma?

É cluster gerenciado. Plataforma é o caminho do squad. O managed tira o etcd; não tira o ticket de manifesto se ninguém fez o path.

Precisamos de K8s para “ser cloud native”?

Não. Cloud native é entrega e operação. VM bem publicada com pipeline pode ser mais nativa do que cluster sem dono.

Agente pode aplicar manifesto?

Só no trilho, com o mesmo teto de qualquer publisher. Isso não é motivo para adotar cluster. É motivo para não dar kubectl amplo ao modelo.

Quando vale a pena começar?

Quando vários serviços sofrem o mesmo problema de deploy e o time aceita pagar o custo de plataforma. Um serviço só raramente justifica. Conte os usuários internos do path, não os pods imaginários.