Para entender, precisamos saber o que é uma imagem Docker e um container...

Basicamente, quando falamos de um container no meio da programação e DevOps, falamos de um ambiente totalmente isolado de onde ele está, podendo ser sua máquina local ou um servidor. Um container contém uma imagem, que é basicamente suas configurações. Por exemplo, quando falamos que temos um container com uma imagem php:8.2, quer dizer que temos um container que dentro dele temos o PHP, rodando provavelmente em um Ubuntu, exatamente como nossa máquina local quando instalamos o PHP nela.

Aí que entra o Kubernetes. Imagine que, em vez de termos um container de php:8.2, teríamos um container com a imagem do nosso sistema, tipo meu-sistema:1.0, tendo todas as configurações e dependências encapsuladas em um container. O Kubernetes serve para usarmos esses containers de imagens criadas a partir do nosso sistema de forma escalável, otimizada e auto-gerenciável. Imagine rodar 4 containers idênticos, sendo orquestrados pelo Kubernetes, já com um balanceador de carga para direcionar o tráfego para cada container. Legal, não é? Mas como funciona?

Arquitetura do Kubernetes

Para simplificar, podemos entender a arquitetura do Kubernetes em 3 partes.

Node

Os nós (nodes) são as máquinas onde os contêineres são realmente executados. Cada nó é responsável por executar os pods (Nosso sistema, por exemplo). Um cluster Kubernetes pode ter vários nós, criando assim a capacidade de escalabilidade.

Pods

Os pods são a unidade básica de implantação no Kubernetes. Eles podem conter um ou mais contêineres que compartilham o mesmo espaço de rede e armazenamento, tornando-os ideais para aplicativos intimamente relacionados (aqui estamos falando de containers que podem conter um banco de dados, por exemplo, tipo mysql:2.0, que se conectam com o container meu-sistema:2.0, por exemplo).

Services (serviços) e Ingress

Os serviços são recursos que permitem a comunicação entre os pods. Eles fornecem uma abstração de rede estável e um balanceamento de carga para garantir que os aplicativos sejam acessíveis e escaláveis. O Ingress, por outro lado, permite que o tráfego externo seja roteado para serviços específicos dentro do cluster, ele basicamente deixa nosso sistema acessível publicamente, e quando o Ingress recebe uma requisição de um host, por exemplo, meu-sistema.com.br, ele irá direcionar para o serviço que nosso pod do sistema está rodando.

Fluxo de trabalho

Basicamente, essas são as ferramentas necessárias para um "Kubernetes Básico", mas agora como isso fica no dia-a-dia? Primeiro de tudo, temos que ter uma imagem do nosso projeto, utilizando o Docker e um Dockerfile. Basicamente, no Dockerfile, a gente simula todo o fluxo de instalação de dependências, banco de dados, etc., tipo um script, que o Docker irá usar para montar o container. Depois disso, a ideia é que cada versão nova do nosso sistema tenha uma imagem, com o nome correto, tipo meu-sistema:1.0 e meu-sistema:2.0, assim sucessivamente. Depois disso, começamos a jogar essa imagem para dentro do nosso Kubernetes, e com as configurações corretas, o Kubernetes irá subir pods, que irão conter os containers da nossa aplicação e disponibilizar ela. (Nesse momento, nosso Kubernetes está rodando em algum servidor ou cluster, mas não se preocupe em como isso rola, só pegue bem como o Kubernetes trabalha)

O que vai jogar a imagem para dentro do Kubernetes?

O que irá jogar as imagens dos containers do nosso sistema para dentro do Kubernetes são os arquivos .yaml, que irão conter as configurações do Kubernetes. Podemos dividir em 2 arquivos para entendermos melhor, vamos chamar esses arquivos de deployment.yaml e ingress.yaml.

deployment.yaml

Esse arquivo é responsável por criar o Service do nosso sistema, que irá abrir uma porta dentro do Kubernetes, para que nosso Ingress saiba onde direcionar os usuários que acessarem o host meu-sistema.com.br. Quando falamos de Kubernetes, nós conseguimos realizar apontamentos em Services, utilizando o Ingress, em vez de apontamento de IPs.

Logo após a criação do Service, iremos criar as configurações de deployment, ou deploy, que de fato irá criar os pods com os containers contendo as imagens do nosso projeto. É nessa configuração que iremos colocar quantos pods serão criados do mesmo software, configurações de servidor, volume de dados, etc., mas vamos focar no básico. Aqui embaixo temos um exemplo de um arquivo deployment.yaml, apenas para contextualizar, vamos entrar mais a fundo no que é cada configuração no próximo blog :).

ingress.yaml

O Ingress é o cara que vai estar no topo do nosso Kubernetes, e ele que irá receber os acessos vindos de usuários que acessam nosso sistema publicamente. Ele que irá capturar essas solicitações e, dependendo do host ou domínio que solicitar, como meu-sistema.com.br, ele irá direcionar essa requisição para um Service, e esse Service irá jogar para um pod, que de fato está rodando nosso sistema. Aqui embaixo temos uma configuração básica de Ingress, que irá direcionar para o nosso Service meu-sistema-service, que configuramos ali em cima.

Po-po-Por hoje é isso pessoal!

Com isso podemos entender a essência por trás do Kube, para já saber como o Kubernetes funciona e como funciona um deploy de uma imagem nele, a ideia era contextualizar vocês, para já terem a base, e logo mais irei postar um artigo que de fato vai explorar cada configuração, modos de deploy, erros mais comuns, boas práticas e escalabilidade e mais! Fica ligado ai que vai ter mais!!! Beijos meus lindos.