Kubernetes em produção: o que um sênior resolve

Subir um cluster Kubernetes gerenciado hoje leva alguns cliques. Mantê-lo de pé com dezenas de serviços, tráfego real e uma equipe inteira dependendo dele é outra coisa. A distância entre esses dois mundos é o que você paga quando contrata um engenheiro Kubernetes sênior. Vale entender o que exatamente ele resolve, porque essa lista raramente cabe em um currículo.

O que um sênior resolve que o júnior nem enxerga

• Upgrades sem parar a operação. Subir a versão do cluster e dos node pools sem derrubar serviço exige planejamento de compatibilidade de API, drenagem de nós e teste em ambiente espelho. O júnior adia o upgrade até virar dívida; o sênior mantém o cluster próximo da versão suportada.
• Autoscaling que funciona. HPA para réplicas, VPA para dimensionamento de pod e Cluster Autoscaler ou Karpenter para nós. Configurar isso junto, sem que um brigue com o outro, é onde muita gente tropeça.
• Rede e ingress. CNI (Cilium, por exemplo), controlador de ingress, DNS interno e a decisão sobre service mesh. Quando o tráfego entre serviços fica difícil de observar e proteger, é aqui que o sênior atua.
• Segurança de cluster. Pod Security Admission, network policies que isolam namespaces, OPA ou Gatekeeper para políticas de admissão e gestão de secret sem deixar credencial no manifesto. Cluster aberto é porta de entrada.
• Custo sob controle. Rightsizing de requests e limits, uso de spot para carga tolerante a falha e limpeza de recurso ocioso. Cluster mal dimensionado queima dinheiro em silêncio.
• Cargas com estado. StatefulSets, storage, backup e restore testado. Banco dentro do Kubernetes exige cuidado que o júnior costuma ignorar.

As certificações que importam

A base é a CKA (Certified Kubernetes Administrator), que prova operação real de cluster. Para ambiente que leva segurança a sério, a CKS (Certified Kubernetes Security Specialist) é a régua, e ela exige a CKA antes. A CKAD (Kubernetes Application Developer) mostra o lado de quem empacota e implanta aplicação. Some a HashiCorp Terraform Associate para quem provisiona o cluster como código.

A CKS em especial diz muito, porque cobre exatamente a parte que o júnior pula: hardening, política de admissão e resposta a incidente no cluster.

O que perguntar na entrevista

• Conte a última vez que um upgrade de cluster deu errado. O que quebrou e como você recuperou?
• Como você configura autoscaling de pod e de nó junto, sem que o cluster fique instável?
• Um pod entra em CrashLoopBackOff em produção. Descreva seu passo a passo de diagnóstico.
• Como você isola tráfego entre namespaces e impede que um serviço comprometido alcance o resto?
• Onde você já cortou custo de Kubernetes sem sacrificar disponibilidade?

Red flags que aparecem na conversa

• A pessoa só usou Kubernetes gerenciado pela interface do provedor e nunca debugou um nó ou um pod travado.
• Aplica manifesto e torce para funcionar, sem entender requests, limits e probes.
• Nunca configurou network policy nem pensou em segurança de cluster.
• Fala de service mesh como buzzword, sem saber o custo operacional que ele adiciona.
• Trata custo como problema de outra pessoa.

Sênior real e júnior disfarçado

O júnior disfarçado roda o tutorial, sobe o cluster de exemplo e mostra que a aplicação responde. O sênior já sofreu com upgrade travado, com OOMKilled em produção, com DNS interno falhando às três da manhã e com a conta do cluster explodindo. Essa cicatriz muda como a pessoa desenha o ambiente: ela prepara para o dia ruim antes que ele chegue. Avaliar isso pede um par técnico que já operou Kubernetes em escala, porque a conversa técnica revela a bagagem em minutos.

Quando alocar em vez de contratar

A operação de Kubernetes tem duas fases. A primeira é montar bem: cluster, GitOps com ArgoCD, segurança e custo sob controle. A segunda é sustentar no dia a dia. Para a fase de montar, um especialista sênior alocado por um período resolve com velocidade e sem o passivo de uma contratação fixa de perfil raro. Para a fase de sustentar, um modelo de operação gerenciada com SLA costuma sair melhor do que manter um especialista caro em regime de plantão.

Os fatores de custo

O valor de um engenheiro Kubernetes acompanha a raridade da combinação: rodar cluster multi-cluster em produção, com segurança (CKS) e disciplina de custo, é combinação escassa. O contraste que interessa é com o custo de um cluster instável, de um incidente de segurança ou de uma fatura que dobrou por dimensionamento ruim.

Por onde começar

Separe o momento: você precisa montar, corrigir ou sustentar. Isso define se o caminho é alocar um especialista ou contratar operação gerenciada.

A Cyberwalk dá acesso a engenheiros de plataforma Kubernetes Staff+, com aprovação por par técnico e garantia de substituição. Para sustentação contínua com SLA, veja o modelo de managed services. Descreva o cluster e o desafio, e a gente traz o especialista certo.