1 — Istio Service Mesh para Kubernetes: introdução e fundamentos operacionais

Público-alvo: administradores Kubernetes, SREs, DevOps, times de plataforma, segurança e desenvolvimento. Objetivo: ensinar Istio com responsabilidade operacional, unindo teoria, prática, validação e troubleshooting.

Aviso importante sobre uso deste material

Os exemplos foram criados para aprendizado, laboratório e homologação. Não copie manifests diretamente para produção sem revisão de contexto, versão, domínio, certificado, namespace, labels, política de segurança, observabilidade, rollback e aprovação operacional.

Istio deve reduzir risco operacional, não criar uma nova fonte de indisponibilidade por excesso de configuração ou falta de validação.

Como estudar este treinamento

Cada capítulo segue uma estrutura simples:

• Objetivo do capítulo: o que você deve aprender.
• Conceito: explicação didática.
• Exemplo guiado: YAMLs e comandos comentados.
• O que observar: como validar o comportamento.
• Erros comuns: onde normalmente ocorrem falhas.
• Exercícios: atividades para fixar o conhecimento.
• Checklist: itens mínimos antes de avançar.

A ordem proposta é intencional:

1. Fundamentos de Kubernetes e Service Mesh.
2. Arquitetura do Istio.
3. Instalação e validação.
4. Sidecar mode.
5. Gerenciamento de tráfego.
6. Resiliência.
7. Segurança.
8. Observabilidade.
9. Operação e troubleshooting.
10. Ambient Mode.
11. Multicluster, somente como tema avançado.

Recomendação pedagógica: comece pelo modo sidecar. Ele é mais visual para o aluno, porque o proxy istio-proxy aparece dentro do Pod. Depois que o aluno entende Envoy, VirtualService, DestinationRule, mTLS e políticas, o Ambient Mode fica mais simples de compreender.

Capítulo 1 — Pré-requisitos e contrato de uso

Objetivo do capítulo

Ao final deste capítulo, o aluno deve entender quais conhecimentos são necessários antes de operar Istio e quais cuidados impedem que a malha se torne uma fonte de indisponibilidade.

Conhecimentos mínimos de Kubernetes

Antes de avançar, revise:

• Pod
• Deployment
• Service
• Namespace
• Ingress
• ServiceAccount
• labels e selectors
• readiness probe e liveness probe
• DNS interno do Kubernetes
• uso básico de kubectl
• uso básico de Helm
• leitura de YAML

Istio depende fortemente de labels, nomes de portas, namespaces e ServiceAccounts. Se esses elementos estiverem mal definidos, os recursos do Istio não terão efeito correto.

Contrato de uso do treinamento

Durante este procedimento, adote as seguintes regras:

1. Tudo que for aplicado deve ser validado.
2. Nenhuma política ampla deve ir diretamente para produção.
3. Toda mudança de segurança deve ter rollback.
4. Todo exemplo com domínio, certificado, ARN ou namespace deve ser adaptado.
5. Observabilidade deve estar disponível antes de testes de resiliência.
6. Fault injection e mirroring devem ser tratados como testes controlados.
7. Versões devem ser validadas na documentação oficial no dia da instalação.

O que Istio não corrige

Istio não corrige automaticamente:

• aplicação sem readiness probe;
• aplicação sem logs úteis;
• dependência externa instável;
• código sem timeout interno;
• banco de dados subdimensionado;
• ausência de métricas de negócio;
• falhas de arquitetura da aplicação.

Istio ajuda a controlar, proteger e observar tráfego. Ele não substitui engenharia de software, SRE, observabilidade de aplicação ou gestão de capacidade.

Exercício de autoavaliação

Responda antes de seguir:

1. O que é uma ServiceAccount?
2. Para que servem labels em Pods?
3. O que acontece quando um Service não tem porta nomeada corretamente?
4. Qual a diferença entre readiness e liveness probe?
5. Você sabe reverter um manifesto aplicado com kubectl apply?

Se alguma resposta não estiver clara, revise Kubernetes antes de avançar.

Capítulo 2 — O que é Service Mesh

Objetivo do capítulo

Entender por que Service Mesh existe, quais problemas ele resolve e quais responsabilidades continuam sendo da aplicação.

Conceito

Em arquiteturas de microsserviços, uma chamada que antes acontecia dentro do mesmo processo passa a atravessar a rede. A rede pode falhar, atrasar, duplicar conexões, perder pacotes ou se comportar de maneira diferente entre ambientes.

Um Service Mesh é uma camada de infraestrutura que padroniza a comunicação entre serviços. No Istio, essa camada fornece recursos como:

• controle de tráfego: canary, roteamento por cabeçalho, timeout, retry, mirroring e fault injection;
• segurança: mTLS, identidade de workload, autenticação e autorização;
• observabilidade: métricas, logs de acesso e integração com tracing;
• padronização operacional: políticas declarativas fora do código da aplicação.

O princípio central

A ideia é mover parte das responsabilidades de rede para uma camada comum da plataforma. Em vez de cada aplicação implementar sua própria forma de timeout, retry, métricas e segurança, o mesh aplica políticas de maneira declarativa e padronizada.

Exemplo mental

Sem Istio:

Serviço A ---> rede ---> Serviço B

Cada aplicação precisa implementar seus próprios controles.

Com Istio em modo sidecar:

Serviço A -> Envoy A -> rede mTLS -> Envoy B -> Serviço B

O proxy passa a aplicar políticas de rede, segurança e telemetria.

O que observar

Istio é um amplificador operacional:

• amplifica controle de deploy;
• amplifica visibilidade;
• amplifica segurança;
• mas também amplifica erros de configuração.

Uma política errada pode bloquear tráfego legítimo. Um retry mal definido pode aumentar a carga. Um fault injection mal aplicado pode causar incidente.

Exercícios

1. Cite três problemas que o Istio ajuda a resolver.
2. Cite três problemas que o Istio não resolve sozinho.
3. Explique por que retry pode ser perigoso.
4. Explique por que observabilidade de rede não substitui métrica de negócio.

Série: Série Istio Service Mesh para Kubernetes

• Próximo artigo: Arquitetura do Istio: control plane, data plane, sidecar e Ambient Mode