O que é Kubernetes? Entenda para que serve e como utilizá-lo!
Provavelmente você já deve ter ouvido falar sobre o Kubernetes, certo? No artigo que escrevi sobre Docker (você pode encontrar ele clicando aqui) expliquei um pouco sobre o universo de containers e como os mesmos funcionam.
Provavelmente você já deve ter ouvido falar sobre o Kubernetes, certo? No artigo que escrevi sobre Docker (você pode encontrar ele clicando aqui) expliquei um pouco sobre o universo de containers e como os mesmos funcionam. Legal, mas qual é a ligação? Pois muito bem, o Kubernetes é um orquestrador de containers em produção. Reparem que eu falei containers no geral, então caso você esteja trabalhando com container em outra tecnologia que não seja Docker, isso não é necessariamente um problema, pois o Kubernetes tem suporte a diversas interfaces de execução – cri-o e containerd para dar alguns exemplos.
O Kubernetes, antes de mais nada, é uma plataforma portável e extensiva, além de ser OpenSource e mantido pela CNCF — Cloud Native Computing Foundation. Portanto é extremamente flexível: você consegue trabalhar com ele desde infra on premise até cloud (AWS, GCP, Azure, DigitalOcean – para citar alguns exemplos).
O objetivo do Kubernetes é gerenciar cargas de trabalho e execução de containers, e, com isso, facilitar a configuração declarativa. Uma curiosidade é que o Kubernetes é comumente conhecido apenas como “K8S” (a origem é basicamente um trocadilho com o próprio nome: K + 8 caracteres + S, daí K8S).
Glossário
Mas afinal de contas, o que é orquestração de container?
É o gerenciamento de servidores individuais que rodam em containers. Com isso conseguimos manter a estrutura elástica de forma automatizada. Além de facilitar a alocação de recursos, provisionamento e o balanceamento de carga da aplicação.
Docker vs. Kubernetes
Apenas para explicar, o Docker é uma plataforma de conteinerização – com foco em construir, distribuir e executar os containers. E o Kubernetes como dito é um orquestrador de container que trabalha com plataformas como o Docker, porém também consegue trabalhar com outros runtimes.
Um pouco sobre a arquitetura do K8S
Podemos dividir a arquitetura do Kubernetes entre os Componentes Master (Control Plane) – que tomam decisões globais dentro do Cluster – Componentes de Nó e Objects Types. Abaixo explico um pouco melhor sobre cada um.
Control Plane
Pode ser executado em qualquer máquina do cluster e serve para tomar decisões globais (como scheduler) e também para detectar e reagir a eventos do cluster (como inicializar um novo pod), quando o número de réplicas não está de acordo com o esperado.
Arquitetura do Control Plane
- API Server: O servidor de API é um componente responsável por expor a API do K8S. Podemos dizer que ele é o frontend do Control Plane. A principal implementação do servidor de API é o kube-apiserver que foi projetado para ser dimensionado de forma horizontal. Ele é dimensionado ao implantar mais instâncias.
- etcd: O etcd é o armazenamento de apoio do Kubernetes que serve para todos os dados do cluster. O mesmo é baseado em chave-valor.
- Scheduler: Responsável por observar os pods recém criados que ainda não foram atribuídos ao nó. A partir disso ele cria um agendamento do pod para um nó – de acordo com os recursos, disponibilidade e afinidade.
- Controller Manager: Gerencia os controladores de processos do Kubernetes. Dentro dele existem controladores mais micros e específicos, como o controlador de nós, jobs, EndpointSlice – que é o link entre services e pods e contas de serviço.
Componentes de Nó
São executados em todos os nós e são responsáveis por manter todos os pods em execução, além de fornecer o ambiente em tempo de execução do K8S.
Arquitetura do Node
- kubelet: O kubelet garante, através dos PodSpecs (especificação de Pods), que os containers estejam íntegros e em execução. Ele é executado em cada nó.
- kube-proxy: O kube-proxy mantém regras de rede que possibilitam a comunicação entre pods e entre sessões dentro ou fora do cluster.
- container runtime: Responsável pela execução dos contêineres. O Kubernetes suporta outras implementações além do Docker, através do CRI – Container Runtime Interface
Objects
- Pods: Os nossos containers rodam nos pods, que são as menores unidades de implantação do K8S. Um pod pode conter N containers, porém os recursos são compartilhados entre os mesmos. Então, por via de regra, 1 pod executa 1 container, para que tenhamos uma melhor granularidade de controle dos recursos utilizados. Caso esteja trabalhando com ServiceMesh, no geral terá outro pod rodando ao lado – sidecar – porém isso é assunto para outro artigo.
- Deployment: O deployment realiza o controle de quantas replicas (ou pods) a nossa aplicação terá. Com ele nós conseguimos mapear o estado desejado da nossa aplicação, além de facilitar um rollback da aplicação, visto que ele trabalha baseado em estado.
- Service: Para que nossas aplicações sejam expostas, utilizamos o service. Caso o nosso deployment tenha pelo menos 2 pods rodando – que é o ideal para se ter uma mínima redundância – os 2 pods serão mapeados e terão um balanceamento de carga na frente para redirecionar o tráfego.
- Ingress: O ingress expõe rotas HTTP e HTTPS para os services que estão dentro do cluster. O roteamento feito pelo ingress é controlado por regras declarativas. Eu consigo baratear o custo de infra com o ingress, visto que eu posso, necessariamente, utilizar apenas um endereço de IP exposto e mapear o mesmo em diversos services, através de subdomínios do meu domínio e request params na minha URI.
Vantagens ao usar o Kubernetes
Existem diversas vantagens ao adotar o uso do Kubernetes. Podemos trabalhar com o Kubernetes praticamente em qualquer tipo de infraestrutura, por isso ele é extremamente flexível. A sua adoção também aumenta a produtividade da pessoa desenvolvedora, visto que as implantações são mais facilitadas com o seu uso. Além disso, o Kubernetes proporciona um ambiente muito mais escalável e o fato de ser Open Source também é uma vantagem, uma vez que ele pode ser modificado por todos os interessados da comunidade.
Como executo a minha primeira aplicação no K8S?
Como citado, o Kubernetes é extremamente portátil, então é possível executá-lo em diversos ambientes, inclusive na sua própria máquina. Para tal, vamos trabalhar com o kind (Kubernentes in Docker) — https://kind.sigs.k8s.io. Isso mesmo: vamos executar o cluster K8S utilizando containers. Além dele, precisamos instalar também o kubectl — https://kubernetes.io/docs/tasks/tools – que é interface via linha de comando padrão do Kubernetes. Após a instalação, para criar o primeiro cluster, basta executar o comando abaixo:
Esse comando cria o cluster com apenas um nó, caso precise de mais, acesse: https://kind.sigs.k8s.io/docs/user/quick-start/#advanced
Depois do cluster ter sido criado, precisamos criar os nossos manifestos e referenciar a imagem que nosso deployment vai executar. Para isso, vamos criar uma pasta e colocar os manifestos abaixo:
Reparem que estamos trabalhando com 5 réplicas para o container do nginx – referenciado em image dentro de containers em specs. Isso significa que, caso um container apresente problemas, a aplicação não ficará indisponível Claro que para garantir essa alta disponibilidade, precisaríamos rodar as nossas réplicas em diversos nós e ter diversos control plane no cluster – ambiente redundante. Além disso, estamos tratando a quantidade de recursos que a aplicação pode utilizar. Por fim, basta salvar o arquivo e aplicar o seguinte dentro da pasta via terminal:
Após isso o deployment foi criado e a aplicação já tá rodando no cluster. Para acompanhar basta rodar o comando:
Eu falei no tutorial sobre o service e ingress, que servem para expor nossa aplicação pro mundo. Para não ficar muito longo, vamos utilizar um recurso em ambiente local para conseguir visualizar a nossa aplicação rodando, com esse comando:
Basicamente, com esse comando o tráfego da sua porta 8080 será redirecionado para a porta 80 do container – que foi definido em ports no manifesto. Para ver o resultado basta acessar http://localhost:8080 no seu navegador.
Pontos importantes
Quando estamos trabalhando com containers em produção, é importante sempre lembrarmos sobre a efemeridade do disco. Sempre que houver um problema na aplicação, a primeira coisa que o Kubernetes vai fazer é tentar se auto recuperar (self healing) e com isso os pods serão reestardados. Portanto, caso os logs estejam salvos em disco, os mesmos serão perdidos (essa regra vale para assets também). Então é interessante manter sempre a aplicação desacoplada dessas regras e utilizar outros serviços para tal.
O Kubernetes abstrai toda a complexidade da infra em si, sendo assim uma interface única para que consigamos realizar as nossas implantações de forma mais simples.
