Kubernetes do Zero - Parte 1: Conceitos, Arquitetura e Componentes Essenciais

E aí pessoal, tudo bem?

Uma das coisas que sempre gostei de fazer durante minha jornada profissional e de aprendizado, foi compartilhar conhecimento/criar procedimentos.

Isso é muito bom, por que me ajuda a fixar o que aprendi e também ajudar as pessoas que estão na mesma jornada.

Recentemente embarquei e me aprofundei nos estudos sobre Kubernetes.

Mas afinal, o que é Kubernetes?

"Kubernetes é uma plataforma open source que gerencia containers em escala, cuidando de deploy, escalonamento e alta disponibilidade."

- Projeto desenvolvido pela Google em 2014. Criado para atuar como orquestrador de containers para a própria Google.

Curiosidade: O nome Kubernetes (K8S) vem do Grego que significa “timoneiro”. Isso explicar o timão no logo do projeto.

Antes do Kubernetes a Google já havia criado pelo menos outros dois orquestradores de containers. Mas apenas o Kubernetes é de código aberto (Open Source).

Código Aberto (Open Source) – Isso quer dizer que o código-fonte é público, pode ser explorado livremente, modificado e distribuído por qualquer pessoa.

Arquitetura do Kubernetes

Falando um pouco sobre a arquitetura do Kubernetes, ele segue a estrutura control plane e workers, fazendo assim a concepção de um cluster.

Recomendação mínima para funcionamento do cluster: 3 nós

• 1 control plane
• 2 workers

Explicando cada um

Control plane: responsável por todo gerenciamento do cluster
Workers: onde efetivamente rodam as aplicações que subirmos no cluster

Se formos falar de laboratório para estudo, OK, é possível usar dois nós ou até mesmo um nó, rodando tudo. Mas nunca para ambientes fora deste contexto.

Vale lembrar que também é possível emular tudo isso usando seu próprio desktop, usando ferramentas como: Kind, Minikube, MicroK8S (da Canonical/Ubuntu) ... dentre outros.

Componentes do control plane

kube-apiserver: sendo um dos principais componentes do Kubernetes, expõe uma API formato JSON sobre HTTP, processando todos os comandos e requisições do usuário utilizando principalmente o utilitário kubeclt. A comunicação estabelecida entre os componentes é através de requisições REST.

etcd: nada mais é do que um banco de dados chave-valor. Ele armazena todos os dados de configuração do cluster bem como seu estado e metadados de todo cluster. Todos os dados armazenados aqui são manipulados via API. Pensando em questões de segurança ele só pode ser executado em nós que sejam do tipo control plane, mas o etcd pode ser executado em nós dedicados para essa função, sendo hosts externos ao cluster por exemplo.

kube-scheduler: componente responsável por escolher em qual nó um determinado Pod (falarei sobre o Pod mais pra frente) irá executar/residir. O scheduler faz a seleção do nó com base na quantidade de recursos disponíveis e com o estado de cada nó, mas não somente isso, ele também pode levar em consideração políticas definidas pelo administrador do cluster, como afinidade, localização, etc.

kube-control-manager: responsável por garantir que o cluster esteja no estado definido no etcd. Um exemplo disso é se temos um deploy configurado para ter 3 réplicas de um Pod. Cabe ao control manager verificar no cluster se o estado atual cumpri essa determinação e caso não, em como irá conciliar para satisfazer essa condição.

Componentes do worker

Pod: é denominado a menor unidade em um cluster Kubernetes. Pode agrupar/conter um ou mais containers que irão compartilhar os mesmos recursos de rede e armazenamento do Pod.

Talvez não seja muito comum vermos Pods com mais de um container, isso vai depender muito do comportamento e perfil da aplicação que irá rodar.

Kubelet: é propriamente o agente do kubernetes que roda em cada worker responsável por gerenciar os pods que o control manager direcionou. Ele tem controle e permissão para iniciar, parar e manter os pods e seus respectivos containers em funcionamento de acordo com o que foi instruído pelo control manager.

Kube-proxy: tem função de proxy propriamente dita, mas também como um load balancer, sendo responsável pelo roteamento das requisições para os pods corretos e assim cuidar também da parte de rede do nó.

Container runtime: é o software responsável pela execução dos containers nos nós. Quando estamos usando um Docker ou mesmo um Podman, para que seja possível executar container na nossa máquina, estamos usando um container runtime. Na verdade, temos uma Container Engine usando um Container Runtine para isso.

Existem 4 tipos de container runtime: Low-level, High-level, Sandbox e Virtualized

Low-level: executados diretamente pelo kernel, como o runc por exemplo. Mas vale lembrar que temos outros também.

High-level: executados pelo container engine, como é o caso do containerd.

Sandbox: executados pelo container engine mas são executados de forma segura em unikernels ou usando algum mecanismo de proxy para comunicação com o kernel.

Virtualized: container engine responsável por executar containers de forma segura em máquinas virtuais. Agora vale informar que existe uma certa “penalidade” quanto a performance. Ela é um pouco menor se comparado ao formato de executar nativamente.

Portas

Existem algumas portas que devemos conhecer e saber que existem para o correto funcionamento de todo cluster do kubernetes.

• Control Plane ports:

 

Protocol	Direction	Port Range	Purpose	Used By
TCP	Inbound	6443*	Kubernetes API server	All
TCP	Inbound	2379-2380	etcd server client API	kube-apiserver, etcd
TCP	Inbound	10250	Kubelet API	Self, Control plane
TCP	Inbound	10251	kube-scheduler	Self
TCP	Inbound	10252	kube-controller-manager	Self

 

* Obs.: no caso da porta 6443 ela pode ser customizada, ou seja, podemos trocar por uma porta da nossa escolha. Mas precisamos lembrar que ela precisa estar “aberta”. 

• Workers ports:

 

Protocol	Direction	Port Range	Purpose	Used By
TCP	Inbound	10250	Kubelet API	Self, Control plane
TCP	Inbound	30000-32767	NodePort	Services All

Fechando nosso entendimento sobre o ponto chave do kubernetes

Um ponto bem importante é que o kubernetes não gerencia diretamente os containers, assim como o docker swarm por exemplo. Ele faz a gestão através dos pods.

Pods - é a menor unidade dentro de um cluster kubernetes. Sendo essa a camada administrada pelo kubernetes e dentro dela podendo residir um ou mais containers compartilhando os mesmos recursos do pod, como IP, volumes, ciclos de CPU e memória.

Deployment - responsável por gerenciar o ciclo de vida das aplicações, associar características a aplicação (imagem, porta, volumes, réplicas, dentro outros). São especificados em arquivos do tipo “yaml” ou “JSON” passados como parâmetro para o kubectl executar o deploy. Esse tipo de ação contempla tanto criação como atualização e remoção do que está especificado no deployment.

ReplicaSets - objeto responsável por garantir a quantidade de pods que queremos em execução.

Services - usado quando queremos expor a comunicação por um ClusterIP, NodePort ou LoadBalancer para que seja feita a distribuição de carga entre os pods que compõem um deployment/aplicação.

Com isso, conseguimos entender a relação entre os principais objetos do Kubernetes.

O Deployment define como a aplicação deverá ser executada, informando, por exemplo, qual imagem será utilizada e quantas réplicas desejamos manter. O ReplicaSet fica responsável por garantir que essa quantidade de Pods esteja sempre disponível. Os Pods executam os containers da aplicação e o Service permite que esses Pods sejam acessados e que as requisições sejam distribuídas entre eles.

Essa estrutura permite que o Kubernetes mantenha o estado desejado da aplicação mesmo quando algum Pod apresenta falha. Nesse caso, o próprio Kubernetes pode criar um novo Pod para substituir aquele que deixou de funcionar.

É importante destacar que este é apenas um primeiro contato com a arquitetura e os principais componentes do Kubernetes. Ainda existem diversos outros recursos importantes, como Namespaces, ConfigMaps, Secrets, Ingress, volumes persistentes, probes de saúde e ferramentas de monitoramento.

Para quem está iniciando os estudos, uma boa forma de fixar esse conhecimento é criar um laboratório utilizando ferramentas como Kind, Minikube ou MicroK8s. A partir disso, é possível praticar a criação de Pods, Deployments e Services utilizando arquivos no formato YAML.

Este foi um resumo dos conceitos iniciais que venho estudando sobre Kubernetes. Espero que o conteúdo possa ajudar outras pessoas que também estão iniciando nessa jornada.

Em breve, pretendo compartilhar novos aprendizados e exemplos práticos sobre o assunto.

E você, já utiliza Kubernetes no dia a dia ou também está começando os estudos?