Kubernetes na Prática: Arquitetura do Control Plane, Pods, Ingress e Operação no Azure AKS

Quando uma organização migra suas aplicações monolíticas para dezenas ou centenas de microsserviços empacotados em contêineres Docker, o gerenciamento manual das instâncias torna-se insustentável. Reiniciar contêineres que falharam, distribuir réplicas uniformemente entre servidores físicos, balancear o tráfego de rede e aplicar atualizações progressivas sem indisponibilidade exigem uma camada de controle automatizada.

O Kubernetes (frequentemente abreviado como K8s), originado a partir do projeto interno Borg do Google e mantido pela Cloud Native Computing Foundation (CNCF), consolidou-se como o padrão absoluto de orquestração de contêineres da indústria. Mais do que uma ferramenta de deploy, ele atua como um sistema operacional distribuído que reconcilia continuamente o estado desejado da infraestrutura com a realidade dos servidores em execução.

A Arquitetura do Cluster: Control Plane e Worker Nodes

Um cluster Kubernetes é estruturado em dois domínios operacionais distintos: o plano de controle (Control Plane) e os nós de execução de carga (Worker Nodes):

flowchart TD
    subgraph CP["Control Plane (Plano de Controle / Cérebro do Cluster)"]
        direction TB
        API["kube-apiserver<br/>(Ponto de entrada REST, validação e autenticação)"]
        ETCD[("etcd<br/>(Storage chave-valor distribuído com estado do cluster)")]
        Sched["kube-scheduler<br/>(Aloca pods nos nós ideais por afinidade/recursos)"]
        CM["kube-controller-manager<br/>(Controladores de reconciliação de estado e réplicas)"]
        CCM["cloud-controller-manager<br/>(Integração com recursos nativos de nuvem pública)"]

        API <--> ETCD
        API <--> Sched
        API <--> CM
        API <--> CCM
    end

    subgraph WN["Worker Nodes (Nós de Trabalho / Execução de Cargas)"]
        direction TB
        Kubelet["kubelet<br/>(Agente do nó que se comunica com a API)"]
        Proxy["kube-proxy<br/>(Regras de rede iptables/IPVS do Service)"]
        CRI["Container Runtime (containerd)<br/>(Executa e gerencia processos OCI)"]
        Pods["Pods de Aplicação (Containers A, B, Sidecars)"]

        Kubelet --> CRI
        CRI --> Pods
        Proxy -.-> Pods
    end

    API <-->|"TLS Mútuo"| Kubelet

Componentes do Control Plane

• kube-apiserver: A porta de entrada unificada do cluster. Todos os componentes internos, ferramentas de linha de comando (kubectl) e esteiras de CI/CD comunicam-se exclusivamente via requisições HTTP REST com o API Server.
• etcd: Banco de dados chave-valor distribuído e altamente consistente (baseado no algoritmo de consenso Raft), onde todo o estado do cluster, segredos (Secrets) e declarações de recursos residem.
• kube-scheduler: Analisa os requisitos de CPU, memória, tolerâncias e afinidades de cada novo Pod e determina em qual Worker Node ele deve ser executado.
• kube-controller-manager: Executa loops de controle que observam o estado real dos nós e réplicas, disparando ações corretivas quando nós falham ou instâncias morrem.

Componentes dos Worker Nodes

• kubelet: O agente residente em cada máquina física ou VM. Ele recebe as especificações do Pod (PodSpec) do API Server e garante que os contêineres descritos estejam saudáveis no motor de execução local.
• kube-proxy: Gerencia as regras de roteamento de rede local (via iptables ou IPVS), viabilizando a comunicação interna estável entre Services.
• Container Runtime: O motor compatível com a Container Runtime Interface (CRI), como o containerd ou CRI-O, responsável por puxar imagens de registros e instanciar os processos no kernel Linux.

As Primitivas Fundamentais de Carga de Trabalho

No Kubernetes, desenvolvedores raramente interagem diretamente com contêineres isolados. A abstração opera por objetos declarativos:

Objeto K8s	Função Primária	Caso de Uso Típico
Pod	Menor unidade computacional; agrupa um ou mais contêineres que compartilham rede e volumes	Aplicação web com contêiner principal e sidecar de telemetria
Deployment	Gerencia o ciclo de vida declarativo, réplicas e rolling updates de Pods sem estado (stateless)	APIs REST, microsserviços de negócio e frontends web
StatefulSet	Fornece identificadores de rede fixos e armazenamento persistente ordenado	Bancos de dados, clusters Kafka e instâncias Elasticsearch
DaemonSet	Garante que exatamente uma cópia do Pod execute em cada nó do cluster	Agentes de coleta de logs (FluentBit) e monitoramento (Datadog/Prometheus)
Job / CronJob	Executa contêineres até a conclusão do processo e encerra	Tarefas de migração de banco de dados e rotinas agendadas

Estratégias de Roteamento e Publicação de Serviços

Por padrão, os Pods são efêmeros: ao morrerem e serem recriados pelo Deployment, recebem novos endereços IP dinâmicos. O objeto Service fornece uma abstração de rede estável com um IP virtual imutável (ClusterIP) e resolução de nomes interna no cluster via CoreDNS:

flowchart LR
    Internet["Tráfego Externo da Internet"] --> Ingress["Ingress Controller (NGINX / Traefik / AGIC)<br/>Roteamento por Host e Path com Terminação TLS"]
    
    Ingress -->|"Path: /api/pedidos"| Svc1["Service: pedidos-svc (ClusterIP: 10.0.12.44)"]
    Ingress -->|"Path: /api/pagamentos"| Svc2["Service: pagamentos-svc (ClusterIP: 10.0.18.91)"]

    Svc1 --> Pod1A["Pod Pedidos #1"]
    Svc1 --> Pod1B["Pod Pedidos #2"]
    Svc2 --> Pod2A["Pod Pagamentos #1"]

1. ClusterIP: Expõe o serviço apenas internamente dentro da rede privada do cluster (padrão para microsserviços internos).
2. NodePort: Abre uma porta estática (faixa 30000-32767) em cada nó do cluster para receber conexões externas.
3. LoadBalancer: Solicita ao provedor de nuvem (Azure, AWS, GCP) a criação de um balanceador de carga público ou privado externo com IP dedicado.
4. Ingress: Atua como roteador de borda HTTP/HTTPS no nível da camada 7 (aplicação), consolidando regras de encaminhamento baseadas em domínio (api.exemplo.com) e caminhos (/pedidos), além de gerenciar terminação de certificados TLS em um único ponto.

Operação em Nuvem Gerenciada com Azure AKS

Em ambientes corporativos, manter os nós do Control Plane (etcd, API Server) atualizados, com backup e alta disponibilidade exige grande dedicação de engenharia de plataforma. O Azure Kubernetes Service (AKS) abstrai completamente o Control Plane: a nuvem assume a responsabilidade de mantê-lo operacional e resiliente sem custos adicionais de máquina para o plano básico, cobrando apenas pelas VMs dos Worker Nodes provisionados.

Boas Práticas de Governança no AKS

• Integração com Microsoft Entra ID: Vinculação de autenticação via RBAC corporativo, permitindo que credenciais empresariais governem o acesso ao cluster sem compartilhamento de arquivos kubeconfig com privilégios de cluster-admin estáticos.
• Rede Azure CNI: Cada Pod recebe um endereço IP roteável diretamente na sub-rede da Virtual Network (VNet), permitindo comunicação direta e de baixa latência com bancos gerenciados (como Azure SQL e Cosmos DB) sem necessidade de traduções de endereço (NAT).
• Horizontal Pod Autoscaler (HPA): Escalonamento automático de réplicas de Pods baseado em consumo de CPU, memória ou métricas de negócio via KEDA (Kubernetes Event-driven Autoscaling), escalando a aplicação a zero durante períodos ociosos e a centenas de réplicas durante picos transacionais.