Kubernetes Fundamentals: Orchestration and Architecture

Por que precisamos de algo além do Docker?

Você já sabe como criar e executar contêineres com Docker. Para aplicações com múltiplos serviços, o Docker Compose (e, de forma mais abstrata, o .NET Aspire) nos ajuda a definir e executar esses serviços juntos. Mas o que acontece quando um contêiner falha no meio da noite? Como garantimos que nossa aplicação possa lidar com um aumento súbito de tráfego? E se a máquina virtual que hospeda nossos contêineres cair?

Executar contêineres diretamente com Docker em produção deixa essas questões em aberto, levando a problemas como:

• Downtime: Se um contêiner ou host falha, a aplicação fica indisponível até que alguém intervenha manualmente.
• Falta de Auto-recuperação (Self-Healing): Não há um mecanismo automático para reiniciar contêineres que falharam.
• Escalabilidade Manual: Para lidar com mais carga, você precisaria iniciar manualmente mais contêineres e configurar um load balancer.
• Alta Disponibilidade Complexa: Distribuir réplicas de seus contêineres em múltiplas máquinas para evitar um ponto único de falha requer uma configuração manual complexa.

É aqui que entra um orquestrador de contêineres. O Kubernetes automatiza a implantação, o escalonamento e o gerenciamento de aplicações em contêineres, resolvendo esses problemas de forma robusta.

Para uma excelente explicação sobre os problemas que o Kubernetes resolve, assista ao início deste vídeo. Ele estabelece a base para tudo o que aprenderemos a seguir.

A Arquitetura do Kubernetes: Uma Visão Geral

O Kubernetes opera sobre um conjunto de máquinas (físicas ou virtuais) que formam um cluster. Em um nível mais alto, um cluster Kubernetes é dividido em duas partes principais:

1. O Control Plane (Plano de Controle): O "cérebro" do cluster. Ele toma decisões globais sobre o cluster (como agendar contêineres), além de detectar e responder a eventos do cluster (por exemplo, iniciar um novo contêiner quando a réplica de um serviço falha).
2. Os Worker Nodes (Nós de Trabalho): As "mãos na massa" do cluster. São as máquinas que efetivamente executam suas aplicações em contêineres.

Essa separação é fundamental: o Control Plane gerencia o estado desejado do cluster, e os Worker Nodes trabalham para tornar esse estado uma realidade.

Para uma introdução mais detalhada, com analogias úteis que conectam esses conceitos ao que você já sabe sobre Docker, o artigo a seguir é um excelente ponto de partida.

Agora, vamos detalhar os componentes específicos que vivem em cada uma dessas partes. O vídeo a seguir oferece uma visão geral clara e bem visualizada de toda a arquitetura.

Dentro do Control Plane

O Control Plane pode ser executado em uma ou mais máquinas (para alta disponibilidade) e é composto por vários processos distintos que trabalham juntos.

Aqui está um resumo das responsabilidades de cada componente do Control Plane:

• API Server (kube-apiserver):

  • Função: O ponto de entrada central para todo o cluster. É a única maneira de interagir com o estado do cluster, seja através da linha de comando (kubectl), de um painel de controle ou de automações.
  • Analogia: Pense nele como o porteiro e o recepcionista do cluster. Ele valida e processa todas as requisições de leitura e escrita.

• etcd:

  • Função: O banco de dados do cluster. É um armazenamento de chave-valor consistente e de alta disponibilidade onde todos os dados do cluster são guardados (o "estado" do cluster).
  • Analogia: É a "memória" ou o "cérebro" do cluster. Ele armazena o estado desejado (o que você pediu para ser executado) e o estado atual (o que está realmente em execução).

• Scheduler (kube-scheduler):

  • Função: Responsável por decidir em qual Worker Node um novo contêiner (ou, mais precisamente, um Pod, que veremos na próxima lição) deve ser executado.
  • Analogia: É o "gerente de logística". Ele observa os contêineres que precisam ser alocados e, com base nos recursos disponíveis (CPU, memória) e outras restrições, escolhe o melhor nó para eles.

• Controller Manager (kube-controller-manager):

  • Função: Executa processos de controle que observam o estado do cluster através do API Server e trabalham para levar o estado atual em direção ao estado desejado.
  • Analogia: É o "supervisor proativo". Se você declarou que precisa de 3 réplicas de um serviço, mas apenas 2 estão em execução, o Controller Manager detecta isso e pede ao Scheduler para iniciar mais uma. Ele é a essência do "self-healing".

Dentro de um Worker Node

Cada Worker Node é uma máquina que executa as aplicações e é gerenciada pelo Control Plane. Para isso, cada nó executa alguns processos essenciais.

Os principais componentes de um Worker Node são:

• Kubelet:

  • Função: É o agente do Kubernetes que roda em cada nó. Ele se comunica com o API Server e é responsável por garantir que os contêineres descritos nas especificações de trabalho (PodSpecs) estejam em execução e saudáveis naquele nó.
  • Analogia: É o "capitão" do navio (o nó). Ele recebe ordens do almirantado (Control Plane) e garante que a tripulação (contêineres) execute as tarefas.

• Kube-proxy:

  • Função: Um proxy de rede que roda em cada nó e mantém as regras de rede. Ele permite a comunicação de rede com seus contêineres de dentro e de fora do cluster, implementando o conceito de Services do Kubernetes.
  • Analogia: É o "controlador de tráfego" ou "encanador" de rede do nó, roteando o tráfego para os contêineres corretos.

• Container Runtime:

  • Função: O software responsável por executar os contêineres. O Kubernetes é flexível e suporta vários runtimes.
  • Exemplos: containerd (o mais comum hoje), CRI-O. Embora o Docker possa ser usado, o Kubernetes moderno geralmente interage diretamente com o containerd, que é o runtime de contêiner dentro do próprio Docker.

Conclusão

Nesta lição, demos o primeiro passo fundamental para entender o Kubernetes. Vimos que ele é muito mais do que um simples executor de contêineres; é um sofisticado sistema de orquestração projetado para automação e resiliência.

Principais Pontos:

• Kubernetes resolve os problemas de disponibilidade, escalabilidade e auto-recuperação que não são abordados nativamente pelo Docker.
• A arquitetura é dividida em um Control Plane (o cérebro) e Worker Nodes (a força de trabalho).
• O Control Plane gerencia o estado do cluster através de seus componentes: API Server (gateway), etcd (memória), Scheduler (alocador) e Controller Manager (regulador de estado).
• Os Worker Nodes executam as aplicações usando o Kubelet (agente), Kube-proxy (rede) e um Container Runtime (executor).

Próxima Lição:
Agora que entendemos a arquitetura e os "bastidores" do Kubernetes, na próxima lição vamos começar a interagir com o cluster. Você aprenderá sobre os objetos fundamentais com os quais trabalhamos no Kubernetes — Pod, Deployment e Service — e usará a ferramenta de linha de comando kubectl para inspecionar um cluster e seus recursos.