Arquitetura de Cluster

O Kubernetes tem como objetivo hospedar suas aplicações em containers de forma automatizada, facilitando sua implantação em múltiplas instâncias e simplificando a comunicação entre os serviços da aplicação. Vamos usar uma abordagem mais simplificada do que a proposta no curso.

Control Plane (Master)

É o conjunto de nós que contém os componentes responsáveis por governar o Kubernetes. Esses componentes mantêm todas as informações necessárias para garantir o bom funcionamento do sistema e controlar os pods e nós workers.

ETCD

É o banco de dados do Kubernetes. Todas as informações do cluster estão armazenadas no ETCD através de um conjunto de chave-valor.

Kube-Scheduler

É encarregado de tomar decisões sobre a alocação de cada pod nos nós do cluster, levando em conta várias políticas estabelecidas, como capacidade dos nós, topologia, políticas de restrição, tipo de hardware, entre outros. Ele considera também fatores como taints, affinities e outras configurações relevantes.

Kube-Controller-Manager

Desempenha um papel fundamental no monitoramento da saúde do cluster. Ele detecta eventuais falhas e tenta corrigi-las automaticamente. Por exemplo, caso um nó ou pod pare de responder, o Kube-Controller-Manager intervém para garantir que o número correto de pods esteja em execução, restaurando assim o estado desejado do cluster. Esse componente atua como uma espécie de auditoria, verificando continuamente o estado do cluster para garantir sua conformidade e integridade.

Este componente é formado por outros dois componentes principais: Replication Controller e Node Controller.

Kube-APIServer

No Kubernetes, tudo funciona por meio de APIs. O Kube-APIServer é o ponto central dessa arquitetura, sendo responsável pela orquestração das operações dentro do cluster Kubernetes. Ele interpreta as requisições enviadas pelos componentes, compreendendo o que deve ser executado ou não. As informações são armazenadas no ETCD. É por meio do Kube-APIServer que os usuários interagem e definem os manifestos.

O comando kubectl comunica-se exclusivamente com o Kube-APIServer. Embora menos comum, é possível invocar as APIs diretamente com um comando POST, sem o uso do kubectl.

O Kube-APIServer desempenha diversas funções vitais no cluster:

• Faz a autenticação do usuário
• Valida a requisição
• Recupera os dados
• Atualiza o ETCD (único que interage com o ETCD)
• Kube-Controller-Manager, Kube-Scheduler e Kubelet utilizam o Kube-APIServer para fazer atualizações no cluster em suas respectivas áreas.

Assim como todos os componentes do Kubernetes, o Kube-APIServer é distribuído na forma de binários.

Worker Nodes

São os nós do Kubernetes que de fato serão usados para rodar os pods.

Kubelet

É o agente do Kubernetes que roda dentro dos nós para enviar e receber os dados do Kube-APIServer. É responsável por periodicamente ler o Kube-APIServer e executar os comandos dentro dos nós e enviar os relatórios de status dos pods para o Kube-APIServer.

É o Kubelet que tem a função de fazer o pull da imagem dos containers (usando o CRI) no nó e executar os pods. Então ele continua a monitorar o pod e reportar para o Kube-APIServer.

O Kubelet é sempre instalado manualmente dentro de cada nó worker e geralmente está presente somente nos nós workers e não nos masters. O kubeadm não instala o Kubelet. Algumas configurações podem ser passadas ao Kubelet.

Kube-proxy

É o agente de rede que garante a comunicação entre os pods do cluster mesmo estando em diferentes nós.

---

Containers

Todas as máquinas que rodam pods, geralmente workers, precisam ter um Container Runtime Interface (CRI) instalado para rodar containers. Não é necessário que seja o Docker. Na verdade, nem é muito recomendado instalar o Docker para ser o CRI, pois ele traz consigo muitas outras ferramentas que interagem com o CRI e não são necessárias nos nós.

Para isso, podemos usar o containerd, que implementa o runc, que é o core do CRI sem trazer todas essas ferramentas que o Docker traz. Tanto o Docker quanto o containerd usam a especificação de declaração de containers que já conhecemos, então qualquer imagem criada pelo Docker funciona no containerd. O containerd é um projeto graduado da CNCF.

No entanto, o containerd traz consigo uma CLI chamada ctr que é pouco amigável e mais usada para debug, pois tem recursos limitados. A fim de melhorar um pouco a interação com o containerd foi criado o crictl que estende os recursos do ctr, mas ainda não é amigável para propósitos gerais e sim para debugging especialmente nos nós trabalhadores.

Para rodar as coisas de uma forma mais amigável, podemos usar o nerdctl que é muito parecido com o CLI Docker, suporta a maioria das opções que o Docker suporta e tem propósitos gerais, inclusive usado para desenvolvimento das imagens.