Service Mesh com Istio: quando vale a complexidade

Istio é o service mesh mais adotado no ecossistema Kubernetes. Mas também é uma das tecnologias mais complexas de operar. A pergunta certa não é "como implementar Istio" — é "quando a complexidade se justifica".

O que é um Service Mesh

Service mesh é uma camada de infraestrutura dedicada para comunicação service-to-service. Em vez de cada aplicação implementar retry, timeout, circuit breaker e mTLS, o mesh faz isso de forma transparente via sidecar proxies.

Componentes do Istio:

Instalação mínima

```bash

curl -L https://istio.io/downloadIstio | sh -

export PATH=$PWD/istio-*/bin:$PATH

istioctl install --set profile=minimal -y

kubectl label namespace producao istio-injection=enabled

kubectl rollout restart deployment -n producao

```

Traffic Management

Canary Deployments

```yaml

apiVersion: networking.istio.io/v1beta1

kind: VirtualService

metadata:

name: api-service

spec:

hosts:

http:

host: api-service

subset: stable

weight: 95

host: api-service

subset: canary

weight: 5

---

apiVersion: networking.istio.io/v1beta1

kind: DestinationRule

metadata:

name: api-service

spec:

host: api-service

subsets:

labels:

version: v1

labels:

version: v2

```

Circuit Breaker

```yaml

apiVersion: networking.istio.io/v1beta1

kind: DestinationRule

metadata:

name: payment-service

spec:

host: payment-service

trafficPolicy:

connectionPool:

tcp:

maxConnections: 100

http:

http1MaxPendingRequests: 100

http2MaxRequests: 1000

outlierDetection:

consecutive5xxErrors: 5

interval: 30s

baseEjectionTime: 30s

maxEjectionPercent: 50

```

mTLS automático

Istio habilita mTLS entre todos os serviços automaticamente.

```yaml

apiVersion: security.istio.io/v1beta1

kind: PeerAuthentication

metadata:

name: strict-mtls

namespace: producao

spec:

mtls:

mode: STRICT

```

Benefício real: compliance com PCI DSS, HIPAA e LGPD sem alterar código.

Observabilidade gratuita

Com sidecars interceptando todo tráfego, Istio gera automaticamente: métricas RED, distributed traces (Jaeger/Zipkin) e service graph (Kiali).

```bash

kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.22/samples/addons/kiali.yaml

istioctl dashboard kiali

```

Quando NÃO usar Istio

1. Menos de 10 microservices: overhead não se justifica.

2. Equipe sem experiência K8s avançada: Istio adiciona complexidade ao debugging.

3. Latência ultra-baixa: cada sidecar adiciona ~1-3ms.

4. Recursos limitados: cada sidecar consome ~50MB RAM e ~100m CPU. Com 200 pods, são 10GB de RAM só para sidecars.

Quando Istio vale a complexidade

Alternativas mais leves

Conclusão

Istio é poderoso, mas não é para todos. Se você precisa apenas de retry e timeout, uma biblioteca resolve. Se precisa de mTLS automático, canary deployments e observabilidade unificada para 50+ serviços, Istio se paga rapidamente. Adote incrementalmente — comece com mTLS, depois traffic management, depois policies.