Ir para o conteúdo

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:

  1. Sistema declarativo: Infraestrutura e aplicações definidas declarativamente
  2. Versionado e imutável: Git é a única fonte de verdade
  3. Aplicação automática: Agents sincronizam estado desejado com estado real
  4. 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

  1. eBPF: Tecnologia kernel-level revolucionando observabilidade e segurança
  2. WebAssembly (WASM): Containers mais leves para edge e serverless
  3. Autonomous Kubernetes: Self-healing e auto-optimization via IA
  4. GitOps 2.0: Drift detection avançada, rollbacks inteligentes
  5. Platform Engineering: Kubernetes como commodity via IDPs internos

Referências

  1. Argo Project (2025). Argo CD 2025 User Survey Results. https://blog.argoproj.io/argo-cd-2025-user-survey-results

  2. CNCF (2025). GitOps in 2025: From Old-School Updates to the Modern Way. https://www.cncf.io/blog/2025/06/09/gitops-in-2025/

  3. Kubernetes Documentation (2025). https://kubernetes.io/docs/

  4. Istio (2025). Istio Service Mesh Documentation. https://istio.io/latest/docs/

  5. Flux CD (2025). Flux Roadmap 2025. https://fluxcd.io/roadmap/

  6. Kubeflow (2024). Kubeflow on Kubernetes. https://www.kubeflow.org/

  7. KServe (2024). KServe Documentation. https://kserve.github.io/website/

  8. K3s (2025). Lightweight Kubernetes. https://k3s.io/

  9. Cilium (2025). eBPF-based Networking, Observability, Security. https://cilium.io/

  10. OpenTelemetry (2025). OpenTelemetry for Kubernetes. https://opentelemetry.io/docs/kubernetes/