Kubernetes — O técnico dos containers
Anteriormente eu fiz um post com uma visão “Big picture” sobre containers, agora vamos descrever esta mesma visão de resumo para Kubernetes. Para ter uma visão macro, nada melhor que comparar com algo do mundo real. Então para exemplificar, vamos falar de futebol — quem me conhece pessoalmente sabe que este é um assunto que não é minha praia, mas é só para o exemplo :) .
No mundo real, um time de futebol é formado por indivíduos, cada um com diferentes habilidades e papéis para cumprir. Alguns ficam na defesa, alguns fazem meio de campo, outros são melhores no ataque, outros são bons para bater o pênalti. Enfim, um time tem um conjunto de jogadores com diferentes habilidades. E é aí que entra o técnico, a pessoa responsável por dar a todos uma posição, uma missão, coordenar o time como uma unidade organizada. Além disso, o técnico também é responsável por cuidar das condições do time, substituindo jogadores quando os mesmos são lesionados. Usando essa analogia e comparando com o mundo Kubernetes, podemos pensar que o técnico é que chamamos de Master e os jogadores são os Nodes.
Acabei me precipitando um pouco falando sobre Master e Nodes, para entender melhor devemos falar antes de…
Cluster
O Kubernetes coordena um cluster de alta disponibilidade, com máquinas (físicas ou virtuais) que estão conectadas para trabalhar como uma unidade única. Conforme é possível observar na Figura 1, um cluster Kubernetes é composto por um Master e um conjunto de Nodes.
O Master gerencia todas as atividades do cluster, como por exemplo, gerenciar o agendamento de aplicações, manter o estado desejado das aplicações, escalar as aplicações e efetuar atualizações.
O Node — anteriormente conhecido como minion — funciona como um worker dentro do cluster. Ou seja, ele recebe ordens do Master e fica responsável pelo funcionamento das aplicações. Conforme é possível notar na Figura 2, dentro de um Node, existem vários Pods.
Um Pod é um grupo de um ou mais containers com armazenamento e rede compartilhados entre si. Os Pods — assim como os Nodes — são mortais, isso significa que a qualquer momento podem morrer e o próprio Kubernetes se responsabiliza por subir outro no lugar. Na Figura 2 é possível notar que cada Pod possui um IP único. Dito isto, sabemos que cada Pod criado terá um IP diferente. Fica evidente a necessidade de uma funcionalidade para conciliar as mudanças entre os Pods e seus IPs, de modo que a aplicações continuem funcionando. É para suprir esta necessidade que existem os …
Services
Um Service é uma abstração que define um conjunto de Pods e uma política de acessos para os mesmos. O Service permite o desacoplamento entre os Pods dependentes. Deste modo, caso um Pod morra os dependentes continuarão possuindo acesso ao novo substituto.
Para exemplificar melhor, observemos a Figura 3. Existe o Service A — o front-end da nossa aplicação — e o Service B — o back-end da aplicação. Note que o Service do back-end possui dois Nodes e três Pods — cada um com um IP diferente — , se retirássemos a abstração do Service B, como a aplicação front-end reconheceria o back-end?
O Service permite abstrair de modo que o front-end conhece somente o IP do Service do back-end. Isso possibilita que os Pods do back-end sejam substituídos por novos sem afetar o funcionamento da aplicação.
E o que mais?
O que nós falamos aqui, não é nem o inicio da brincadeira, existe muito chão para percorrer ainda. O propósito deste post era expor uma versão super simplificada da plataforma. Caso queira continuar os estudos — e eu espero que sim :D — , os tutoriais oficiais do Kubernetes é um ótimo lugar para começar.
Em um futuro breve, pretendo fazer um post falando sobre minha experiencia configurando o Kubernetes para testes em minha máquina local.
Se quiser trocar uma ideia ou entrar em contato comigo, pode me achar no Twitter (@e_ferreirasouza) ou Linkedin.
Grande abraço e até a próxima!
