Se você já pesquisou sobre Kubernetes, provavelmente encontrou diagramas cheios de Pods, Services, Deployments, ConfigMaps e dezenas de comandos. A impressão que fica é a de que estamos diante de uma tecnologia extremamente complexa.
Muita gente começa a estudar decorando nomes, recursos e comandos. Mas existe um problema, é difícil entender a utilidade de cada um deles quando ainda não sabemos qual problema o Kubernetes foi criado para resolver.
Na minha opinião, esse é o maior obstáculo para quem está começando. Quando chegamos no entendimento da necessidade que deu origem ao Kubernetes, conceitos como Pods, Deployments e Services deixam de parecer peças soltas e passam a fazer sentido.
Antes do Kubernetes
Imagine uma API rodando em produção. Tudo está funcionando normalmente até que um dia:
- A aplicação consome toda a memória
- O processo encerra inesperadamente
- O servidor reinicia
- A quantidade de acessos aumenta muito além do esperado
Agora alguém precisa perceber o problema, acessar o servidor e colocar a aplicação de volta no ar. Se ela estiver em um container, será necessário iniciar o container novamente. Esse modelo funciona bem para aplicações pequenas, mas conforme o sistema cresce, manter tudo de forma manual deixa de ser viável.
O Docker resolveu um problema
O Docker resolveu um dos maiores problemas do desenvolvimento, garantir que uma aplicação seja executada da mesma forma em qualquer ambiente. Pense no Docker como a ferramenta responsável por colocar sua aplicação para rodar dentro de um container.
O mesmo container pode ser executado no notebook do desenvolvedor, em um servidor de testes ou em produção. A partir dele ficou muito mais fácil disponibilizar software sem se preocupar com diferenças entre servidores.
Mas existe uma diferença importante entre executar um container e garantir que ele continue disponível.
Então onde entra o Kubernetes?
O Kubernetes não foi criado para executar containers. Ele foi criado para administrar containers. Essa diferença muda completamente a forma de enxergar a ferramenta. O Kubernetes fica observando constantemente o estado desejado da aplicação.
Por exemplo:
Quero três instâncias da minha API funcionando.
Se uma delas cair...
O Kubernetes cria outra.
Sem intervenção humana.
Um exemplo simples
Imagine um restaurante. O Docker seria um cozinheiro e o Kubernetes seria o gerente.
O Kubernetes verifica:
- Falta cozinheiro?
- Entrou muita gente?
- Alguém ficou doente?
- Precisamos contratar mais pessoas?
O gerente reorganiza tudo para manter o restaurante funcionando.
Por que existem Pods?
Essa é uma dúvida comum de quem está começando. O Kubernetes não gerencia containers diretamente. Ele gerencia Pods. Um Pod representa uma unidade de execução. Na maioria das aplicações um Pod contém apenas um container. Mas nada impede que um Pod possua dois ou mais containers trabalhando juntos.
Então por que não subir vários containers manualmente?
Você até pode. Mas imagina precisar controlar:
- Disponibilidade
- Escalabilidade
- Atualizações
- Reinicializações
- Balanceamento
- Configuração
- Segredos
Fazer isso manualmente rapidamente se torna inviável. É exatamente aí que o Kubernetes começa a entregar valor.
Os principais componentes deixam de parecer mágicos
Depois que entendemos o objetivo do Kubernetes, cada recurso ganha um propósito.
Deployment
Mantém a quantidade desejada de Pods em execução.
"Quero sempre três réplicas da minha aplicação."
Service
Fornece um ponto único de acesso aos Pods.
"Independentemente de quantos Pods existam, quero um único endereço para acessá-los."
ConfigMap
Centraliza configurações.
"Não quero recompilar minha aplicação sempre que mudar uma configuração."
Secret
Protege informações sensíveis.
"Credenciais não devem ficar dentro da imagem."
Horizontal Pod Autoscaler
Escala automaticamente.
"Quando a carga aumentar, crie novas réplicas."
Conclusão
Na minha opnião o maior obstáculo para aprender Kubernetes é tentar decorar conceitos antes de entender os problemas que eles resolvem.
Quando enxergamos o Kubernetes como um sistema que mantém aplicações funcionando e não apenas como uma ferramenta para subir containers, os Pods, Deployments, Services e outros recursos deixam de parecer complexos.
Eles passam a representar soluções para problemas que toda aplicação em produção inevitavelmente enfrenta.