Introdução ao Service Mesh - Controle de Comunicação com Istio/Linkerd

O que é Service Mesh

Service Mesh é uma camada de infraestrutura que gerencia a comunicação entre microsserviços. Separa a complexidade da comunicação entre serviços da aplicação e a controla de forma consistente.

Por que é necessário: À medida que os microsserviços aumentam, torna-se difícil garantir observabilidade, segurança e confiabilidade na comunicação entre serviços. O service mesh resolve esses problemas de forma unificada.

Desafios sem Service Mesh

flowchart LR
    A["Serviço A"] --> B["Serviço B"]

Implementação necessária em cada serviço:

• Lógica de retry
• Circuit breaker
• Timeout
• Gerenciamento de certificados TLS
• Coleta de métricas
• Tracing

Padrão Sidecar

Implanta um proxy (sidecar) em cada Pod de serviço, fazendo toda a comunicação passar por ele.

flowchart LR
    subgraph Pod
        App["Application<br/>(App)"]
        Sidecar["Sidecar<br/>(Envoy)"]
        App <-->|localhost| Sidecar
    end
    Sidecar <-->|"Toda comunicação passa aqui"| External["Externo"]

Arquitetura do Service Mesh

flowchart TB
    subgraph ControlPlane["Control Plane"]
        Config["Config<br/>Management"]
        Telemetry["Telemetry<br/>Collection"]
        Policy["Policy<br/>Enforcement"]
    end

    subgraph DataPlane["Data Plane"]
        SA["Service A<br/>+ Sidecar"]
        SB["Service B<br/>+ Sidecar"]
        SC["Service C<br/>+ Sidecar"]
        SA <--> SB <--> SC
    end

    ControlPlane -->|"Distribuição de configuração"| DataPlane

Principais Funcionalidades

1. Gerenciamento de Tráfego

# Istio VirtualService - Deploy Canário
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: my-service
spec:
  hosts:
    - my-service
  http:
    - route:
        - destination:
            host: my-service
            subset: v1
          weight: 90
        - destination:
            host: my-service
            subset: v2
          weight: 10

2. Circuit Breaker

# Istio DestinationRule
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: my-service
spec:
  host: my-service
  trafficPolicy:
    outlierDetection:
      consecutive5xxErrors: 5
      interval: 30s
      baseEjectionTime: 30s

3. Retry e Timeout

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
spec:
  http:
    - route:
        - destination:
            host: my-service
      timeout: 10s
      retries:
        attempts: 3
        perTryTimeout: 3s
        retryOn: 5xx

4. mTLS (TLS Mútuo)

Criptografa automaticamente a comunicação entre serviços.

flowchart LR
    A["Serviço A<br/>Certificado"] -->|mTLS| B["Serviço B<br/>Certificado"]
    AutoManage["Gerenciamento Automático"] -.-> A
    AutoManage -.-> B

# Istio PeerAuthentication
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: production
spec:
  mtls:
    mode: STRICT

5. Observabilidade

Principais Service Meshes

Istio vs Linkerd

Casos de Uso

Release Canário

Teste A/B

# Roteamento por header
http:
  - match:
      - headers:
          x-user-group:
            exact: beta
    route:
      - destination:
          host: my-service
          subset: v2
  - route:
      - destination:
          host: my-service
          subset: v1

Injeção de Falhas

# Injetar atraso intencionalmente para testes
http:
  - fault:
      delay:
        percentage:
          value: 10
        fixedDelay: 5s
    route:
      - destination:
          host: my-service

Decisão de Adoção

Casos Adequados

• Muitos microsserviços (10+)
• Padrões de comunicação complexos
• Necessidade de segurança Zero Trust
• Necessidade de controle avançado de tráfego
• Uso de Kubernetes

Casos Não Adequados

• Poucos serviços (menos de 5)
• Arquitetura monolítica
• Padrões de comunicação simples
• Recursos limitados da equipe de operações

Resumo

Service mesh é uma infraestrutura para separar a complexidade da comunicação entre microsserviços da aplicação e gerenciá-la de forma unificada. Oferece controle de tráfego, segurança e observabilidade, mas também traz complexidade e overhead de recursos. Considere o número de serviços e a capacidade operacional ao decidir pela adoção.