Kubernetes — Conceitos básicos e agentes
Tags: kubernetes, docker, cloud, devops
Published: 2021-05-18 20:16:26

Nesse artigo vamos falar sobre os conceitos ditos como básicos no Kubernetes como um ponto de partida para essa série!

Para quem não sabe o Kubernetes é uma ferramenta que gerencia containers que ficam em um cluster, também conhecido como um “orquestrador de containers”. Quando você precisa lidar com muitas aplicações em um cluster o Kubernetes se torna uma boa alternativa. Nele existem várias funcionalidades que torna o seu ecossistema mais resiliente e elástico como veremos ao logo dessa (possível) série sobre Kubernetes.

Apenas dando uma explicação sobre as nomenclaturas usadas no Kubernetes necessárias para esse artigo:
* **Node**: máquina virtual ou física que suporta os Pods.
* **Pod**: pequena unidade que pode ser feito um deploy, ou seja, um container!
* **kubectl**: ferramenta de linha de comando para interagir com o cluster Kubernetes.


## Arquitetura
Como as coisas funcionam por debaixo dos panos?

O Kubernetes, também conhecido como K8s, é composto por uma série de componentes que se comunicam entre si que possuem responsabilidades específicas.

Podemos primeiramente abstrair em duas partes pra ficar melhor de entender, existe o **Master Node** e os **Worker Nodes**.


## Master
![Representação de um Master Node](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/v66mfqrjavlb386m19hg.png)

Dentro de um Master node temos quatro componentes importantes que serão elencados e descritos a seguir:

**ETCD Cluster**: é um banco de dados de chave e valor responsável por guardar todas informações do cluster K8s. Nele podemos encontrar dados de configuração do cluster e das aplicações, status das aplicações e metadados. Cada comando kubectl feito realiza uma interação com o cluster ETCD, seja para buscar dados, alterar ou criar.
O banco ETCD possui uma função chamada watch que possibilita monitorar em tempo real as alterações feitas no cluster e registrar isso em formato de chave e valor.

**kube-apiserver**: esse é o coração do Node Master, tudo é regido pela kube-api onde define a ação de cada componente no Node Master. Nele é validado todas as informações e configurações sobre deploys, services, pods, replicasets, statefullsets e entre outros. É possível integrar uma API própria com a [API do Kubernetes](https://kubernetes.io/docs/reference/using-api/client-libraries/) com isso é possível automatizar alguns processos do seu trabalho com a ferramenta.

**Controller Manager**: esse componente é formado por diversos serviços controladores (outros controllers). Esses controllers são executados como loops fazendo com que monitorem o estado de cada componente no Worker Node e envia essas informações para o kube-apiserver. Ele também realiza as alterações necessárias para que os componentes fiquem no estado que você deseja. Segundo a própria [documentação](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-controller-manager/) os controllers que já vem instalados com o K8s são:

* Replica Controller, Endpoint Controller, Namespace Controller, Service Account Controller, Node Controller, PV-Binder Controller, PV-Protection Controller, Job Controller, Deployment Controller, CronJob e Statefulset Controller.

**kube-scheduler**: é o serviço responsável por anexar os Pods nos devidos Worker Nodes, ele analisa se o Node está em condições favoráveis para que o Pod possa ser levantado. Assim ele realiza um rank dos Worker Nodes disponíveis e elege o melhor para o Pod.

Vale lembrar que é possível pré destinar um Pod a um Worker Node atribuindo um seletor no Pod (mas isso é assunto para outro artigo). Para saber mais sobre como é feito esse processo aqui está a própria [documentação](https://kubernetes.io/docs/concepts/scheduling-eviction/) sobre o kube-scheduler.


## Worker Nodes
![Representação de um Worker Node.](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/e1r2vzhsla28zywsp7ih.png)


**kubelet**: agente responsável por identificar cada Worker Node, ele interage diretamente com o kube-apiserver. Além disso o kubelet analisa as configurações dos Pods (também conhecido como PodSpec) e certifica que esses Pods estão rodando com as configurações corretas. É importante entender que o kubelet não gerencia Pods que não forem criados pelo Kubernetes.

**kube-proxy**: esse componente é encontrado em cada Node e possui interfaces UDP, TCP E SCTP atuando como um proxy que entrega as chamadas para os Services correspondentes de cada Pod. Através dele que é possível fazer o balanceamento de carga (load balancing) das aplicações.

Existem três tipos de Services no Kubernetes com finalidades diferentes que serão tratados nos próximos artigos.

As aplicações em container exigem um agente de execução de container (runtime) para que possam baixar e executar as imagens do container desejado. Existem outras duas alternativas além do Docker que são o [CRI-O](https://cri-o.io/) e o [containerd](https://containerd.io/).


## Conclusão
Espero que esse artigo tenha esclarecido sobre o conceito básico do Kubernetes, pretendo fazer uma séria sobre essa ferramenta tão rica em funcionalidades que esta sendo muito utilizada no mercado hoje em dia.

Até.


### Fontes
[kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/)
[Container runtimes](https://kubernetes.io/docs/setup/production-environment/container-runtimes/)
[kube-proxy](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-proxy/)
[kube-controller-manager](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-controller-manager/)
[kube-scheduler](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-scheduler/)
[Proxies Kubernetes](https://kubernetes.io/docs/concepts/cluster-administration/proxies/)
[kube-apiserver](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-apiserver/)