Por que um cluster muda a pergunta

Tudo nesta série até aqui nomeou máquinas. A configuração do Kamal diz hosts: [203.0.113.10], e foi você quem decidiu que esta aplicação roda naquele servidor. Quando o servidor lota você acrescenta uma linha, e quando o servidor cai você descobre e age.

O Kubernetes remove a linha. Você para de dizer onde e passa a dizer o quê:

replicas: 3

Três cópias desta aplicação devem estar rodando em algum lugar do cluster, em nenhuma máquina específica. Decidir onde agora é trabalho de outro, e esse outro é software.

O laço de reconciliação

Esta é a ideia central. Todo o resto do Kubernetes decorre dela.

Você escreve uma descrição do estado que quer e a entrega ao API server. Um conjunto de controllers compara continuamente essa descrição com o que está rodando, e toma qualquer ação que feche a diferença. Ninguém executa as suas instruções, porque você escreveu uma descrição, e não uma lista de passos.

flowchart LR
  Y["Seu YAML: estado desejado"] --> A["API server"]
  A --> S[("etcd")]
  C["Controllers"] --> A
  C --> D{"desejado == atual?"}
  D -->|"não"| ACT["criar / apagar / reagendar"]
  ACT --> N["nodes rodando seus containers"]
  N --> C
  D -->|"sim"| W["não faz nada"]

O node de um pod pega fogo. O atual agora é dois, o desejado é três, e algo inicia um terceiro em outro lugar, sem humano no laço. Essa é a propriedade que as pessoas estão comprando.

É também por isso que "apaguei o pod e ele voltou" é a primeira coisa que todo mundo aprende do jeito difícil. Você não apagou nada que importe para o cluster. Você mexeu no estado atual, e o laço te corrigiu.

As peças, em resumo

Um node é uma máquina, e o control plane é o conjunto de peças acima dele. Num cluster gerenciado (EKS, GKE, AKS), você aluga o control plane e nunca o vê. Isso remove a parte mais difícil de rodar Kubernetes e deixa a segunda mais difícil com você.

O custo honesto

Este curso ensina Kubernetes, então começa dizendo quando não usá-lo.

O setup Kamal de dois cursos atrás tem cerca de sessenta linhas de YAML e um comando. O setup equivalente em Kubernetes é um Deployment, um Service, um Ingress, um ConfigMap, um Secret, probes, requisições de recursos e uma estratégia de rollout: várias centenas de linhas em vários arquivos. Some a isso um cluster para rodar tudo, e alguém que saiba o que significa um CrashLoopBackOff às 3 da manhã.

Essa troca vale quando você tem alguns destes:

• Mais aplicações do que um time consegue colocar em máquinas à mão.
• Tráfego que precisa de autoescala em vez de um número que você definiu na terça.
• Um requisito de que uma máquina perdida se conserte sem pessoa nenhuma.
• Uma organização que já roda um cluster, onde ficar de fora custa mais que ficar dentro.

"Empresas sérias usam" não é motivo para fazer essa troca. Uma aplicação Rails num servidor bem configurado com Kamal serve um volume enorme de tráfego, e muitos times migraram para Kubernetes e ficaram mais lentos.

Já a capacidade de ler isso sempre vale. Você vai herdar clusters, revisar manifestos e conversar com times de plataforma. É para isso que este curso serve.

O que este curso cobre

1. Por que um cluster muda a pergunta (você está aqui).
2. Pods e Deployments.
3. Services e como o tráfego entra.
4. Configuração e segredos.
5. Saúde, recursos e agendamento.
6. Rodando Rails no Kubernetes.
7. Juntando tudo: um conjunto completo de manifestos.

Pontos-chave

• O Kamal nomeia máquinas; o Kubernetes recebe uma descrição do estado desejado e decide a colocação sozinho.
• O laço de reconciliação (controllers fechando a diferença entre desejado e atual) é a ideia da qual tudo decorre.
• O control plane é API server, etcd, controllers e scheduler; um node roda um kubelet e os seus containers.
• O Kubernetes custa centenas de linhas e um conjunto de habilidades operacionais; isso se paga com muitas aplicações, autoescala real ou exigência de autorreparo.
• Ler manifestos vale a pena mesmo quando rodar um cluster não vale.