Istio
Istio é um service mesh de código aberto que fornece uma plataforma integrada transparente para os desenvolvedores gerenciarem, protegerem e observarem microsse...
Istio é uma plataforma de service mesh de código aberto que oferece uma maneira transparente de proteger, conectar e monitorar serviços. Ele foi projetado para gerenciar a complexidade das arquiteturas de microsserviços, abstraindo a camada de rede. Istio geralmente é executado como um conjunto de microsserviços implantados dentro de um cluster Kubernetes. Sua arquitetura consiste em dois componentes principais: o Plano de Controle (Control Plane) e o Plano de Dados (Data Plane). O Plano de Controle (por exemplo, Pilot, Citadel, Galley) gerencia e configura os proxies no Plano de Dados. O Plano de Dados consiste em proxies Envoy implantados como sidecars ao lado de cada instância de serviço. Esses proxies Envoy interceptam todo o tráfego de rede entre os serviços, aplicando políticas e coletando telemetria. Os principais recursos incluem gerenciamento de tráfego (por exemplo, roteamento, balanceamento de carga, injeção de falhas), segurança (por exemplo, autenticação mútua TLS, políticas de autorização) e observabilidade (por exemplo, métricas, logs, rastreamento distribuído). As desvantagens envolvem a introdução de complexidade operacional e sobrecarga de recursos devido aos proxies sidecar, mas isso é frequentemente compensado pelos benefícios significativos no gerenciamento de sistemas distribuídos. Istio permite que os desenvolvedores se concentrem na lógica de negócios em vez de preocupações de rede, fornecendo recursos avançados como implantações canary, testes A/B e padrões de resiliência prontos para uso.
graph LR
Center["Istio"]:::main
Rel_advanced_propulsion_systems["advanced-propulsion-systems"]:::related -.-> Center
click Rel_advanced_propulsion_systems "/terms/advanced-propulsion-systems"
Rel_microservices["microservices"]:::related -.-> Center
click Rel_microservices "/terms/microservices"
Rel_service_mesh["service-mesh"]:::related -.-> Center
click Rel_service_mesh "/terms/service-mesh"
classDef main fill:#7c3aed,stroke:#8b5cf6,stroke-width:2px,color:white,font-weight:bold,rx:5,ry:5;
classDef pre fill:#0f172a,stroke:#3b82f6,color:#94a3b8,rx:5,ry:5;
classDef child fill:#0f172a,stroke:#10b981,color:#94a3b8,rx:5,ry:5;
classDef related fill:#0f172a,stroke:#8b5cf6,stroke-dasharray: 5 5,color:#94a3b8,rx:5,ry:5;
linkStyle default stroke:#4b5563,stroke-width:2px;
🧠 Teste de conhecimento
🧒 Explique como se eu tivesse 5 anos
É como um controlador de tráfego super inteligente para todos os diferentes aplicativos que rodam no seu sistema de computador, garantindo que eles conversem entre si de forma segura, eficiente e sem se perderem.
🤓 Expert Deep Dive
A arquitetura do Istio utiliza proxies Envoy como sidecars, injetando-os nos pods de aplicação para interceptar e gerenciar todo o tráfego de entrada e saída. O Plano de Controle, historicamente composto por Pilot (gerenciamento de tráfego), Citadel (segurança) e Galley (validação de configuração), evoluiu com componentes como istiod, que consolida muitas funções. Pilot configura os proxies Envoy através da API xDS (Discovery Service), permitindo roteamento dinâmico, balanceamento de carga e injeção de falhas. Citadel fornece autenticação e autorização robustas de serviço a serviço usando identidades SPIFFE/SPIRE e gerencia a rotação de certificados. Galley lida com a ingestão e validação de configurações. As desvantagens incluem a sobrecarga significativa de recursos (CPU/memória) de executar sidecars Envoy para cada instância de serviço e a latência adicional introduzida pelo salto de rede extra. Vulnerabilidades podem surgir de configurações incorretas em políticas de autorização, potenciais explorações no próprio proxy Envoy ou problemas dentro dos componentes do plano de controle do Istio. Garantir a aplicação consistente de políticas em um ambiente de microsserviços dinâmico é um desafio chave.