Containerização e Orquestração¶
A containerização revolucionou a forma como empacotamos, distribuímos e executamos aplicações. De uma abordagem onde aplicações eram instaladas diretamente em servidores físicos ou máquinas virtuais, evoluímos para um modelo onde aplicações são encapsuladas em containers leves, portáveis e consistentes.
Em 2025, Kubernetes consolidou-se como a plataforma padrão para orquestração de containers, com 97% dos usuários de ArgoCD executando-o em produção. A infraestrutura de IA, incluindo workloads de Large Language Models (LLMs), é predominantemente executada em Kubernetes, tornando-o essencial para operações modernas.
1. Fundamentos de Containerização¶
1.1 O Que São Containers¶
Containers são unidades padronizadas de empacotamento de software que incluem código, runtime, ferramentas de sistema, bibliotecas e configurações necessárias para executar uma aplicação.
Características Principais:
- Isolamento: Processos isolados do host e entre si
- Portabilidade: Funcionam igualmente em desenvolvimento, staging e produção
- Eficiência: Compartilham kernel do sistema operacional host
- Imutabilidade: Imagem é read-only, mudanças são camadas efêmeras
- Leveza: Megabytes vs gigabytes de VMs tradicionais
1.2 Docker: O Padrão da Indústria¶
Embora existam alternativas (containerd, CRI-O, Podman), Docker popularizou a containerização e permanece como referência para desenvolvimento local e construção de imagens.
Arquitetura Docker:
┌─────────────────────────────────────────────────────────┐
│ Docker Engine │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────────┐ │
│ │ Container │ │ Container │ │ Container │ │
│ │ (App A) │ │ (App B) │ │ (App C) │ │
│ └─────────────┘ └─────────────┘ └─────────────────┘ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ Docker Daemon (dockerd) │ │
│ └─────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────┘
↓
Linux Kernel
(cgroups, namespaces, overlayfs)
Dockerfile: Definindo Imagens:
# Exemplo: Dockerfile para aplicação Python
FROM python:3.11-slim as builder
WORKDIR /app
COPY requirements.txt .
RUN pip install --user -r requirements.txt
FROM python:3.11-slim
WORKDIR /app
COPY --from=builder /root/.local /root/.local
COPY ./src .
ENV PATH=/root/.local/bin:$PATH
ENV PYTHONDONTWRITEBYTECODE=1
ENV PYTHONUNBUFFERED=1
EXPOSE 8000
USER 1000
CMD ["python", "-m", "uvicorn", "main:app", "--host", "0.0.0.0"]
Melhores Práticas de Docker em 2025:
| Prática | Benefício | Implementação |
|---|---|---|
| Multi-stage builds | Imagens menores | Usar FROM...as stage |
| Non-root user | Segurança | USER 1000 |
| Layer caching | Builds mais rápidos | Copiar requirements antes do código |
| Distroless images | Superfície de ataque mínima | gcr.io/distroless/python3 |
| Image scanning | Segurança proativa | Trivy, Snyk no CI/CD |
1.3 Container Registries¶
Registries são repositórios para armazenar e distribuir imagens de containers.
Principais Registries (2025):
| Registry | Provedor | Características |
|---|---|---|
| Docker Hub | Docker | Público/privado, limites de pull |
| Amazon ECR | AWS | Integração IAM, scanning nativo |
| Google GCR | GCP | Análise de vulnerabilidades |
| Azure ACR | Azure | Geo-replicação, tasks |
| GitHub Packages | GitHub | Integração nativa com repos |
| JFrog Artifactory | JFrog | Universal, enterprise features |
2. Kubernetes: Orquestração em Escala¶
2.1 Arquitetura Fundamentals¶
Kubernetes (K8s) é um sistema de orquestração de containers open-source que automatiza deployment, scaling e operações de aplicações containerizadas.
Componentes do Control Plane:
┌─────────────────────────────────────────────────────────────┐
│ Control Plane │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────────────┐ │
│ │ API Server │ │ etcd │ │ Controller Manager │ │
│ │ (kube-apiserver)│ (Datastore) │ │ (kube-controller) │ │
│ └─────────────┘ └─────────────┘ └─────────────────────┘ │
│ ┌────────────────────────────────────────────────────────┐ │
│ │ Scheduler (kube-scheduler) │ │
│ └────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────────┐
│ Worker Nodes │
│ ┌────────────────────────────────────────────────────────┐ │
│ │ Kubelet │ Kube-Proxy │ Container Runtime │ │
│ └────────────────────────────────────────────────────────┘ │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────────┐ │
│ │ Pod │ │ Pod │ │ Pod │ │
│ │ ┌──────────┐ │ │ ┌──────────┐ │ │ ┌──────────────┐ │ │
│ │ │Container │ │ │ │Container │ │ │ │ Container │ │ │
│ │ └──────────┘ │ │ │Container │ │ │ └──────────────┘ │ │
│ └──────────────┘ │ └──────────┘ │ └──────────────────┘ │
│ └──────────────┘ │
└─────────────────────────────────────────────────────────────┘
2.2 Recursos Principais¶
Pods: Unidade mínima de deployment, encapsula um ou mais containers.
apiVersion: v1
kind: Pod
metadata:
name: web-server
labels:
app: web
spec:
containers:
- name: nginx
image: nginx:1.25
ports:
- containerPort: 80
resources:
requests:
memory: "64Mi"
cpu: "250m"
limits:
memory: "128Mi"
cpu: "500m"
Deployments: Gerenciam replicação e atualizações de Pods.
apiVersion: apps/v1
kind: Deployment
metadata:
name: api-deployment
spec:
replicas: 3
selector:
matchLabels:
app: api
template:
metadata:
labels:
app: api
spec:
containers:
- name: api
image: minha-app:v1.2.3
ports:
- containerPort: 8080
readinessProbe:
httpGet:
path: /health
port: 8080
initialDelaySeconds: 5
periodSeconds: 10
livenessProbe:
httpGet:
path: /health
port: 8080
initialDelaySeconds: 15
periodSeconds: 20
Services: Exposição e balanceamento de carga.
| Tipo de Service | Descrição | Caso de Uso |
|---|---|---|
| ClusterIP | IP interno do cluster apenas | Comunicação inter-serviço |
| NodePort | Expõe em porta do nó | Acesso externo simples |
| LoadBalancer | Provisiona LB de cloud | Exposição pública padrão |
| ExternalName | Alias DNS externo | Integração com serviços externos |
2.3 Storage e Configuração¶
ConfigMaps e Secrets:
# ConfigMap para configuração não-sensível
apiVersion: v1
kind: ConfigMap
metadata:
name: app-config
data:
database.url: "postgres://db:5432/myapp"
cache.ttl: "3600"
---
# Secret para dados sensíveis
apiVersion: v1
kind: Secret
metadata:
name: db-credentials
type: Opaque
stringData:
username: admin
password: "s3cr3t-p@ssw0rd"
Persistent Volumes:
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: postgres-storage
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 10Gi
storageClassName: gp3
3. GitOps: O Padrão Moderno de Deployment¶
3.1 Princípios do GitOps¶
GitOps é um paradigma operacional que utiliza Git como fonte única de verdade para infraestrutura e aplicações declarativas.
Quatro Princípios:
- Sistema declarativo: Infraestrutura e aplicações definidas declarativamente
- Versionado e imutável: Git é a única fonte de verdade
- Aplicação automática: Agents sincronizam estado desejado com estado real
- Reconciliação contínua: Divergências são detectadas e corrigidas automaticamente
3.2 ArgoCD vs Flux CD¶
Em 2025, ArgoCD e Flux CD dominam o cenário GitOps, com abordagens filosóficas distintas.
ArgoCD:
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: minha-aplicacao
namespace: argocd
spec:
project: default
source:
repoURL: https://github.com/org/gitops-repo
targetRevision: main
path: apps/producao
destination:
server: https://kubernetes.default.svc
namespace: producao
syncPolicy:
automated:
prune: true
selfHeal: true
syncOptions:
- CreateNamespace=true
Flux CD:
apiVersion: source.toolkit.fluxcd.io/v1
kind: GitRepository
metadata:
name: minha-aplicacao
namespace: flux-system
spec:
interval: 1m
url: https://github.com/org/gitops-repo
ref:
branch: main
---
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
name: minha-aplicacao
namespace: flux-system
spec:
interval: 10m
path: ./apps/producao
prune: true
sourceRef:
kind: GitRepository
name: minha-aplicacao
Comparação Detalhada (2025):
| Aspecto | ArgoCD | Flux CD |
|---|---|---|
| Filosofia | Experiência de plataforma completa | Pureza Kubernetes-native |
| Interface | Web UI rica + CLI | CLI-first, minimal UI |
| Arquitetura | Aplicação centralizada | Controllers distribuídos |
| Multi-tenancy | Built-in robusto | Requer configuração adicional |
| Helm support | Nativo e completo | Via Helm controller |
| Secret management | Integração com external secrets | SOPS nativo |
| Melhor para | Equipes de aplicação | Engenheiros de plataforma |
Dados da Pesquisa ArgoCD 2025:
- 97% dos usuários executam ArgoCD em produção
- 60% executam 75% ou mais de suas aplicações em Kubernetes
- 70% usam ApplicationSets para multi-cluster
- 45% adotaram Argo Rollouts para progressive delivery
3.3 Progressive Delivery¶
GitOps evoluiu além do deployment contínuo simples para entrega progressiva sofisticada.
Argo Rollouts:
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
name: api-canary
spec:
replicas: 5
strategy:
canary:
steps:
- setWeight: 20
- pause: {duration: 10m}
- setWeight: 40
- pause: {duration: 10m}
- setWeight: 60
- pause: {duration: 10m}
- setWeight: 80
- pause: {duration: 10m}
analysis:
templates:
- templateName: success-rate
args:
- name: service-name
value: api-canary
Técnicas de Progressive Delivery:
| Técnica | Descrição | Quando Usar |
|---|---|---|
| Canary | Liberação gradual para % de usuários | Maioria dos casos |
| Blue-Green | Dois ambientes idênticos, switch instantâneo | Rollback rápido necessário |
| A/B Testing | Roteamento baseado em headers/cookies | Testes de features |
| Shadow | Duplicação de tráfego sem impacto | Testes de carga |
| Feature Flags | Ativação independente de deployment | Liberação gradual de funcionalidades |
4. Kubernetes para Workloads de IA¶
4.1 Scheduling de GPUs¶
Kubernetes tornou-se a plataforma padrão para workloads de Machine Learning e LLMs.
apiVersion: v1
kind: Pod
metadata:
name: treinamento-ml
spec:
containers:
- name: treinamento
image: tensorflow/tensorflow:latest-gpu
resources:
limits:
nvidia.com/gpu: 4 # Solicita 4 GPUs
requests:
nvidia.com/gpu: 4
volumeMounts:
- name: dados
mountPath: /data
volumes:
- name: dados
persistentVolumeClaim:
claimName: ml-dataset
nodeSelector:
accelerator: nvidia-tesla-a100
Operadores para ML:
- Kubeflow: Plataforma completa de ML no Kubernetes
- KServe: Serverless inferencing para modelos
- Seldon Core: Deployment avançado de modelos ML
- Ray: Framework distribuído para ML e IA
4.2 Scaling de Workloads de IA¶
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: llm-inference-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: llm-inference
minReplicas: 2
maxReplicas: 50
metrics:
- type: Resource
resource:
name: nvidia.com/gpu
target:
type: Utilization
averageUtilization: 80
- type: Pods
pods:
metric:
name: inference_latency
target:
type: AverageValue
averageValue: "100m"
5. Service Meshes¶
5.1 Istio: O Service Mesh Completo¶
Service meshes adicionam uma camada de infraestrutura para comunicação segura, observável e controlada entre serviços.
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: api-routing
spec:
hosts:
- api.minhaempresa.com
http:
- match:
- headers:
canary:
exact: "true"
route:
- destination:
host: api
subset: v2
weight: 100
- route:
- destination:
host: api
subset: v1
weight: 90
- destination:
host: api
subset: v2
weight: 10
Comparação de Service Meshes (2025):
| Feature | Istio | Linkerd | Consul Connect |
|---|---|---|---|
| Performance | Média | Alta | Média |
| Complexidade | Alta | Baixa | Média |
| mTLS automático | Sim | Sim | Sim |
| Circuit breaker | Sim | Sim | Sim |
| Rate limiting | Sim | Limitado | Sim |
| Multi-cluster | Sim | Sim | Sim |
| eBPF support | Experimental | Beta | Não |
6. Segurança em Containers¶
6.1 Security Contexts¶
apiVersion: v1
kind: Pod
metadata:
name: app-segura
spec:
securityContext:
runAsNonRoot: true
runAsUser: 1000
fsGroup: 2000
seccompProfile:
type: RuntimeDefault
containers:
- name: app
image: minha-app:v1.0
securityContext:
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true
capabilities:
drop:
- ALL
seccompProfile:
type: RuntimeDefault
6.2 Network Policies¶
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: api-isolamento
namespace: producao
spec:
podSelector:
matchLabels:
app: api
policyTypes:
- Ingress
- Egress
ingress:
- from:
- namespaceSelector:
matchLabels:
name: frontend
ports:
- protocol: TCP
port: 8080
egress:
- to:
- podSelector:
matchLabels:
app: database
ports:
- protocol: TCP
port: 5432
6.3 Pod Security Standards¶
Kubernetes 1.25+ introduziu Pod Security Standards substituindo Pod Security Policies:
| Profile | Descrição | Caso de Uso |
|---|---|---|
| Privileged | Sem restrições | Administração do cluster |
| Baseline | Restrições mínimas | Maioria das aplicações |
| Restricted | Segurança máxima | Aplicações críticas, multi-tenant |
7. Observabilidade de Containers¶
7.1 OpenTelemetry no Kubernetes¶
apiVersion: opentelemetry.io/v1alpha1
kind: OpenTelemetryCollector
metadata:
name: observability
spec:
mode: deployment
config: |
receivers:
otlp:
protocols:
grpc:
endpoint: 0.0.0.0:4317
http:
endpoint: 0.0.0.0:4318
processors:
batch:
resource:
attributes:
- key: cluster
value: producao
action: upsert
exporters:
prometheusremotewrite:
endpoint: http://prometheus:9090/api/v1/write
otlp/jaeger:
endpoint: jaeger-collector:4317
tls:
insecure: true
service:
pipelines:
traces:
receivers: [otlp]
processors: [batch, resource]
exporters: [otlp/jaeger]
metrics:
receivers: [otlp]
processors: [batch]
exporters: [prometheusremotewrite]
7.2 Métricas Específicas de Containers¶
| Métrica | Descrição | Alerta Crítico |
|---|---|---|
| Container CPU throttling | % de tempo sendo throttled | > 25% |
| Container memory usage | Uso vs limit | > 85% |
| Container restart count | Restarts recentes | > 3 em 10min |
| Image pull errors | Falhas ao baixar imagem | > 0 |
| Pod scheduling failures | Pods pendentes | > 5 |
8. Estratégias Avançadas¶
8.1 Multi-Cluster e Federation¶
Karmada (Kubernetes Armada):
apiVersion: policy.karmada.io/v1alpha1
kind: PropagationPolicy
metadata:
name: app-multi-cluster
spec:
resourceSelectors:
- apiVersion: apps/v1
kind: Deployment
name: api
placement:
clusterAffinity:
clusterNames:
- cluster-us-east
- cluster-us-west
- cluster-eu-west
replicaScheduling:
replicaDivisionPreference: Weighted
replicaSchedulingType: Divided
weightPreference:
staticWeightList:
- targetCluster:
clusterNames:
- cluster-us-east
weight: 50
- targetCluster:
clusterNames:
- cluster-us-west
weight: 30
- targetCluster:
clusterNames:
- cluster-eu-west
weight: 20
8.2 Edge Computing com K3s¶
K3s é uma distribuição lightweight de Kubernetes para edge e IoT:
- Binário único de < 100MB
- SQLite como datastore padrão
- Containerd embutido
- Ideal para deployments em larga escala de edge
9. Desafios e Tendências¶
9.1 Desafios Atuais¶
| Desafio | Impacto | Mitigação |
|---|---|---|
| Complexidade de Kubernetes | Curva de aprendizado íngreme | Platform Engineering, IDPs |
| Custos de operações | 30-40% overhead de gestão | Automação, managed services |
| Security sprawl | Superfície de ataque ampla | Policy as code, admission controllers |
| Day 2 operations | Dificuldade de manutenção | GitOps, observabilidade |
| Multi-cluster management | Visibilidade fragmentada | Fleet managers, service meshes |
9.2 Tendências para 2025-2026¶
- eBPF: Tecnologia kernel-level revolucionando observabilidade e segurança
- WebAssembly (WASM): Containers mais leves para edge e serverless
- Autonomous Kubernetes: Self-healing e auto-optimization via IA
- GitOps 2.0: Drift detection avançada, rollbacks inteligentes
- Platform Engineering: Kubernetes como commodity via IDPs internos
Referências¶
-
Argo Project (2025). Argo CD 2025 User Survey Results. https://blog.argoproj.io/argo-cd-2025-user-survey-results
-
CNCF (2025). GitOps in 2025: From Old-School Updates to the Modern Way. https://www.cncf.io/blog/2025/06/09/gitops-in-2025/
-
Kubernetes Documentation (2025). https://kubernetes.io/docs/
-
Istio (2025). Istio Service Mesh Documentation. https://istio.io/latest/docs/
-
Flux CD (2025). Flux Roadmap 2025. https://fluxcd.io/roadmap/
-
Kubeflow (2024). Kubeflow on Kubernetes. https://www.kubeflow.org/
-
KServe (2024). KServe Documentation. https://kserve.github.io/website/
-
K3s (2025). Lightweight Kubernetes. https://k3s.io/
-
Cilium (2025). eBPF-based Networking, Observability, Security. https://cilium.io/
-
OpenTelemetry (2025). OpenTelemetry for Kubernetes. https://opentelemetry.io/docs/kubernetes/