Service Mesh

O BoxOffice agora roda nove serviços no Kubernetes. Cada time reimplementou as mesmas coisas do seu jeito: order tem timeout de 2 segundos para payment, inventory não tem nenhum; catalog tenta de novo três vezes, search tenta para sempre; ninguém criptografa o tráfego dentro do cluster porque "é interno"; e quando o time de segurança pergunta "quais serviços podem chamar payment?", a resposta honesta é "qualquer pod que saiba a URL". Um service mesh tira essas preocupações transversais — criptografia, identidade, autorização, timeouts, retries, divisão de tráfego, telemetria — do código da aplicação e as coloca em uma camada de infraestrutura uniforme.

O que é um service mesh

Um service mesh é uma camada de infraestrutura dedicada à comunicação entre serviços¹. Ele tem duas partes:

• Plano de dados (data plane) — proxies que ficam no caminho de toda requisição entre serviços. Eles terminam e originam TLS, aplicam políticas, fazem retry, timeout, balanceamento de carga e emitem métricas e traces.
• Plano de controle (control plane) — o cérebro que configura os proxies: distribui regras de roteamento e políticas, e atua como autoridade certificadora que emite a identidade de cada workload.

flowchart TB
    subgraph cp ["Plano de controle (istiod / linkerd-control-plane)"]
        CFG["configuração + política"]
        CA["autoridade certificadora"]
    end
    subgraph dp ["Plano de dados"]
        subgraph po ["pod: order"]
            O["app order"] --- PO["proxy"]
        end
        subgraph pp ["pod: payment"]
            PP["proxy"] --- P["app payment"]
        end
    end
    PO <-->|"mTLS"| PP
    CFG -.->|"rotas, políticas"| PO & PP
    CA -.->|"certificados (rotacionados)"| PO & PP

A aplicação continua chamando http://payment:8080/charges em HTTP puro. O proxy na saída promove a chamada para TLS mútuo, o proxy na entrada verifica a identidade de quem chama, confere a política e entrega HTTP puro a payment. Nenhuma das aplicações mudou uma linha.

O que você ganha

O mesh é a casa natural de três temas do curso: padrões de confiabilidade (veja Confiabilidade), observabilidade de cada salto (veja Observabilidade) e Zero Trust entre serviços (Zero Trust).

Arquiteturas de plano de dados: sidecar, ambient, eBPF

Onde o proxy roda? Três projetos estão em produção hoje²³.

Identidade e mTLS

Como payment sabe que uma chamada vem mesmo de order? Endereços IP não provam nada — pods são recriados com novos IPs, e o atacante no pod search comprometido pode enviar de qualquer IP. O mesh dá a cada workload uma identidade criptográfica.

• TLS (Transport Layer Security) — o servidor prova a sua identidade com um certificado X.509 assinado por uma autoridade certificadora; o canal é criptografado.
• mTLS (TLS mútuo) — o cliente também apresenta um certificado. Os dois lados são autenticados.
• SPIFFE (Secure Production Identity Framework For Everyone)⁴ — um padrão de nomes para identidades de workloads, spiffe://<trust-domain>/<path>. O Istio usa spiffe://cluster.local/ns/<namespace>/sa/<service-account>: a identidade é a service account do Kubernetes.
• SVID (SPIFFE Verifiable Identity Document) — o certificado X.509 de vida curta que carrega essa identidade, rotacionado automaticamente (o tempo de vida padrão do Istio é 24 horas; o do SPIRE, uma hora).

sequenceDiagram
    autonumber
    participant O as order (proxy)
    participant CA as CA do mesh (istiod)
    participant P as payment (proxy)
    O->>CA: CSR + prova do token da service account
    CA-->>O: SVID spiffe://cluster.local/ns/boxoffice/sa/order (24 h)
    P->>CA: CSR + prova do token da service account
    CA-->>P: SVID spiffe://cluster.local/ns/boxoffice/sa/payment
    O->>P: ClientHello
    P-->>O: certificado de payment + CertificateRequest
    O->>O: verifica o SVID de payment contra o trust bundle
    O->>P: certificado de order + prova da chave privada
    P->>P: verifica o SVID de order, lê o seu SPIFFE ID
    P->>P: política de autorização: sa/order pode POST /charges? → permitir
    Note over O,P: canal criptografado, as duas identidades provadas, política aplicada

Ligue o mTLS estrito

Por padrão, o Istio aceita tanto texto puro quanto mTLS (modo permissive), para que os serviços migrem aos poucos. Quando todo workload tiver um proxy, torne-o estrito:

apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: default
  namespace: boxoffice
spec:
  mtls:
    mode: STRICT        # reject any plain-text connection to pods in this namespace

mTLS autentica; uma política autoriza

Um certificado válido diz quem está chamando — não se ele pode. Isso é uma política de autorização, avaliada pelo proxy em toda requisição. Só order pode cobrar cartões:

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: payment-allow-order
  namespace: boxoffice
spec:
  selector:
    matchLabels:
      app: payment
  action: ALLOW
  rules:
    - from:
        - source:
            principals: ["cluster.local/ns/boxoffice/sa/order"]
      to:
        - operation:
            methods: ["POST"]
            paths: ["/charges", "/refunds"]

# API versions change between Linkerd releases: check yours
apiVersion: policy.linkerd.io/v1beta3
kind: Server
metadata:
  name: payment-http
  namespace: boxoffice
spec:
  podSelector:
    matchLabels:
      app: payment
  port: 8080
  proxyProtocol: HTTP/1
---
apiVersion: policy.linkerd.io/v1alpha1
kind: MeshTLSAuthentication
metadata:
  name: order-only
  namespace: boxoffice
spec:
  identities:
    - "order.boxoffice.serviceaccount.identity.linkerd.cluster.local"
---
apiVersion: policy.linkerd.io/v1alpha1
kind: AuthorizationPolicy
metadata:
  name: payment-allow-order
  namespace: boxoffice
spec:
  targetRef:
    group: policy.linkerd.io
    kind: Server
    name: payment-http
  requiredAuthenticationRefs:
    - group: policy.linkerd.io
      kind: MeshTLSAuthentication
      name: order-only

Políticas de tráfego

O segundo grande trabalho de um mesh é moldar o tráfego: timeouts, retries, circuit breaking e divisão.

Timeouts e retries por rota

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: payment
  namespace: boxoffice
spec:
  hosts: ["payment"]
  http:
    - route:
        - destination:
            host: payment
            subset: v1
          weight: 90
        - destination:
            host: payment
            subset: v2        # canary: 10% of the traffic
          weight: 10
      timeout: 3s             # total budget for the call
      retries:
        attempts: 2
        perTryTimeout: 1s
        retryOn: connect-failure,refused-stream,unavailable

Três decisões estão codificadas aqui: um canary manda 10% das chamadas para v2; a chamada inteira tem um orçamento de 3 segundos; e os retries só acontecem em falhas nas quais a requisição certamente não chegou à aplicação (connect-failure, refused-stream, unavailable). Repetir um POST /charges depois de um timeout poderia cobrar o cliente duas vezes — é para isso que existem as chaves de idempotência (veja Computação — integrações).

Circuit breaking com detecção de outliers

apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: payment
  namespace: boxoffice
spec:
  host: payment
  subsets:
    - name: v1
      labels: { version: v1 }
    - name: v2
      labels: { version: v2 }
  trafficPolicy:
    connectionPool:
      http:
        http2MaxRequests: 200          # bulkhead: max concurrent requests
        maxRequestsPerConnection: 50
    outlierDetection:
      consecutive5xxErrors: 5          # eject a replica after 5 errors in a row
      interval: 10s
      baseEjectionTime: 30s
      maxEjectionPercent: 50           # never eject more than half the replicas

A detecção de outliers tira uma réplica problemática do pool de balanceamento por um tempo — um circuit breaker por instância. Os limites do pool de conexões são um bulkhead: quando payment está lento, no máximo 200 requisições esperam por ele, em vez de todas as threads de order.

Experimente. Abra o cenário cascading-failure: uma dependência externa lenta, sem timeouts, esgota as threads de quem a chama, e requisições sem relação começam a falhar. Ligue o timeout e o circuit breaker, rode de novo e compare a taxa de erros e o p99 das outras rotas. No BoxOffice, o timeout do VirtualService e os limites da DestinationRule do mesh são uma forma de aplicar exatamente essa correção sem tocar no código.

Gateway API para o mesh (GAMMA)

A Gateway API do Kubernetes nasceu como sucessora do Ingress para o tráfego norte–sul (veja Borda). A iniciativa GAMMA estende o mesmo recurso HTTPRoute ao tráfego leste–oeste dentro do mesh, de modo que um canary fica igual no Istio, no Linkerd ou no Cilium:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: payment-canary
  namespace: boxoffice
spec:
  parentRefs:
    - group: ""
      kind: Service           # attach to a Service = mesh (east-west) routing
      name: payment
      port: 8080
  rules:
    - backendRefs:
        - name: payment-v1
          port: 8080
          weight: 90
        - name: payment-v2
          port: 8080
          weight: 10

Política do mesh e NetworkPolicy: duas camadas

Uma NetworkPolicy do Kubernetes é um firewall para pods em L3/L4 (IP e porta), aplicado pelo plugin CNI (Calico, Cilium)⁵. Uma política de autorização do mesh atua em L7, com identidade criptográfica. São camadas complementares de defesa em profundidade:

Comece com negar por padrão na camada de rede e depois abra só as arestas do grafo de chamadas:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
  namespace: boxoffice
spec:
  podSelector: {}
  policyTypes: ["Ingress"]
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: payment-from-order
  namespace: boxoffice
spec:
  podSelector:
    matchLabels:
      app: payment
  policyTypes: ["Ingress"]
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: order
      ports:
        - port: 8080

Custos e quando não usar um mesh

Um mesh é poderoso e caro de operar. Ele acrescenta um plano de controle para operar e atualizar, proxies que consomem CPU e memória, alguns milissegundos por salto, uma nova classe de falhas ("o proxy rejeitou") e uma curva de aprendizado íngreme para depurar.

Como se conecta

flowchart LR
    CP["plano de controle<br/>config + CA"] --> DP["plano de dados:<br/>sidecar, ambient, eBPF"]
    CP --> SVID["identidade SPIFFE (SVID)<br/>da service account"]
    SVID --> MTLS["mTLS estrito"]
    MTLS --> AUTHZ["política de autorização<br/>só order → payment"]
    AUTHZ --> NP["NetworkPolicy L3/L4<br/>negar por padrão + saída"]
    AUTHZ --> ZT["PEP para workloads<br/>→ Zero Trust"]
    DP --> TP["timeouts, retries,<br/>outlier detection"]
    TP --> REL["padrões de resiliência<br/>→ Confiabilidade"]
    DP --> CAN["pesos no HTTPRoute (GAMMA)<br/>→ canary em Cloud-native"]
    DP --> TEL["sinais de ouro por salto<br/>→ Observabilidade"]

Componentes da paleta: mesh · app (os serviços atrás de cada proxy) · ingress (Gateway API, norte–sul) · metrics · tracing (telemetria de cada salto). Cenários: cascading-failure, retry-storm. Continua em: Zero Trust, Confiabilidade — padrões, Observabilidade — sinais, Borda — balanceamento no Kubernetes, Cloud-native — entrega (canary).

Pontos-chave