Eu não precisei de Kubernetes, e você provavelmente também não vai precisar

Por que deixei o Kubernetes e escolhi o Google Cloud Run

Contexto da adoção do Kubernetes

• Na plataforma online de edição 3D Clara.io, lançada em 2013, a infraestrutura foi otimizada com servidores bare metal, mas isso exigia trabalho excessivo com gerenciamento e monitoramento de hardware.
• Em 2018, no projeto Threekit.com, foi escolhido o Kubernetes. Na época, Azure, AWS e Docker adotavam o Kubernetes como padrão, consolidando-o como tecnologia mainstream.

Limitações do Kubernetes

1. Problemas de custo:

   • O custo básico para montar um cluster é alto, incluindo nós de gerenciamento e configuração redundante do cluster.
   • Como o autoscaling é lento, é necessário superprovisionar os serviços, o que gera custo com recursos ociosos.

2. Dificuldade para gerenciar workloads:

   • O agendamento de tarefas é complexo, e tanto o scheduler embutido quanto o Argo são ineficientes para grandes volumes de trabalho.

3. Sobrecarga de complexidade:

   • O conjunto rico de funcionalidades torna complexas até tarefas simples.
   • É preciso ter pessoal de DevOps dedicado para administrar o Kubernetes, o que aumenta os custos.

Migração para o Google Cloud Run

O Cloud Run substitui a complexidade do Kubernetes por um ambiente simplificado e com melhor eficiência de custo.

Nova configuração

• Infraestrutura baseada em contêineres Docker:
  • Inclui contêineres para serviços com autoscaling e para tarefas de longa duração.
  • O Cloud Run automatiza deploy de contêineres, escalonamento, gerenciamento de indisponibilidade e execução de tarefas.

Vantagens do Cloud Run

1. Eficiência de custo:

   • A cobrança é feita com base no tempo de uso de CPU e memória.
   • Serviços ociosos não geram custo.
   • Exemplo: o site Web3D Survey consegue operar por US$ 4/mês processando 500.000 acessos mensais.

2. Autoscaling rápido e estável:

   • O escalonamento acontece em segundos, mais rápido que no Kubernetes.
   • Isso permite lidar rapidamente com picos de demanda.

3. Sem a carga de gerenciar Kubernetes:

   • O Cloud Run é baseado no Borg, do Google, dispensando o gerenciamento de clusters Kubernetes.

4. Tarefas assíncronas simples:

   • Com Cloud Run Tasks, é fácil executar grandes volumes de trabalho com retry automático.

Problema potencial do Kubernetes: lock-in no cluster

• Depender de funcionalidades do Kubernetes dificulta a integração com recursos externos ao cluster e limita a expansão.
• Isso pode criar dependência de uma infraestrutura específica, tornando expansão e migração mais complexas e caras.

Perguntas comuns sobre usar Cloud Run

“Você não se preocupa com dependência de GCP?”

• Como a configuração é baseada em Docker, a migração para outra nuvem, como a AWS, pode ser feita em cerca de uma semana.
• Na prática, fora fatores políticos, é raro trocar de provedor de nuvem.

“No fim das contas, o Cloud Run não é Kubernetes gerenciado?”

• O Cloud Run usa a interface do Knative, mas roda sobre o Borg do Google, e não sobre Kubernetes.
• Ele elimina a complexidade do Kubernetes e oferece uma interface simplificada.

Desvantagens do workflow atual

1. Inconveniência no gerenciamento de nomes de serviço:

   • É necessária uma camada de abstração para manter uma configuração consistente entre ambiente local e servidor.
   • Falta a funcionalidade de gerenciamento de nomes que o Kubernetes oferece.

2. Falta de emulação de Cloud Run Task:

   • Ao desenvolver tarefas localmente, não existe um ambiente simples de emulação que capture e rastreie a saída de logs.

Conclusão

• O Cloud Run é a solução ideal em termos de custo, velocidade, escalabilidade e simplicidade
• Para grandes empresas ou casos com requisitos complexos, o Kubernetes pode ser útil, mas
• Em projetos em que simplicidade e eficiência são importantes, o Cloud Run é muito mais prático
• PS: Talvez fosse possível resolver esses problemas adicionando extensões específicas ao Kubernetes, mas isso só aumentaria a complexidade, e não quero depender de um ambiente Kubernetes que vai além de necessidades simples.

[blurblah]

Não existe bala de prata. O importante é usar bem de acordo com a situação, né? haha
Se adotarem Kubernetes sem senso crítico só porque é algo da moda, isso pode acabar tornando tudo mais difícil, mas ainda assim acho que é uma ferramenta boa em ambientes de escala um pouco maior.
Mesmo que façam a adoção, se parar só na adoção e acabar aí, provavelmente não vão conseguir usar direito.
E, como acontece com qualquer ferramenta, ela não consegue atender 100% das necessidades dos desenvolvedores ou dos usuários, então acho que um nível adequado de automação é indispensável.

[bungker]

Eu não precisava de Kubernetes, e vocês provavelmente também não precisarão

Depois que o Kubernetes está configurado, só resta curtir a vida... T_T

[riki3]

Kubernetes é o meu ganha-pão, e houve uma época em que eu acreditava que essa era a resposta certa.
Mas, com o passar do tempo, acabei me vendo enfrentando muitos problemas e desperdiçando tempo.

Eu recomendo k8s para os outros, mas acho que não usaria no meu próprio serviço. E, além do k8s, estou cansado até de contêineres em geral.

[joon14]

Se você usa AWS, dá para pensar que é parecido com o ECS?

[tujuc]

Sim, é isso mesmo. :)

[eclipsense]

O problema é não conseguir usar Kubernetes; dizer que Kubernetes é ruim já é um pouco forçado.

[tujuc]

Também penso de forma parecida com a do autor.
Nossa empresa ainda não tem porte para usar kube.

Eu achava que todos os desenvolvedores conseguiriam fazer a gestão usando Kube.
No fim, foi melhor orientar para que fosse possível montar a infraestrutura e resolver problemas de um jeito mais simples do que a média dos desenvolvedores da empresa...

[doolayer]

???: Eu não precisava de IA, e vocês provavelmente também não precisarão.

[ilbanin00]

Qualquer produto terá aspectos que envolvem trade-offs.

[bbulbum]

Como eu usava serviços gerenciados, nunca senti tanta dificuldade com a administração,,
qualquer ferramenta é útil se for usada dentro de um limite adequado, mas no caso do Kubernetes tenho a impressão de que a crítica recorrente é, em especial, o fato de "permitir configurações complexas".

[tujuc]

Como é uma tecnologia com a qual dá para fazer quase tudo do jeito que eu quero... :) Acho que é por isso que muita gente acaba usando de forma complicada kkkkk...

[GN⁺]

Comentários do Hacker News

• Expressa frustração com a “tecnologia de nuvem”, mencionando que, ao usar Kubernetes, acaba gastando muito tempo editando arquivos YAML e resolvendo erros. Defende evitar a integração com a nuvem e configurar os próprios servidores

• Kubernetes gera custos significativos de infraestrutura, além do tempo gasto com DevOps e administração. Sugere que usar o Kubernetes gerenciado do provedor de nuvem é mais eficiente

• Kubernetes não é uma ferramenta de orquestração de contêineres, mas uma ferramenta para criar um cluster de computadores; se você não precisa de um cluster, não precisa usar Kubernetes

• O investimento excessivo em DevOps está diminuindo, e compartilha uma visão crítica sobre Kubernetes. Enfatiza que, em startups pequenas, um único servidor pode ser suficiente

• Ao usar Cloud Run, menciona como pontos de atenção o limite de conexões TCP, a escolha do ambiente de execução e as configurações de autoescalonamento

• Cloud Run é adequado para startups pequenas, mas aponta a falta de controle de firewall, um elemento básico da arquitetura de segurança. Explica que, no fim, será necessário usar uma VPC

• Argumenta que comparar Google Cloud Run com Kubernetes não é justo e explica as vantagens e desvantagens de cada um. Enfatiza que Kubernetes é adequado para trabalhos complexos

• Explica que Kubernetes tem uma curva de aprendizado íngreme, mas é uma ferramenta poderosa quando usada corretamente

• Discorda das críticas ao Kubernetes e enfatiza que, ao implantar aplicativos complexos, a API do Kubernetes pode ser necessária

• Explica que a complexidade do Kubernetes surge principalmente das tarefas de administração de sistemas, e que o próprio Kubernetes é estável

• Aponta que IaC e CM deveriam reduzir a quantidade de configuração e facilitar a administração, mas, na prática, exigem mais esforço. Enfatiza que, em muitos casos, Kubernetes não é necessário e que um bom administrador de sistemas é mais importante