Caro amigo, você construiu um Kubernetes

• Uma carta para um amigo

  • Explica que, embora tenha tentado evitar o Kubernetes, acabou construindo um sistema parecido.
  • O amigo escolheu uma "tecnologia entediante" e queria uma execução simples de contêineres, mas no fim surgiram problemas por causa de scripts e configurações complexas.
  • Mesmo migrando para o Docker Compose, não é possível resolver tudo, e ele percebeu que seriam necessárias soluções separadas para implantação, atualizações contínuas, rollback e escalonamento.

• Expansão de servidores e complexidade de rede

  • Surge a necessidade de expandir para um segundo servidor.
  • Tenta usar uma rede overlay como o Tailscale para descoberta de serviços.
  • Esforça-se para resolver a complexidade da rede, mas acaba enfrentando ainda mais problemas.

• Manutenção e automação

  • Surge a pergunta: se a pessoa que criou os scripts entrar de férias ou sair da empresa, quem vai gerenciar as configurações complexas e as mudanças de configuração não documentadas?
  • Para resolver os problemas de manutenção dos scripts customizados, usa o Ansible para tornar as VMs imutáveis e versionáveis.
  • Acredita que, por não usar Kubernetes, será mais fácil fazer a manutenção.

• Criação de contêineres e problemas de segurança

  • Aparece a necessidade de criar programaticamente outros contêineres.
  • Como montar o socket do Docker em uma aplicação web é um risco de segurança, ele escreve um serviço separado para resolver isso.
    • Resolve o problema criando um serviço separado que expõe apenas a parte segura da API do Docker.

• Conclusão

  • No fim, percebe que acabou construindo um sistema semelhante ao Kubernetes.
    • Conclui um sistema complexo que inclui formato padrão de configuração, método de implantação, rede overlay, descoberta de serviços, nós imutáveis e servidor de API

• PS

  • Isso não significa negar a possibilidade de existirem soluções melhores para substituir o Kubernetes.
  • Ainda assim, recomenda entender bem os problemas que ele tenta resolver antes de concluir que o Kubernetes é simplesmente complexo.

[savvykang]

Não entendo muito bem essa ideia de adotar o Kubernetes para resolver a transferência de implantação.

[kandk]

A manutenção e a automação podem ser feitas facilmente em nível de código.
Infra as code também é possível.

[savvykang]

Em ambientes de serviços gerenciados de k8s como o EKS, há load balancer e também é possível integrar com o Route 53, mas no k8s self-hosted não há implementação de load balancer e a integração com DNS também é limitada. Em empresas que têm uma equipe dedicada só para administrar k8s, as vantagens que você mencionou podem realmente ser válidas.

À primeira vista parece uma solução razoável, mas quando você realmente usa, ela não funciona em todas as situações.

[kandk]

É fácil de usar mesmo sem uma equipe para gerenciar o k8s. Basta usar o EKS.

[savvykang]

Não é basicamente a mesma alegação de que, se você entregar só o código-fonte, a transferência de conhecimento está concluída? Ainda parece que o manual de trabalho e o histórico de execução das tarefas continuam sendo necessários.

[kbumsik]

Infra as Code em si existe justamente para tentar resolver tudo só entregando o código-fonte.
Ah, claro, como com qualquer código, a documentação básica precisa existir.

[kandk]

É possível se o código-fonte estiver bem escrito e a documentação for boa.
Ter um manual de trabalho e um histórico de execução das tarefas separados ajudaria, mas isso parece ser outra história, diferente deste texto.

[GN⁺]

Comentários do Hacker News

• Já houve experiências bem-sucedidas de deploy em várias empresas usando scripts de shell

  • Com dois serviços PHP, era possível processar mais de 1 bilhão de requisições por dia e fazer deploy sem downtime enviando arquivos para os servidores e executando migrações
  • Em setores que não precisam de escala web, como contas de aposentadoria, os deploys eram feitos via comandos Docker pelo Jenkins
  • Era possível disponibilizar ambientes de teste sob demanda em poucos minutos
  • A empresa atual está tentando adotar Kubernetes, mas enfrenta dificuldades por causa da complexidade

• Kubernetes exige duas ou três pessoas dedicadas só para gerenciar arquivos YAML

  • Escolher um provedor de nuvem pode resolver as partes complexas, mas isso gera custo adicional
  • Arquivos YAML são arquivos de configuração que não deveriam ser escritos por pessoas, e sim gerados por ferramentas
  • A maioria dos sites e serviços não precisa de Kubernetes

• A ideia de que o simples é frágil está errada

  • É mais difícil entender e depurar a complexidade dos arquivos YAML e do Kubernetes
  • Uma alternativa ao Kubernetes são scripts de shell

• Há casos em que Kubernetes não é necessário

  • Com instâncias EC2 e scripts de shell simples, é possível lidar com mais de 100.000 usuários simultâneos
  • Se não há problema, não há motivo para mudar

• Com scripts de shell, dá para gerenciar facilmente regras de iptables e editar sysctl

  • Em vez de criar contêineres de forma programática usando uma fila de tarefas, é possível simplesmente enviar as tarefas para a fila

• Criticar Kubernetes é visto como algo pouco profissional

  • Se não for uma aplicação de grande escala como as do Google ou da Netflix, é melhor escrever scripts simples

• É errado supor que todas as limitações de sistemas feitos em casa são custo, e que toda a flexibilidade de soluções genéricas é uma vantagem

  • Você quer seguir padrões semelhantes no codebase e que os serviços sejam implantados da mesma forma

• O problema do Kubernetes é que inúmeras bibliotecas open source tornam o sistema difícil de entender e causam bugs

• Quem já passou da curva de aprendizado do Kubernetes diz que a complexidade não é tão ruim

  • Um treinamento para ensinar Kubernetes a desenvolvedores leva cerca de 30 minutos e permite que eles escrevam charts do Helm