O que entrevistas de emprego me ensinaram sobre Kubernetes

• O Kubernetes vem sendo adotado até em empresas pequenas menos pela escalabilidade técnica e mais como um padrão para resolver padronização de deploy e questões de operação organizacional
• Nas conversas recentes durante a busca por emprego, todas as empresas usavam Kubernetes, diferente do cenário de 5 anos atrás em que VM·serverless·K8s coexistiam
• Os principais motivos citados pelos CTOs eram implantar todos os serviços da mesma forma, registrar o conhecimento operacional em YAML e charts do Helm, e rastrear o histórico de mudanças com GitOps
• Empresas pequenas estão aceitando a complexidade do Kubernetes mais pelos benefícios organizacionais do que por recursos avançados como HPA, Pod Disruption Budget e afinidade de nós
• Para empresas em estágio inicial, costuma ser melhor começar sem Kubernetes para focar no produto, e a necessidade de adoção cresce a partir do momento em que o CTO deixa de ser o único responsável pela engenharia

---

Mudanças percebidas na busca de emprego recente

• Ao ler vagas, fazer entrevistas e conversar com cerca de doze equipes de engenharia durante a busca recente por emprego, todas as empresas com que conversei estavam usando Kubernetes
• Quando procurei emprego 5 anos atrás, coexistiam grupos que raramente usavam Kubernetes, grupos que usavam systemd sobre VM/VPS/EC2, e grupos serverless com Lambda e Cloud Run
• Onde trabalho hoje, há problemas em escala Big Tech, então Kubernetes faz sentido de forma clara, mas foi surpreendente ver até startups de 10 pessoas com apenas dois serviços usando Kubernetes
• As empresas com que conversei não operavam microserviços nem estavam perto de um ambiente de grande escala, e não demonstravam grande interesse no lado técnico do Kubernetes

Motivos para adotar Kubernetes e critérios de decisão

• Por que usar Kubernetes

  • O primeiro motivo era a uniformidade: se todos os serviços são implantados da mesma forma, desaparece a situação em que apenas um serviço fica preso a scripts bash antigos em uma VM bare-metal ou ao Docker Compose
  • O segundo motivo era o conhecimento compartilhável e contratável: como o Kubernetes funciona como uma linguagem comum, dá para entender rapidamente a arquitetura só olhando os charts do Helm e as configurações do Kube
  • Quando o conhecimento fica registrado em YAML, e não só na cabeça das pessoas, reduz-se a chance de alguém gastar semanas tentando descobrir como executar algo depois que outra pessoa saiu da empresa
  • No meu trabalho atual, o SRE de plantão consegue manter até serviços que nunca viu antes porque os padrões de Kubernetes são parecidos entre as equipes
  • Essa vantagem só vale quando as configurações não são excessivamente peculiares
  • O terceiro motivo era a rastreabilidade: em vez de executar kubectl apply -f diretamente no cluster, sobe-se o chart do Helm para o git e passa-se por aprovação de MR e deploy com FluxCD ou ArgoCD, deixando um histórico de mudanças
  • Esse fluxo ajuda na conformidade quase sem custo adicional porque GitOps e Kubernetes se encaixam naturalmente
  • A empresa atual está passando bem por certificações ISO dessa forma

• Conclusões obtidas

  • A escolha dos CTOs não era uma decisão tola, e sim uma forma de resolver problemas reais
  • Kubernetes parecia uma solução técnica para um problema técnico, mas muitos CTOs estavam mais interessados em vantagens não técnicas do que eu imaginava
  • Os problemas técnicos das empresas pequenas não exigem necessariamente Kubernetes, e é provável que seus manifests nem tenham topologySpreadConstraints, HPA, Pod Disruption Budget ou regras de afinidade de nós
  • Elas estão aceitando o custo operacional de um software complexo por causa dos benefícios organizacionais, mesmo mantendo um número de nós parecido com o que teriam usando VMs

• Por que a mudança aconteceu recentemente

  • Há 5 anos, VM com systemd, serverless e Kubernetes ainda eram opções válidas, mas nas vagas atuais a combinação de VM com systemd praticamente sumiu, serverless ficou em um nicho, e o Kubernetes venceu
  • O motivo exato da virada não é totalmente claro
  • Uma possível razão é que o Kubernetes gerenciado como EKS, GKE e AKS amadureceu, e também que já há gente suficiente que aprendeu Kubernetes, tornando mais difícil contratar para outras abordagens
  • O Helm também tornou realista a opção de simplesmente usar charts feitos por outras pessoas

• Quando usar Kubernetes

  • Meu critério pessoal é o momento em que o CTO deixa de ser o único engenheiro
  • Quando entra o segundo engenheiro, alguém que não configurou os servidores diretamente precisa fazer deploy, e passa a ser necessário um controle de acesso adequado em vez de sair distribuindo chaves SSH para tudo
  • Em algum momento, alguém vai deixar a empresa, e o conhecimento operacional dessa pessoa pode ir embora junto
  • A partir daí, o conhecimento precisa permanecer mais no sistema do que nas pessoas
  • Antes desse estágio, depurar um cluster de fato pode ser difícil, e a energia que deveria ir para o produto pode acabar sendo gasta em infraestrutura
  • Em vez de passar duas horas procurando a causa de um pod em CrashLoopBackOff logo antes de uma reunião com um grande cliente, pode ser mais rápido e compreensível, como resposta de emergência, corrigir às pressas com um git pull em uma VPS

[GN⁺]

Opiniões do Lobste.rs

• Na Europa, o motivo é bem claro. Os CTOs acreditam que colocar em cima de K8s permite trocar de provedor de K8s gerenciado em poucas semanas
  Isso não quer dizer que esteja certo, mas eles de fato acreditam nisso. Também acham que ambientes de PR ficam mais fáceis
  Mas o ponto principal é a troca de provedor. Há a expectativa de que, nos próximos anos, surjam proibições ao uso de provedores ligados aos EUA, especialmente em GDPR, sistemas financeiros etc. Então isso é uma preparação para esse risco

• Parece uma prova de que a indústria de tecnologia perdeu completamente o rumo, independentemente do tamanho da empresa. A stack ficou cada vez mais uniforme e complexa, e o resultado é que ficou mais difícil encontrar produtos e serviços que dê para usar sem ranger os dentes

  • As camadas de baixo nível têm tantos bugs e tanta complexidade que, para sobreviver, você acaba sendo forçado a criar algo como Kubernetes. Se quiser impedir que a stack continue subindo, é preciso melhorar as camadas de baixo
    Precisamos de elementos fundamentais de sistema operacional muito melhores. Por exemplo, contêineres eram uma mistura de vários mecanismos de isolamento do kernel sem um projeto consistente, então havia muitos buracos
    Hoje o isolamento de contêineres melhorou bastante, mas não foi algo projetado desde o início com segurança e correção — foi sendo consertado no estilo “whack-a-mole”. Até que o kernel lide com essa enorme dívida técnica, ou até alguém criar um kernel para o qual valha a pena migrar, vamos continuar empilhando coisas em cima dele

• Ferramentas de deploy suficientemente complexas acabam incluindo uma meia implementação de Kubernetes, feita como gambiarra, definida de forma informal, cheia de bugs e lenta

  • “Meia” é uma boa descrição. Só que, por acaso, essa metade é justamente a metade necessária
    Eu poderia falar longamente sobre como montamos uma empresa SaaS de e-commerce de US$ 1 bilhão em 2009, ou como funcionava o backend online de um jogo multiplayer AAA gigantesco, e essas coisas com certeza eram mais parecidas com Kubernetes do que com deploy em máquina única
    Mas eram mais rápidas e tinham opiniões fortes exatamente do jeito que a organização precisava, e não de formas que entravam em conflito com os requisitos do produto
    A parte “cheia de bugs” do Kubernetes muitas vezes não está no sistema central em si, mas nas inúmeras camadas de interface que colocamos em cima dele para fazê-lo funcionar do jeito que queremos
  • Isso se aplica a Erlang, não ao Kubernetes. Para Kubernetes, não faz o menor sentido

• O problema é que a maioria das organizações adota K8s de forma desajeitada, cria até um time de DevOps para gerenciá-lo, mas no fim joga em cima dos engenheiros de software toda a responsabilidade por escrever, implantar, depurar e operar coisas relacionadas a K8s
  Um bom time de DevOps deveria oferecer internamente uma experiência parecida com a do Heroku. Você define os recursos necessários, faz merge na main e o deploy acontece; não deveria ficar perdido tentando descobrir o que deu errado em algum dashboard ruim de GitOps/DevOps
  Heroku foi o auge da experiência do desenvolvedor, e acho que perdemos isso depois do K8s

  • Tirando o fato de você ver os Pods rodando nos nós, não sei qual é a grande diferença entre a experiência de usar Heroku e Kubernetes
    Claro, o Heroku oferece uma experiência mais integrada para conexão com banco de dados e deploy com git push, mas fazer uma casca personalizada em cima do Kubernetes não é lá grande coisa. No fim, você acaba repassando todos os parâmetros do mesmo jeito

• Na indústria, a adoção de tecnologia sempre funciona pela lógica de “contratar pronto e demitir se não servir”. Este é só o caso mais recente disso

• A frase “o conhecimento deve estar no sistema, não nas pessoas” expressa muito bem algo em que eu pensava vagamente
  Esse tipo de formalização só é possível quando a variabilidade do processo diminui. A pessoa faz manualmente, documenta o processo, transforma em script e depois automatiza
  Em workflows comuns de ferramentas ou ecossistemas populares, você ganha a maior parte dessas etapas quase de graça

• Não faço tanto DevOps, e hoje os sistemas funcionam bem só com systemd e uns contêineres podman usados de vez em quando. Trabalho com IoT/AgTech
  Este texto tem aquele tipo de “afirmação” que ouço muito de executivos não técnicos. Algo como “o pessoal de lá também usa LoRa, né? Então está resolvido? Dá para lançar amanhã?”
  Existe a crença de que a não uniformidade é o único obstáculo para o sucesso. Se dois sistemas usam Fiber, Modbus ou “têm uma API”, então seria só conectá-los de imediato e criar aquela experiência linda em que “1 + 1 é maior que a soma”
  Mas o fato de dois softwares concordarem em padrões de interoperabilidade de baixo nível não elimina o trabalho real de decidir como interpretar e usar de forma útil os dados que são fáceis de fazer parse
  O fato de duas pessoas falarem a mesma língua não faz o trabalho desaparecer. Usar uma língua em comum também não apaga as decisões que parte da equipe tomou ao usar aquelas ferramentas nas condições que conhecia na época
  No começo, Fortran era uma língua comum no meio científico/engenharia, mas isso não impedia que as pessoas ficassem completamente perdidas com o trabalho dos colegas ou precisassem reescrevê-lo
  Não tenho problema com o valor do K8s nem com o fato de ele ter se tornado o “padrão” atual. Só acho difícil concordar com a ideia de que isso faz desaparecer certos tipos de problemas de programação. A lei da conservação da feiura continua valendo

• Kubernetes é uma plataforma de deploy razoável

• A forma de distribuição também é outro motivo. Trabalho com nós Canton, e o software upstream do Canton e os apps relacionados são fornecidos como charts Helm
  Independentemente de Kubernetes ser adequado ao nosso trabalho — e eu acho que não é —, é assim que o software é distribuído e suportado. Se você sair desse caminho, acaba tendo ainda mais trabalho do que lidar com Kubernetes

• Não sei se sou só eu, mas este texto parece demais ter sido escrito por IA
  Ainda assim, concordo com a proposta. Estou migrando configurações de homelab/self-hosting que estavam em um estado de ajustes customizados no systemd, comandos de shell de que eu não lembro mais e “droga, em qual arquivo Markdown eu anotei aquele procedimento de configuração?” — e isso é realmente revigorante
  Ainda não estou usando um sistema de deploy contínuo de verdade, mas gosto da sensação de que, só com um pequeno script shell apply e um conjunto de arquivos YAML, eu conseguiria recuperar 90% mesmo depois de um desastre
  O systemd é conceitualmente simples, mas a reprodutibilidade é complexa; com Kubernetes é o contrário. Você paga um custo conceitual maior, mas a reprodutibilidade e o entendimento que vem com ela ficam muito mais fortes. Pelo menos por enquanto, é assim que vejo
  Ainda estou na fase intermediária de aprender Kubernetes, mas ultimamente tenho gostado bastante de usá-lo

  • Há 10 anos eu concordaria, mas hoje, por causa das várias opções de namespace e da integração dinâmica de usuários, o systemd também parece “mais um monstro”
    Esse tipo de integração vertical com definições de primeira classe parece o caminho errado
  • Se foi escrito por IA ou não, isso não importa muito. O que importa é se foi bem escrito ou mal escrito