Kubernetes: o que é, quando e como aplicá-lo
Tags: kubernetes, docker, python, django
Published: 2024-01-03 18:08:00

---
title: Kubernetes: o que é, quando e como aplicá-lo
published: true
description: O que é, quando e como aplicá-lo
tags: kubernetes, docker, python, django
# cover_image: https://raw.githubusercontent.com/leogregianin/kubernetes-workshop/main/docs/Kubernetes_logo.png
# Use a ratio of 100:42 for best results.
published_at: 2024-01-03 14:08 -0400
---

## O que é Kubernetes?
Kubernetes é uma plataforma de orquestração de contêineres de código aberto. Ele automatiza o deploy, a escalabilidade e o gerenciamento de aplicativos em contêineres.

![k8s logo](https://raw.githubusercontent.com/leogregianin/kubernetes-workshop/main/docs/Kubernetes_logo.png)

## Qual a sua origem?
O Kubernetes iniciou como um sistema interno de orquestração de contêineres no Google, chamado Borg, que gerenciava a implantação de milhares de aplicativos no Google. Em 2014, o Google abriu o código-fonte de uma versão do Borg e o denominou como Kubernetes, que em grego (`κυβερνήτης`) significa "timoneiro" ou "piloto" e agora é mantido pela Cloud Native Computing Foundation.

## Porque alguns o chamam de K8S?
Esta é uma maneira um tanto nerd de abreviar palavras longas. O número 8 em K8S refere-se às oito letras entre a primeira letra K e a última letra S na palavra Kubernetes. Outros exemplos são I18N para internacionalização e L10N para localização.

## Quais as principais peças de um cluster K8S?
Um cluster Kubernetes é um conjunto de máquinas chamadas "nós" que são usadas para executar aplicativos em contêineres. Existem duas peças principais em um cluster Kubernetes, vejamos:

* O primeiro é o **plano de controle** ou **control plane** que é responsável por gerenciar o estado do cluster. Em ambientes de produção, o control plane geralmente é executado em vários nós que abrangem diversas zonas do data center. Em ambientes on-premisse você mesmo deve ter o controle sobre ele, em ambientes cloud providers como AWS, Google Cloud ou Azure, a própria cloud gerencia o control plane.

* O segundo é um conjunto de **nós de trabalho** ou **worker**. Esses nós executam as cargas de trabalho de aplicativos em contêineres. Os aplicativos em contêineres são executados em um "pod". Os pods são as menores unidades de um cluster Kubernetes. Um pod hospeda um ou mais contêineres e fornece armazenamento compartilhado e rede para esses contêineres. Os pods são criados e gerenciados pelo control plane do Kubernetes. Eles são os blocos de construção básicos dos aplicativos Kubernetes.

![architeture](https://raw.githubusercontent.com/leogregianin/kubernetes-workshop/main/docs/arch.png)

## Control Plane
Plano de Controle consiste em vários componentes principais. Eles são o Servidor API (**API Server**), o **etcd**, o agendador (**Scheduler**) e o gerenciador de controle (**Controller Manager**). O API Server é a principal interface de comunicação entre Control Plane e o restante do Cluster.

![control plane](https://raw.githubusercontent.com/leogregianin/kubernetes-workshop/main/docs/control_plane.png)

O Control Plane expõe uma **API** RESTful que permite aos clientes interagir com o Control Plane e enviar solicitações para gerenciar o cluster.

**etcd** é um armazenamento de chave-valor distribuído, ou seja, é o estado persistente do cluster. É utilizado pela API Server e outros componentes do Control Plane para armazenar e recuperar informações sobre o cluster.

O **Scheduler** é responsável por agendar pods nos nós dos workers do cluster. Ele usa informações sobre os recursos exigidos pelos pods e os recursos disponíveis nos nós do worker para tomar decisões.

O **Controller Manager** é responsável por executar controladores que gerenciam o estado do cluster, por exemplo, o controlador de réplicas, que garante que o número desejado de réplicas de um pod esteja em execução, e um controlador de deploy, que gerencia as atualizações contínuas e reversões de deploys.


## Worker
Os principais componentes do Kubernetes executados nos worker nodes incluem **kubelet**, **container runtime** e o **kubeproxy**.

![worker](https://raw.githubusercontent.com/leogregianin/kubernetes-workshop/main/docs/worker.png)

O **kubelet** é um daemon executado em cada worker node e é responsável pela comunicação com o Control Plane recebendo instruções de quais pods serão executados no nó e garante que o estado desejado dos pods seja mantido.

O **Container runtime** executa os contêineres nos worker nodes e é responsável por extrair as imagens dos contêineres de um registro, iniciar, parar e gerenciar os recursos dos contêineres.

O **kubeproxy** é um proxy de rede executado em cada wroker node e é responsável por rotear o tráfego para os pods corretos, realiza balanceamento de carga para os pods e garante que o tráfego seja distribuído uniformemente entre os pods.


## Vantagens
Kubernetes é escalonável e altamente disponível, fornece recursos como autocorreção, reversões automáticas e dimensionamento horizontal. Isso torna mais fácil aumentar ou diminuir nosso aplicativo conforme necessário, permitindo-nos responder rapidamente às mudanças na demanda.

Kubernetes é portátil, nos ajuda a implantar e gerir aplicações de forma consistente e confiável, independentemente da infraestrutura. Ele é executado on-premise, em cloud ou em ambiente híbrido. Fornece uma maneira uniforme de empacotar, implantar e gerenciar aplicativos.

## Desvantagens
A desvantagem número um é a complexidade. O Kubernetes é complexo de configurar e operar. O custo inicial é alto para formar uma equipe com conhecimento em orquestração de contêineres. Requer um alto nível de conhecimento e recursos para configurar e gerenciar um ambiente de produção do Kubernetes.

A segunda desvantagem é o custo. O Kubernetes requer um certo nível mínimo de recursos para funcionar, a fim de oferecer suporte a todos os recursos mencionados acima. Provavelmente é um exagero para aplicações menores.

## Opção razoável
Uma opção popular que atinge um equilíbrio razoável é transferir o gerenciamento do control plane para um serviço gerenciado do Kubernetes em um cloud provider como Amazon EKS, GKE no Google Cloud e AKS no Azure. Esses serviços permitem que as organizações executem aplicativos Kubernetes sem se preocupar com a infraestrutura.

Eles cuidam de tarefas que exigem conhecimento profundo, como instalar e configurar o control plane, dimensionar o cluster e fornecer manutenção e suporte contínuos. Esta é uma opção razoável para uma organização de médio porte testar o Kubernetes.


## Exemplo em código

Como exemplo, fizemos uma aplicação real chamada **URL shorter**, ou, **Encurtador de URL** que recebe uma URL e retorna um hash da URL original tornando uma URL curta, que ao ser acessada redireciona para a URL original e grava a quantidade de acessos a URL curta e a URL original.

Por exemplo, a URL de um dos meus artigos no Medium é essa: `https://dev.to/leogregianin/python-e-facil-go-e-simples-simples-e-diferente-de-facil-5b9o` e poderia ficar somente `https://encurtador_de_url.com/abc123`.

O objetivo é mostrar como é possível criar uma aplicação utilizando as melhores práticas de desenvolvimento e deploy, utilizando as tecnologias **Django** para backend e frontend, **Django Rest Framework** para API, **Postgres** como banco de dados e **Docker** e **Kubernetes** para containerização e orquestração do deploy.

URL shorter é uma aplicação pequena e é utilizada para fins didáticos de como construir uma aplicação e escalar ela utilizando Kubernetes.

Um único pod:
![one_pod](https://raw.githubusercontent.com/leogregianin/kubernetes-workshop/main/docs/k8s-pod_one.png)

Escalando para 12 réplicas:
![scaling](https://raw.githubusercontent.com/leogregianin/kubernetes-workshop/main/docs/k8s-replicas.png)

App rodando:
![app](https://raw.githubusercontent.com/leogregianin/kubernetes-workshop/main/docs/app.png)


O código da aplicação e os arquivos de configuração do Docker e Kubernetes estão em: https://github.com/leogregianin/kubernetes-workshop