Service Mesh: Istio, Linkerd

Service Mesh: Istio, Linkerd

1) O que é o Service Mesh e quando você precisa dele

O Service Mesh é uma camada de plano de dados/gerenciamento de rede que fornece mTLS, roteamento, resistência a falhas e observabilidade entre os serviços sem reescrever o código.

• Segurança padrão (zero-trust, identidade de serviços, política de acesso).
• Controle de tráfego (Canary/Blue-Green, A/B, shadowing).
• Confiabilidade (retais, temporizadores, circuito breaking).
• Observabilidade (métricas, logs, trailers).
• Normalização operacional (políticas como código, GitOps).

• Muitos microsserviços com polilinguinidade e exigência de mTLS.
• Você precisa de cenários avançados de rotação/experimentação sem alterar o aplicativo.
• Existem requisitos de auditoria/política no nível de rede.

2) Istio vs Linkerd - uma breve comparação

3) Arquitetura e modelos de implantação

3. 1 Sidecar mesh (clássico)

Cada Pod recebe um site proxy.
Os benefícios são maturidade, controle L7 total.
Contras: custos gerais CPU/RAM, complexidade dos depósitos/depuração.

3. 2 Istio Ambient Mesh

ztunno (L4) em + waypoint proxies (L7) por necessidade.
Benefícios: menor custo e complexidade, inclusão gradual do L7.
Contras: mais novo, nem todas as malas L7 estão disponíveis sem waypoint.

4) Identidade e mTLS (zero-trust)

4. 1 SPIFF/SPIRE e certificados

A cada worcload é atribuído o SPIFFE ID: 'spiffe ://cluster. local/ns/NS/sa/SA`.
Autenticação: TLS mútuo entre os serviços.
Rotação de chaves - automaticamente (TTL curto).

4. 2 Istio (PeerAuthentication + DestinationRule)

yaml apiVersion: security. istio. io/v1 kind: PeerAuthentication metadata: { name: default, namespace: payments }
spec:
mtls: { mode: STRICT }
apiVersion: networking. istio. io/v1 kind: DestinationRule metadata: { name: payments-dr, namespace: payments }
spec:
host: payments. svc. cluster. local trafficPolicy:
tls: { mode: ISTIO_MUTUAL }

4. 3 Linkerd - mTLS padrão

Ativado após 'linkerd install' + 'linkerd inject'.
Clusters - trust-anchor próprio, rotativo automático.

5) Gestão de tráfego

5. 1 Istio: VirtualService (rotas, canarinhos)

yaml apiVersion: networking. istio. io/v1 kind: VirtualService metadata: { name: payments }
spec:
hosts: ["payments"]
http:
- route:
- destination: { host: payments, subset: v1 } # stable weight: 90
- destination: { host: payments, subset: v2 } # canary weight: 10 retries: { attempts: 2, perTryTimeout: 300ms }
timeout: 2s

yaml apiVersion: networking. istio. io/v1 kind: DestinationRule metadata: { name: payments }
spec:
host: payments subsets:
- name: v1 labels: { version: v1 }
- name: v2 labels: { version: v2 }
trafficPolicy:
loadBalancer: { simple: LEAST_CONN }
outlierDetection:
consecutive5xx: 5 interval: 5s baseEjectionTime: 30s maxEjectionPercent: 50

5. 2 Linkerd: ServiceProfile + TrafficSplit

yaml apiVersion: linkerd. io/v1alpha2 kind: ServiceProfile metadata:
name: payments. default. svc. cluster. local spec:
routes:
- name: POST /withdraw condition:
method: POST pathRegex: "/withdraw"
isRetryable: true timeout: 2s apiVersion: split. smi-spec. io/v1alpha2 kind: TrafficSplit metadata: { name: payments }
spec:
service: payments backends:
- service: payments-v1 weight: 90
- service: payments-v2 weight: 10

6) Ingress/Egress e API

Istio Gateway (ingress/egress) - controla o tráfego de entrada/saída, TLS termination, mTLS passthrough.
O Linkerd trabalha com controladores invress existentes (NGINX/Contour/Traefik); egress - através de Policy/egress-gateway-pattern.
Políticos egress: listas brancas de domínios, SNI-policy, proibição da Internet direta.

7) Autorizações e políticas

7. 1 Istio AuthorizationPolicy (RBAC/ABAC)

yaml apiVersion: security. istio. io/v1 kind: AuthorizationPolicy metadata: { name: allow-withdraw, namespace: payments }
spec:
selector: { matchLabels: { app: payments } }
action: ALLOW rules:
- from:
- source:
principals: ["spiffe://cluster. local/ns/api/sa/gateway"]
to:
- operation:
methods: ["POST"]
paths: ["/withdraw"]
when:
- key: request. auth. claims[role]
values: ["cashout"]

7. 2 Linkerd policy (server + serverauthorization)

yaml apiVersion: policy. linkerd. io/v1beta3 kind: Server metadata: { name: payments-server, namespace: payments }
spec:
podSelector: { matchLabels: { app: payments } }
port: 8080 apiVersion: policy. linkerd. io/v1beta3 kind: ServerAuthorization metadata: { name: allow-gateway, namespace: payments }
spec:
server: { name: payments-server }
client:
meshTLS:
identities: [".ns. api. serviceaccount. identity. linkerd. cluster. local"]

8) Observabilidade e telemetria

8. 1 Métricas

Istio Telemetry API → Prometheus: `istio_requests_total`, `istio_request_duration_milliseconds_bucket`, `istio_tcp_received_bytes_total`.
Linkerd viz: `request_total`, latency p50/p95/p99, `success_rate`.

8. 2 Trailers e logs

Fure o W3C Trace Context.
Istio/Envoy → OTLP в OpenTelemetry Collector; Linkerd - via sidecar-loggers/app-SDK.

8. 3 Instâncias (Exemplars)

Adicione 'trace _ id' aos histogramas de duração para 'jump-to-trace'.

9) Rate limits, WAF, filtros de customa

Istio: EnvoyFilter/WASM para rate limits locais, eksternal-rate-limit service (Redis) e lógica WAF (Lua/WASM).
Linkerd: suporte nativo limitado; rate limit - em ingress/nível de gateway.

10) Multiplicidade

Istio: east-west gateway, PKI comum ou trust-bundle, discovery de serviços via ServiceEntry, Federation.
Linkerd: `linkerd multicluster link`, gateway per cluster, service-mirror контроллер.

Use-cases: ativo-ativo regiões, localização de tráfego, federal zero-trust.

11) Desempenho e custo

Sidecar mesh: overhead CPU/RAM para cada Pod, latidão aumentada (normalmente + 1-3 ms por hop no steady-state).
Ambient (Istio): Consumo menor para L4, L7 é ativado pontualmente.
Linkerd: proxy leve geralmente menos overhead, mas menos recursos extremos L7.
Prática: Mede p95/CPU antes/depois, mantenha os gates SLO para degradação.

12) Segurança

mTLS em todo o lado, TTL curto, rotação automática.
Policy as Code (OPA/Gatekeeper, Kyverno) para proibições 'authorizationPolicy: ALLOW all'.
Os segredos são CSI/Vault, não nos manifestos.
Controle Egress: deny-by-default, folhas de allow explícitas.
Trust domins individuais para ambientes (prod/estágio).

13) Integração com lançamentos e SLO-gating

Canary/Blue-Green é implementado por caminhos mesh (veja exemplos).
Análise de métricas (Prometheus/SpanMetrics) em Argo Rollouts AnalysisTemplate - Auto-stop/reversão em burn-rate/p95/5xx.
Anotações de lançamento no Grafana: comparação de 'versão = stable' canary '.

14) Anti-pattern

Ligar mesh «em todo o lado e imediatamente» → choque de infraestrutura.
Ignorar a cardinalidade das métricas/logs do proxy → sobrecarregar TSDB/loggate.
Deixar o mTLS no modo PERMISSIVE/opaque para sempre.
Tentar fazer um WAF complexo/lógica de negócios dentro de EnvoyFilter em vez de gateway/aplicativo.
Não há política de egress - vazamento na internet/contornação da complacência.
Proxy s ': 15000' debug estão abertos para fora.

15) Folha de cheque de implementação (0-60 dias)

0-15 dias

Selecione um modelo: Sidecar vs Ambient/Linkerd por perfil de carga.
Incluir o mTLS STRICT, as políticas básicas de autorização para 1-2 serviços críticos.
Rotas básicas (timeout/retries), dashboards RED/SLO.

16 a 30 dias

Canary/TrafficSplit, outlier detation/circuito breaking em caminhos quentes.
Integração OTEL: Trailers + Exemplars; alert burn-rate.
Egress-gateways e listas brancas de domínios; deny-by-default.

31 a 60 dias

Linha múltipla (se necessário), federation trust.
Policy as Code на AuthorizationPolicy/ServerAuthorization.
Game-day: simulação de incidente e reversão de rotas/políticas.

16) Métricas de maturidade

A cobertura de mTLS (STRATT/auto-rotate) ≥ 95% dos serviços.
A proporção de tráfego através de lançamentos canários/progressivos ≥ de 80%.
Média overhead p95 <+ 5% da linha de base (após otimização).
0 egress aberto sem permissão, 100% serviços com AuthZ básicos.
RCA «do gráfico para a pista» ≤ 2 minutos (p50).

17) Exemplos de «políticas como código»

Gatekeeper (proibição de PERMISSIVE em venda)

yaml apiVersion: constraints. gatekeeper. sh/v1beta1 kind: K8sIstiomTLSStrict metadata: { name: deny-permissive-prod }
spec:
match:
kinds: [{ apiGroups: ["security. istio. io"], kinds: ["PeerAuthentication"] }]
namespaces: ["prod-"]
parameters:
allowedModes: ["STRICT"]

Kyverno (labels obrigatórios para VS/DR)

yaml apiVersion: kyverno. io/v1 kind: ClusterPolicy metadata: { name: require-mesh-labels }
spec:
rules:
- name: vs-dr-labels match:
any:
- resources:
kinds: ["VirtualService","DestinationRule"]
validate:
message: "owner and service labels required"
pattern:
metadata:
labels:
owner: "?"
service: "?"

18) Dicas de operação

Versione políticas e rotas (semver) promovidas através de GitOps.
Observabilidade proxy: individuais «proxy saturation» (CPU/heap, retries, 429/503).
Orçamento de cardinalização: «rota», «código», «destination» - apenas modelos.
Limites de rede/quotas de namespace (NetworkPolicy/LimitRange).
Documentação do comando: runbook «como reverter rotas/políticas/chaves mTLS».

19) Conclusão

O Istio e o Linkerd lidam com uma tarefa: normalizar a segurança, a confiabilidade e a visibilidade das comunicações entre servidores - mas o fazem com profundidade e custo de posse diferentes.

Você precisa de ricas capacidades L7 e políticas flexíveis - tome Istio (considere o Ambient para reduzir as letras).
Você precisa de simplicidade e overhead pequeno - leve Linkerd.

Seja qual for a mesh escolhida, ative o mTLS padrão, gere o roteiro como código, ligue as métricas aos trailers, feche o egress e adicione o SLO-gating aos lançamentos. Assim, a camada de rede deixará de ser uma caixa preta e tornará-se uma ferramenta previsível de estabilidade e velocidade.