Orquestração de containers
O que é um container
Um container é uma unidade leve de software que empacota código e todas as suas dependências em um ambiente isolado, compartilhando o kernel do sistema operacional hospedeiro. Diferente das VMs, não há necessidade de um sistema operacional completo por instância.
| Característica | VM | Container |
|---|---|---|
| Isolamento | Hipervisor + OS completo | Namespace do kernel |
| Tempo de boot | Minutos | Segundos |
| Tamanho | GBs | MBs |
| Portabilidade | Média | Alta |
O Docker é o runtime de containers mais comum coberto no CCNA.
Orquestração de containers
Quando uma aplicação escala para dezenas ou centenas de containers, gerenciá-los manualmente torna-se inviável. A orquestração automatiza o ciclo de vida dos containers: implantação, escalonamento, recuperação de falhas e balanceamento de carga.
O Kubernetes (K8s) é o orquestrador padrão da indústria e o mais relevante para o exame CCNA.
Componentes principais do Kubernetes
Control Plane (gerência):
- API Server — ponto central de comunicação do cluster
- Scheduler — decide em qual nó cada container será executado
- Controller Manager — garante que o estado desejado seja mantido
- etcd — banco de dados distribuído que armazena o estado do cluster
Worker Nodes (execução):
- kubelet — agente que roda em cada nó, garante que os containers estejam saudáveis
- kube-proxy — gerencia regras de rede e balanceamento entre pods
- Container Runtime — executa os containers (Docker, containerd)
Conceitos-chave para o exame
- Pod — menor unidade do Kubernetes; agrupa um ou mais containers que compartilham rede e armazenamento
- Deployment — define quantas réplicas de um pod devem existir e gerencia atualizações
- Service — expõe pods na rede com um IP estável, mesmo que os pods sejam recriados
- Namespace — divide logicamente o cluster para diferentes equipes ou ambientes
Redes em ambientes de containers
O CCNA exige entender como containers se comunicam:
- Container-to-container no mesmo pod: via
localhost - Pod-to-pod no mesmo nó: via bridge virtual
- Pod-to-pod entre nós: via CNI plugin (Calico, Flannel, Weave)
- Serviço externo para pod: via NodePort ou LoadBalancer
O Kubernetes atribui um IP único a cada pod. O kube-proxy mantém regras iptables ou ipvs para direcionar o tráfego corretamente.
Microservices e impacto na rede
A arquitetura de microservices divide aplicações monolíticas em serviços independentes, cada um rodando em seu próprio container. Isso aumenta a resiliência, mas gera tráfego leste-oeste (entre servidores dentro do datacenter) significativo — algo que o CCNA aborda no contexto de design de redes.
Implicações para a rede:
- Maior demanda por largura de banda interna
- Necessidade de segmentação com VLANs e ACLs
- Service mesh (como Istio) pode adicionar camada de segurança e observabilidade
Modelos de entrega em nuvem
O CCNA relaciona orquestração com os modelos de nuvem:
| Modelo | Responsabilidade do cliente | Exemplo |
|---|---|---|
| IaaS | VMs, rede, OS | AWS EC2 |
| PaaS | Aplicação e dados | Google App Engine |
| CaaS | Apenas código/containers | AWS EKS, Google GKE |
CaaS (Container as a Service) é a evolução natural para times que adotam Kubernetes gerenciado em nuvem.
Pontos críticos para a prova
- Containers compartilham o kernel do host; VMs possuem kernel próprio
- Kubernetes é o orquestrador padrão da indústria
- Pod é a menor unidade deployável no Kubernetes
- Services fornecem endereçamento estável para pods efêmeros
- CaaS é o modelo de nuvem associado a containers orquestrados
- Tráfego leste-oeste aumenta com microservices — considere no design de rede