Service Mesh

Em arquiteturas de microsserviços, cada serviço precisa resolver os mesmos problemas de comunicação: retry, timeout, circuit breaking, mTLS, tracing, rate limiting, canary deploys. Implementar isso em cada serviço — em Go, C#, Python, Java — cria duplicação de código difícil de manter e atualizar. Service mesh resolve isso extraindo toda essa lógica para proxies sidecar que interceptam o tráfego transparentemente, sem que o código da aplicação precise saber da sua existência.

O problema que service mesh resolve

Sem service mesh, um time que precisa adicionar timeout de 5s em todas as chamadas inter-serviço precisa: encontrar todos os clientes HTTP em todos os serviços, modificar cada um, testar, fazer deploy coordenado. Com service mesh, a mudança é uma linha de configuração no plano de controle — aplicada imediatamente a todos os serviços sem toque no código.

As responsabilidades que o mesh centraliza:

• Segurança: mTLS automático entre todos os serviços — identidade verificada por certificado, não por IP
• Confiabilidade: retry, timeout, circuit breaker, outlier detection configurados por rota
• Observabilidade: métricas L7, distributed tracing e access logs para cada chamada inter-serviço sem instrumentação no código
• Traffic management: canary, A/B testing, traffic mirroring, weighted routing sem redeployar serviços
• Política: autorização por serviço chamador (não por IP) usando identidade SPIFFE

Data plane vs Control plane

Todo service mesh tem dois planos distintos:

Data plane — os proxies sidecar que ficam junto a cada instância do serviço e interceptam todo o tráfego de entrada e saída. O Envoy é o data plane padrão de quase todos os meshes modernos (Istio, Consul Connect, Kuma). Cada sidecar conhece as políticas de tráfego para aquele serviço e as aplica em tempo real.

Control plane — o cérebro do mesh. Distribui configuração para todos os sidecars via xDS API, gerencia certificados (rotação automática), e provê a interface administrativa. No Istio é o Istiod; no Linkerd é o Linkerd Control Plane; no Consul Connect é o Consul Server.

# Fluxo de uma chamada com service mesh
Serviço A (Pod)
  ↓ tráfego sai pela porta local
Sidecar Envoy de A (container no mesmo Pod)
  ↓ aplica políticas: mTLS, retry, timeout, tracing
Rede Kubernetes
  ↓
Sidecar Envoy de B (container no mesmo Pod)
  ↓ verifica certificado de A, aplica autorização
Serviço B (Pod)

# O Serviço A e o Serviço B chamam localhost normalmente
# Os sidecars são transparentes — sem mudança de código

Sidecar injection

Em Kubernetes, o sidecar é injetado automaticamente via Mutating Admission Webhook — quando um Pod é criado em um namespace com label istio-injection: enabled, o webhook do Istiod modifica o PodSpec para adicionar o container Envoy e o init container que configura as regras de iptables para redirecionar o tráfego.

# Habilitar sidecar injection no namespace
kubectl label namespace production istio-injection=enabled

# Verificar que o sidecar foi injetado
kubectl get pod orders-7d8b9f-xkl2p -n production -o jsonpath='{.spec.containers[*].name}'
# orders envoy-proxy (dois containers no Pod)

# Ver logs do sidecar — todo tráfego do serviço
kubectl logs orders-7d8b9f-xkl2p -c envoy-proxy -n production | head -20

# Forçar injeção em um Pod específico (sem label no namespace)
# Adicionar annotation ao PodSpec:
# sidecar.istio.io/inject: "true"

mTLS — identidade de serviço

mTLS (mutual TLS) é a funcionalidade de segurança mais importante do service mesh. Em vez de confiar em IPs (facilmente falsificáveis em ambientes de container), cada serviço recebe uma identidade criptográfica baseada no padrão SPIFFE (Secure Production Identity Framework For Everyone).

SPIFFE e SVID

SPIFFE define uma identidade de serviço como um URI: spiffe://cluster.local/ns/production/sa/orders-service. Essa identidade é embutida em um certificado X.509 chamado SVID (SPIFFE Verifiable Identity Document). O mesh emite e rotaciona esses certificados automaticamente — sem gestão manual de PKI.

# Istio — ver certificado SVID de um serviço
istioctl proxy-config secret orders-7d8b9f-xkl2p -n production

# Output mostra:
# - Certificate chain com a identidade SPIFFE
# - Tempo de expiração (tipicamente 24h, rotacionado automaticamente)
# - CA que assinou (Istio CA / cert-manager)

# PeerAuthentication — exigir mTLS em um namespace
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: production
spec:
  mtls:
    mode: STRICT  # rejeitar qualquer tráfego sem mTLS válido
    # PERMISSIVE: aceita mTLS e plain HTTP (útil durante migração)

# AuthorizationPolicy — controle de acesso por serviço chamador
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: orders-authz
  namespace: production
spec:
  selector:
    matchLabels:
      app: orders-service
  action: ALLOW
  rules:
  - from:
    - source:
        principals:
        # Apenas payments-service e api-gateway podem chamar orders
        - "cluster.local/ns/production/sa/payments-service"
        - "cluster.local/ns/production/sa/api-gateway"
    to:
    - operation:
        methods: ["GET", "POST"]
        paths: ["/api/orders*"]

Traffic Management

O service mesh separa deployment de release: você pode ter duas versões do serviço rodando simultaneamente e controlar exatamente qual percentual do tráfego vai para cada uma, sem modificar os clientes.

VirtualService e DestinationRule no Istio

# DestinationRule — define subsets (versões) do serviço
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: orders-destination
  namespace: production
spec:
  host: orders-service
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 100
      http:
        http2MaxRequests: 1000
        maxRequestsPerConnection: 10
    outlierDetection:
      consecutive5xxErrors: 5
      interval: 10s
      baseEjectionTime: 30s
      maxEjectionPercent: 50
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2

---
# VirtualService — controla roteamento entre subsets
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: orders-routing
  namespace: production
spec:
  hosts:
  - orders-service
  http:
  # Canary: 10% do tráfego vai para v2
  - match:
    - headers:
        x-canary-user:
          exact: "true"  # tráfego de usuários canary vai sempre para v2
    route:
    - destination:
        host: orders-service
        subset: v2
  - route:
    - destination:
        host: orders-service
        subset: v1
      weight: 90
    - destination:
        host: orders-service
        subset: v2
      weight: 10
    # Retry policy — 3 tentativas em 5xx com backoff
    retries:
      attempts: 3
      perTryTimeout: 5s
      retryOn: "5xx,reset,connect-failure"
    # Timeout global para esta rota
    timeout: 30s
    # Fault injection para testes de resiliência
    # fault:
    #   delay:
    #     percentage:
    #       value: 10
    #     fixedDelay: 2s

Traffic mirroring

Traffic mirroring (ou shadowing) envia uma cópia do tráfego de produção para uma nova versão — em paralelo, sem afetar a resposta ao cliente. A v2 processa as requisições mas as respostas são descartadas. Permite testar com carga real antes de migrar tráfego.

# VirtualService com mirror
spec:
  http:
  - route:
    - destination:
        host: orders-service
        subset: v1
      weight: 100
    mirror:
      host: orders-service
      subset: v2
    mirrorPercentage:
      value: 100.0  # espelhar 100% do tráfego para v2

Observabilidade integrada

O service mesh coleta métricas, traces e logs de cada chamada inter-serviço sem instrumentação no código — mas requer que os serviços propaguem headers de tracing para manter o contexto de trace entre chamadas.

Métricas geradas automaticamente

# Métricas Istio expostas via Prometheus (por sidecar)
# Formato: istio_[direction]_[metric]_[unit]

# Requisições recebidas pelo serviço
istio_requests_total{
  reporter="destination",
  source_workload="api-gateway",
  destination_workload="orders-service",
  request_protocol="http",
  response_code="200",
  response_flags="-"
} 15234

# Distribuição de latência (histogram)
istio_request_duration_milliseconds_bucket{
  reporter="destination",
  destination_workload="orders-service",
  le="25"  # requests abaixo de 25ms
} 12100

# Bytes enviados/recebidos
istio_request_bytes_sum{...}
istio_response_bytes_sum{...}

Distributed tracing — propagação de headers

O sidecar cria spans automaticamente para cada requisição de entrada e saída. Para que os spans sejam correlacionados em um trace único, o serviço deve propagar os headers B3/W3C do request de entrada para os requests de saída. Essa é a única coisa que o código da aplicação precisa fazer explicitamente.

# Headers de tracing que devem ser propagados
# (do request de entrada para todos os requests de saída)
x-request-id
x-b3-traceid
x-b3-spanid
x-b3-parentspanid
x-b3-sampled
x-b3-flags
# Ou formato W3C:
traceparent
tracestate

Istio em profundidade

Istio é o service mesh mais completo e mais complexo. O Istiod (control plane unificado desde a versão 1.5) implementa xDS para configurar os sidecars Envoy, gerencia a CA interna (Citadel), e traduz os CRDs Kubernetes (VirtualService, DestinationRule, etc.) em configuração Envoy.

# Instalação com istioctl
istioctl install --set profile=default -y
# Profiles: minimal, default, demo, external

# Verificar status
istioctl verify-install
kubectl get pods -n istio-system

# Ferramentas de observabilidade bundled com profile=demo
kubectl apply -f samples/addons/prometheus.yaml
kubectl apply -f samples/addons/grafana.yaml
kubectl apply -f samples/addons/jaeger.yaml
kubectl apply -f samples/addons/kiali.yaml

# Kiali — visualização do service graph
istioctl dashboard kiali

# Analisar configuração de um serviço
istioctl analyze -n production

# Debug de conectividade entre dois serviços
istioctl proxy-config routes orders-7d8b9f-xkl2p -n production
istioctl proxy-config clusters orders-7d8b9f-xkl2p -n production | grep payments

Linkerd — simplicidade como filosofia

Linkerd (v2, reescrito em Rust/Go) tem como objetivo ser o service mesh mais simples de operar. Em vez de Envoy (100k+ linhas de C++), usa um proxy em Rust (linkerd2-proxy) com footprint muito menor: ~10MB RAM e latência adicionada de sub-milissegundo.

# Instalação do Linkerd
curl --proto '=https' --tlsv1.2 -sSfL https://run.linkerd.io/install | sh
linkerd check --pre   # pré-requisitos
linkerd install --crds | kubectl apply -f -
linkerd install | kubectl apply -f -
linkerd check         # verificar instalação

# Injetar sidecar em um deployment existente
kubectl get deploy orders-service -n production -o yaml \
  | linkerd inject - \
  | kubectl apply -f -

# Dashboard
linkerd viz install | kubectl apply -f -
linkerd viz dashboard

# Tap — ver tráfego em tempo real (como tcpdump para L7)
linkerd viz tap deploy/orders-service -n production \
  --to deploy/payments-service \
  --method POST

O que Linkerd não tem comparado ao Istio: sem VirtualService/DestinationRule (traffic splitting usa SMI — Service Mesh Interface), sem fault injection nativa, e sem suporte a traffic mirroring tão completo. Para a maioria dos casos — mTLS, métricas, retry, timeout — Linkerd é suficiente e muito mais simples de operar.

Quando usar — e quando não usar

Não use service mesh quando:

• Você tem menos de 5-10 serviços — a complexidade operacional não compensa
• Sua equipe ainda está aprendendo Kubernetes — adicionar mesh na curva de aprendizado é arriscado
• Os serviços são monolitos ou comunicam principalmente via banco de dados — o mesh não ajuda
• Latência é absolutamente crítica (sub-5ms) — o overhead do sidecar pode ser inaceitável
• Você usa VMs, não containers — mesh funciona melhor em Kubernetes

Comparação por linguagem

A única coisa que o código da aplicação precisa fazer para service mesh é propagar headers de tracing. Veja como isso se implementa em cada linguagem.

// Middleware que propaga headers de tracing entre requisições
// Registrar como middleware no pipeline HTTP

public class TracingPropagationMiddleware
{
    // Headers que o Istio/Linkerd esperam propagados
    private static readonly string[] TracingHeaders =
    [
        "x-request-id",
        "x-b3-traceid", "x-b3-spanid", "x-b3-parentspanid",
        "x-b3-sampled", "x-b3-flags",
        "traceparent", "tracestate",  // W3C Trace Context
    ];

    private readonly RequestDelegate _next;

    public TracingPropagationMiddleware(RequestDelegate next) => _next = next;

    public async Task InvokeAsync(HttpContext context)
    {
        // Guardar headers do request de entrada no contexto
        var tracingHeaders = TracingHeaders
            .Where(h => context.Request.Headers.ContainsKey(h))
            .ToDictionary(h => h, h => context.Request.Headers[h].ToString());

        context.Items["TracingHeaders"] = tracingHeaders;
        await _next(context);
    }
}

// Extension para HttpClient — propagar headers automaticamente
public class TracingPropagationHandler : DelegatingHandler
{
    private readonly IHttpContextAccessor _httpContextAccessor;

    public TracingPropagationHandler(IHttpContextAccessor accessor)
        => _httpContextAccessor = accessor;

    protected override Task<HttpResponseMessage> SendAsync(
        HttpRequestMessage request, CancellationToken ct)
    {
        var ctx = _httpContextAccessor.HttpContext;
        if (ctx?.Items["TracingHeaders"] is Dictionary<string, string> headers)
        {
            foreach (var (key, value) in headers)
                request.Headers.TryAddWithoutValidation(key, value);
        }
        return base.SendAsync(request, ct);
    }
}

// Program.cs
builder.Services.AddHttpContextAccessor();
builder.Services.AddTransient<TracingPropagationHandler>();
builder.Services.AddHttpClient("payments")
    .AddHttpMessageHandler<TracingPropagationHandler>();

app.UseMiddleware<TracingPropagationMiddleware>();

// Health check para o mesh detectar readiness
builder.Services.AddHealthChecks();
app.MapHealthChecks("/ready");
app.MapHealthChecks("/health");

from fastapi import FastAPI, Request
import httpx
from contextvars import ContextVar

app = FastAPI()

# ContextVar — armazena headers de tracing por coroutine (thread-safe)
_tracing_headers: ContextVar[dict] = ContextVar('tracing_headers', default={})

TRACING_HEADERS = [
    "x-request-id",
    "x-b3-traceid", "x-b3-spanid", "x-b3-parentspanid",
    "x-b3-sampled", "x-b3-flags",
    "traceparent", "tracestate",
]

@app.middleware("http")
async def propagate_tracing_headers(request: Request, call_next):
    # Extrair headers de tracing do request de entrada
    headers = {
        h: request.headers[h]
        for h in TRACING_HEADERS
        if h in request.headers
    }
    _tracing_headers.set(headers)
    return await call_next(request)

# Cliente HTTP que propaga headers automaticamente
class TracingClient:
    def __init__(self, base_url: str):
        self._client = httpx.AsyncClient(base_url=base_url)

    async def get(self, path: str, **kwargs) -> httpx.Response:
        headers = {**_tracing_headers.get(), **kwargs.pop("headers", {})}
        return await self._client.get(path, headers=headers, **kwargs)

    async def post(self, path: str, **kwargs) -> httpx.Response:
        headers = {**_tracing_headers.get(), **kwargs.pop("headers", {})}
        return await self._client.post(path, headers=headers, **kwargs)

    async def aclose(self):
        await self._client.aclose()

# Health checks para readiness/liveness
@app.get("/ready")
async def ready():
    # Verificar dependências necessárias
    return {"status": "ready"}

@app.get("/health")
async def health():
    return {"status": "ok"}

# Uso
payments_client = TracingClient("http://payments-service")

@app.post("/api/orders")
async def create_order(request: Request):
    # Headers de tracing são propagados automaticamente pelo cliente
    payment = await payments_client.post(
        "/api/payments",
        json={"amount": 100, "currency": "BRL"}
    )

package mesh

import (
    "context"
    "net/http"
)

// Headers de tracing que devem ser propagados
var tracingHeaders = []string{
    "x-request-id",
    "x-b3-traceid", "x-b3-spanid", "x-b3-parentspanid",
    "x-b3-sampled", "x-b3-flags",
    "traceparent", "tracestate",
}

type contextKey struct{}

// TracingMiddleware extrai headers de tracing e guarda no contexto
func TracingMiddleware(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        headers := make(map[string]string)
        for _, h := range tracingHeaders {
            if v := r.Header.Get(h); v != "" {
                headers[h] = v
            }
        }
        ctx := context.WithValue(r.Context(), contextKey{}, headers)
        next.ServeHTTP(w, r.WithContext(ctx))
    })
}

// PropagateHeaders injeta os headers de tracing em um request de saída
func PropagateHeaders(ctx context.Context, req *http.Request) {
    if headers, ok := ctx.Value(contextKey{}).(map[string]string); ok {
        for k, v := range headers {
            req.Header.Set(k, v)
        }
    }
}

// TracingTransport — RoundTripper que propaga headers automaticamente
type TracingTransport struct {
    Base    http.RoundTripper
    Context func() context.Context  // função que retorna o contexto atual
}

func (t *TracingTransport) RoundTrip(req *http.Request) (*http.Response, error) {
    if t.Context != nil {
        PropagateHeaders(t.Context(), req)
    }
    return t.Base.RoundTrip(req)
}

// Uso no serviço
func NewPaymentsClient(ctx func() context.Context) *http.Client {
    return &http.Client{
        Transport: &TracingTransport{
            Base:    http.DefaultTransport,
            Context: ctx,
        },
    }
}

// Health check handlers para o mesh
func ReadinessHandler(w http.ResponseWriter, r *http.Request) {
    // Verificar conexão com dependências críticas
    w.WriteHeader(http.StatusOK)
    w.Write([]byte(`{"status":"ready"}`))
}

func LivenessHandler(w http.ResponseWriter, r *http.Request) {
    w.WriteHeader(http.StatusOK)
    w.Write([]byte(`{"status":"ok"}`))
}

Exercícios práticos

1. Instale o Linkerd em um cluster local (kind ou minikube). Injete o sidecar em dois serviços que se comunicam. Use linkerd viz tap para observar o tráfego em tempo real e linkerd viz stat para ver métricas de sucesso e latência por rota. Critério: linkerd viz stat deploy/orders-service mostra SUCCESS ≥99% para tráfego normal; ao derrubar o pod do backend, tap mostra erros sendo retornados pelo sidecar em <1s; latência P99 visível no dashboard Linkerd Viz.
2. Configure mTLS STRICT em um namespace Istio e verifique que chamadas sem certificado são rejeitadas. Adicione uma AuthorizationPolicy que permita apenas o serviço A chamar o serviço B. Critério: kubectl exec em um pod sem service account autorizada e tentativa de chamar B retorna RBAC: access denied ou upstream connect error or disconnect/reset before headers; pod com service account correta retorna 200; istioctl analyze -n production não reporta warnings.
3. Implemente um canary deploy com Istio VirtualService: 90% do tráfego para v1, 10% para v2. Aumente progressivamente o peso monitorando a taxa de erro. Critério: query Prometheus rate(istio_requests_total{destination_version="v2"}[1m]) / rate(istio_requests_total[1m]) mostra ≈0.10 (10%); ao injetar fault delay de 500ms em v2, o Kiali mostra latência P99 de v2 claramente acima de v1; aplicar VirtualService com 100% v1 elimina os erros em ≤30s.
4. Implemente propagação de headers de tracing na linguagem de sua preferência. Configure Jaeger (disponível no profile demo do Istio). Critério: uma requisição que passa por 3 serviços (A → B → C) gera um trace único no Jaeger com 3 spans e o mesmo trace_id; ao remover o middleware de propagação do serviço B, o trace se quebra em dois: um com A→B e outro sem parent para C.
5. Compare o overhead do Istio vs Linkerd: deploy do mesmo serviço em dois namespaces (um com Istio, outro com Linkerd) e meça com kubectl top pod e hey ou wrk. Critério: documentar RAM do sidecar Linkerd (esperado: ≤10-15MB) vs Istio (esperado: 80-100MB); latência P99 de Linkerd deve ser ≤2ms de overhead adicional; latência P99 de Istio tipicamente 3-8ms de overhead. Compilar tabela comparativa com os valores reais medidos.