O caso
Doze serviços e um que sempre cai. Quem reinicia o container às três da manhã?
A loja do Isaac cresceu. Pedidos, estoque, pagamentos, notificações e o painel do contador viraram doze containers. Cada um precisa de cópias rodando ao mesmo tempo, de um reinício quando trava e de um jeito de encontrar os outros.
Numa madrugada, o serviço de estoque travou. Ninguém percebeu até a manhã seguinte, porque ninguém estava olhando.
Este post parte de Containers na Nuvem e de Serverless e Cloud Run. No Cloud Run, o Google decide quando o container roda. Aqui, a equipe decide o que roda, em quantas cópias, e como as partes se encontram.
O problema
Um container sozinho não cuida de si
Subir um container é fácil. Mantê-lo de pé é outra história:
- Reinício: se o processo trava, alguém precisa perceber e subir de novo.
- Cópias: para aguentar o movimento, é preciso rodar várias cópias e distribuí-las pelas máquinas.
- Endereços: quando um container é recriado, o endereço dele muda, e quem depende dele quebra.
A solução
Kubernetes: a equipe descreve, o sistema executa
O Kubernetes (ou K8s) é um sistema de orquestração de containers. Você declara o estado que quer, por exemplo "três cópias do serviço de pedidos sempre no ar", e ele trabalha para manter esse estado. Se uma cópia cai, ele cria outra. Se uma máquina some, ele move as cópias para outra.
É como pedir ao gerente da loja que tenha três caixas abertos a qualquer hora. Você não escolhe quem chama para cobrir a falta; ele cuida disso e avisa só quando não consegue.
Três objetos
Pod, Deployment e Service
Pod
A menor unidade do Kubernetes: um ou mais containers que rodam juntos e dividem o mesmo endereço.
Na loja: o container do serviço de estoque, com o seu coletor de logs ao lado.
Deployment
Declara quantas cópias de um pod devem existir, e recria as que caem.
Na loja: três cópias do serviço de pedidos, sempre.
Service
Um endereço estável para chegar aos pods, mesmo quando eles são recriados.
Na loja: o endereço "pagamentos", que o serviço de pedidos chama sem saber em qual máquina o pagamento está.
Não confunda
GKE Autopilot × GKE Standard
O GKE (Google Kubernetes Engine) é o Kubernetes gerenciado do Google Cloud. Nos dois modos, o Google cuida do control plane, o cérebro do cluster. A diferença está em quem cuida dos nós, as máquinas onde os pods rodam.
GKE Autopilot
“Quem gerencia os nós?”
- Exemplo
- O Google. A equipe define os pods e os recursos que cada um pede, e não cria nem configura as máquinas.
- Foco
- Paga pelos recursos pedidos pelos pods. É o modo que o Google recomenda.
GKE Standard
“Quem gerencia os nós?”
- Exemplo
- A equipe escolhe o tipo de máquina, o tamanho e a quantidade de nós.
- Foco
- Mais controle sobre a infraestrutura, e mais trabalho para mantê-la.
Por baixo
Cluster, nós e pods
Um cluster é o conjunto do control plane com os nós. Os nós são máquinas virtuais, como as do Compute Engine, e cada pod é agendado num nó com espaço livre. O control plane decide onde cada pod roda e observa se o estado declarado está sendo cumprido.
Quando o tráfego sobe, o número de pods pode crescer automaticamente. Se os nós não têm espaço para eles, o cluster precisa de mais nós. No Autopilot, o Google cuida disso; no Standard, a equipe configura esse comportamento.
Na prática
O que a loja precisa, e como resolver
| O que a loja precisa | Como resolver |
|---|---|
| Três cópias do serviço de pedidos sempre no ar | Deployment com três réplicas |
| Reiniciar o estoque quando ele trava | O Kubernetes recria o pod que falhou |
| Chamar o pagamento pelo nome, não pelo endereço | Service |
| Mais pedidos à noite, menos de manhã | Escalonamento automático dos pods, e dos nós quando faltar espaço |
| Ninguém quer administrar máquinas | GKE Autopilot |
Termos-chave
Cinco termos para fixar
Toque no cartão para ver a definição.
Teste rápido
Três perguntas, estilo prova
01
A equipe quer rodar containers em Kubernetes sem administrar as máquinas. Qual modo do GKE atende melhor?
02
Um serviço precisa manter três cópias de um container sempre no ar, recriando as que caírem. Qual objeto do Kubernetes faz isso?
03
Qual afirmação sobre o GKE é verdadeira?
O Kubernetes não substitui o container: ele decide onde e quantas cópias rodam. Com o GKE, o Isaac deixa de acordar de madrugada por causa do estoque, e a equipe passa a olhar para o que a loja precisa, e não para cada máquina. O próximo passo da trilha é a segurança: quem pode acessar cada serviço.