Guia para quem odeia Kubernetes

Um guia crítico sobre Kubernetes

• Kubernetes ganhou a reputação, entre alguns profissionais técnicos, de ser desnecessariamente complexo e uma perda de tempo, e seu uso por equipes pequenas é visto como excesso de engenharia.
• Na Jamsocket, após alguns anos operando Kubernetes em produção, eles encontraram uma forma eficiente de usá-lo: utilizar apenas os recursos necessários e ignorar o restante.

Por que usar Kubernetes

• Kubernetes é o caminho mais consolidado quando você quer estas três coisas ao mesmo tempo:
  • Executar vários processos/servidores/tarefas agendadas.
  • Executá-los com redundância e distribuir a carga.
  • Configurar, em código, suas definições e relações mútuas.
• Kubernetes é uma camada de abstração que permite tratar um conjunto de computadores como se fosse um único computador sem cabeça (headless).
• A Jamsocket faz deploy várias vezes por dia, e quando há um problema no produto, o produto dos clientes também é afetado; por isso, eles ganham confiança para fazer deploys frequentes por meio de rolling deploys.

Como usam Kubernetes

• A Jamsocket é um serviço que cria processos dinâmicos capazes de se comunicar com apps web, semelhante ao AWS Lambda, mas a vida útil do processo depende de uma conexão WebSocket, e não de uma única requisição/resposta.
• Kubernetes é usado para operar processos de longa duração, como servidor de API, registro de contêineres, controladores, coletores de logs, alguns serviços de DNS e coleta de métricas.
• O que eles não usam no Kubernetes: processos temporários, sites estáticos/de marketing e qualquer coisa que armazene dados diretamente.
• Eles usam o Google Kubernetes Engine para terceirizar a gestão do Kubernetes, e, se necessário, a migração para o Amazon EKS é relativamente simples.

Recursos do Kubernetes usados ativamente

• Deployments: a maioria dos pods é criada por meio de deploys.
• Services: usam ClusterIP para serviços internos e LoadBalancer para serviços externos.
• CronJobs: usados para scripts de limpeza e afins.
• ConfigMaps e Secrets: usados para passar dados aos recursos acima.

O que usam com cautela

• Eles usam StatefulSet e PersistentVolumeClaim, mas preferem armazenar dados importantes em serviços gerenciados fora do Kubernetes.
• Evitam RBAC sempre que possível, porque isso adiciona complexidade.

O que evitam ativamente

• Escrever YAML manualmente: usam TypeScript e Pulumi para gerar as definições de recursos do Kubernetes.
• Recursos não padronizados e operadores: permitem que softwares de terceiros usem a infraestrutura do Kubernetes, mas na prática são difíceis de usar.
• Helm: não usam por causa dos operadores e das convenções de YAML.
• Tudo que tenha "mesh" no nome: consideram desnecessário.
• Recursos de Ingress: evitam adicionar indireção desnecessária.
• Replicar toda a stack de k8s localmente: usam Docker Compose ou scripts próprios para iniciar apenas as partes necessárias do sistema.

Pessoas não deveriam esperar por um Pod

• Kubernetes foi projetado com foco em robustez e modularidade, mais do que em tempo de inicialização de contêineres, e não é adequado para casos em que uma pessoa precisa esperar o pod iniciar.
• A Jamsocket usa o Plane, um orquestrador em Rust sob licença MIT, para agendar e executar rapidamente processos para cargas de trabalho interativas.

Abstrações de nível mais alto

• Algumas alternativas ao Kubernetes são muito boas, especialmente quando não é necessário definir a infraestrutura como código.
• Também é possível escolher outras soluções no lugar do Kubernetes usando serviços como Railway, Render e Flight Control.
• Se você gerenciar sua abordagem ao Kubernetes de forma sistemática, ninguém poderá dizer que é cedo demais.

Opinião do GN⁺

• Kubernetes é uma ferramenta poderosa para gerenciar complexidade e automação, especialmente em sistemas de grande escala, mas sua complexidade pode ser um fardo para projetos menores ou startups.
• Este texto ajuda iniciantes e equipes pequenas a aproveitar os benefícios do Kubernetes ao mostrar como evitar a complexidade excessiva que pode surgir ao usá-lo.
• Antes de usar Kubernetes, é preciso considerar os recursos realmente necessários e a capacidade técnica da equipe, avaliando cuidadosamente os benefícios em relação à complexidade e ao custo de gestão.
• Em vez de Kubernetes, pode ser melhor usar serviços mais simples e fáceis de gerenciar. Por exemplo, Docker Swarm, Apache Mesos e Nomad, cada um com seus próprios prós e contras.
• Ao adotar Kubernetes, é preciso considerar a integração com a infraestrutura existente, segurança, custos de gestão e curva de aprendizado.
• Os benefícios de escolher Kubernetes incluem escalabilidade, alta disponibilidade e uma experiência de deploy consistente em diferentes ambientes de nuvem. No entanto, isso exige entendimento sobre gestão de recursos e orquestração.

[GN⁺]

Comentários no Hacker News

• Resumo do primeiro comentário:

  • Ao adotar sistemas complexos como Kubernetes, essa complexidade continua se expandindo, com vários componentes reforçando uns aos outros e passando a ser vistos como indispensáveis.
  • Quando a nuvem surgiu pela primeira vez, as pessoas se sentiram atraídas por reduzir a complexidade do balanceamento de carga e do gerenciamento de bancos de dados.
  • Servidores de aplicação stateless não eram um grande problema de manutenção, mas a evangelização dos microsserviços criou problemas que antes não existiam.
  • Agora essa cultura já se consolidou, e fica difícil simplesmente acenar em concordância com a ideia de que microsserviços são obrigatórios.

• Resumo do segundo comentário:

  • Como alguém que implementa Kubernetes em pequenas e médias empresas, houve engenheiros insatisfeitos, mas a maioria respondeu que está satisfeita.
  • Kubernetes é complexo, mas é uma ferramenta para problemas complexos.
  • Ter um padrão é melhor do que um caos simples não documentado, e argumenta-se que kubectl explain X é muito melhor do que a documentação da AWS.
  • Kubernetes é complexo, mas funciona exatamente da mesma forma que os desenvolvedores usavam em empregos anteriores, e velocidade importa.

• Resumo do terceiro comentário:

  • Criticar Kubernetes está na moda, mas ele ainda é a melhor solução.
  • Ele permite definir a infraestrutura de forma declarativa e oferece balanceamento de carga, autorrecuperação e escalabilidade.
  • Fornece excelente observabilidade para toda a stack, e há muito software pré-empacotado disponível.
  • É possível construir praticamente a mesma infraestrutura na nuvem, em servidores próprios e em ambiente local, sem ficar preso a um provedor específico de nuvem.

• Resumo do quarto comentário:

  • As grandes vantagens do Kubernetes são Helm e Operators.
  • Se você vai pagar o custo da complexidade, então deveria obter em troca a vantagem de uma “app store” de componentes de infraestrutura e da possibilidade de gerenciar operações de forma programática.
  • Por exemplo, para configurar algo complexo como Ceph, Rook é uma boa abordagem.
  • Helm e Operators não transformam a infraestrutura em appliances gerenciados do tipo “turnkey”, mas interfaces declarativas em geral são melhores de administrar.

• Resumo do quinto comentário:

  • Kubernetes é uma boa tecnologia, mas sua complexidade tende a transformar os mantenedores nos heróis da empresa.
  • Muitos ajustes finos e alavancas podem desviar o foco do objetivo real do projeto.

• Resumo do sexto comentário:

  • A empresa atual está dividida entre Kubernetes e um sistema de deploy customizado baseado em Ansible.
  • A abordagem com Ansible funciona bem, mas migrar para Kubernetes pode reduzir o tempo de deploy de horas para minutos e permitir autoscaling de forma mais rápida e eficiente.
  • A dificuldade de descobrir por que um deploy com Helm falhou e a necessidade de aprender uma nova forma de operar são feedbacks consistentes ouvidos de equipes anteriores.

• Resumo do sétimo comentário:

  • Em uma conversa com um ex-engenheiro de confiabilidade de sites do Google, foi dito que dá para contar nos dedos as empresas que realmente precisam de Kubernetes.
  • Muitas pessoas tendem a desenvolver seguindo a moda do momento.

• Resumo do oitavo comentário:

  • Kubernetes pode ser a ferramenta certa, mas deve ser aceito como um mal necessário.
  • Softwares que podem falhar em colaborar por causa de falhas de várias partes frequentemente causam problemas.

• Resumo do nono comentário:

  • Escrever YAML manualmente pode ser um problema, então, em vez disso, usa-se TypeScript e Pulumi para gerar definições de recursos do Kubernetes.
  • Em vez de fazer lint em YAML, introduz-se todo um runtime de linguagem de programação e bibliotecas de terceiros, assumindo também complexidades extras como manutenção de versões e compilação do projeto.

• Resumo do décimo comentário:

  • Como alguém que já teve entusiasmo por Kubernetes, as boas partes dele são os blocos básicos (deployments, services, configmaps), e o resto deve ser usado apenas em situações especiais.
  • A equipe prefere escrever YAML puro e usar kustomize para manter a configuração clara e explícita.