Istio
| Fiche express | |
|---|---|
| Type | Implémentation concrète de service mesh pour Kubernetes |
| Data plane | Envoy (sidecar ou ambient) |
| Control plane | istiod (Pilot/Citadel/Galley fusionnés depuis 1.5) |
| Modes | Sidecar classique · Ambient (sidecarless) |
| Voir aussi | Service mesh et mTLS · Envoy · Ingress et Gateway API |
Istio est l'implémentation open source de référence pour le service mesh sur Kubernetes, portée initialement par Google, IBM et Lyft. Pour l'arbitrage « faut-il un mesh, et lequel » voir Service mesh et mTLS — cette page-ci détaille l'implémentation concrète : data plane Envoy, control plane istiod, et les objets qu'on manipule au quotidien.
Architecture
Deux plans distincts :
- Control plane — istiod : depuis la version 1.5, un binaire unique regroupe ce qui était auparavant Pilot (configuration des proxys), Citadel (autorité de certification, identités) et Galley (validation de configuration).
- Data plane — Envoy : proxy injecté en sidecar dans chaque Pod (mode historique), ou déployé au niveau du nœud/à la demande en mode ambient (voir plus bas).
<mermaid> flowchart TD
U[Utilisateur / kubectl] -->|VirtualService, DestinationRule,
PeerAuthentication...| API[API Server] API --> ISTIOD[istiod] ISTIOD -->|xDS| E1[Envoy sidecar Pod A] ISTIOD -->|xDS| E2[Envoy sidecar Pod B] E1 <-->|mTLS| E2
</mermaid>
istiod pousse la configuration aux proxys Envoy via l'API xDS : pas de rechargement statique, la config est appliquée dynamiquement.
Injection du sidecar
Le sidecar istio-proxy est ajouté automatiquement par un webhook d'admission mutant, déclenché par un label sur le namespace :
apiVersion: v1
kind: Namespace
metadata:
name: monapp
labels:
istio-injection: enabled
Une injection manuelle par annotation de Pod reste possible pour un contrôle plus fin.
mTLS automatique
Istio délivre et fait tourner automatiquement des certificats de courte durée (identité SPIFFE) pour chaque charge de travail, sans intervention applicative. Le mode est piloté par la ressource PeerAuthentication :
apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
name: default
namespace: monapp
spec:
mtls:
mode: STRICT
- STRICT — mTLS obligatoire, tout trafic en clair est refusé.
- PERMISSIVE — accepte mTLS et trafic en clair (utile en migration progressive).
Gestion de trafic
Deux CRD combinées pilotent le routage fin :
- VirtualService — règles de routage (par en-tête, poids, retries, timeouts).
- DestinationRule — sous-ensembles (versions) et politiques (load balancing, circuit breaking).
Exemple de canary 90/10 entre deux versions d'un service :
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
name: mon-service
spec:
hosts:
- mon-service
http:
- route:
- destination:
host: mon-service
subset: v1
weight: 90
- destination:
host: mon-service
subset: v2
weight: 10
Un blue-green complet bascule simplement les poids à 0/100. Les mêmes primitives permettent le miroir de trafic (traffic mirroring) pour tester une version en silence.
Observabilité
Chaque proxy Envoy expose nativement des métriques (latence, taux d'erreur, débit) sans instrumentation applicative. Écosystème habituel :
- Prometheus / Grafana — métriques et tableaux de bord.
- Kiali — visualisation de la topologie du mesh et de la santé des routes.
- Jaeger / Zipkin / OpenTelemetry — traçage distribué (nécessite la propagation des en-têtes par l'application).
Sidecar vs ambient
| Critère | Sidecar (classique) | Ambient |
|---|---|---|
| Proxy par Pod | Oui (Envoy injecté) | Non (ztunnel par nœud + waypoint L7 à la demande) |
| Surcoût ressources | Plus élevé (un proxy par Pod) | Réduit |
| Complexité de bascule | Faible (redémarrage du Pod) | Migration Pod par Pod possible |
| Fonctions L7 (routage fin, authz L7) | Toujours disponibles | Via waypoint proxy, à la demande |
| Maturité | Historique, éprouvé | Plus récent (à vérifier selon version) |
Le mode ambient vise à réduire le coût opérationnel du sidecar (une instance Envoy par Pod) en séparant le traitement L4 (niveau nœud) du traitement L7 (proxy waypoint optionnel, activé service par service).
Positionnement
Istio n'est pas qu'un mesh « clé en main » : c'est un control plane qui pilote des instances Envoy. Il peut aussi servir d'implémentation pour la Gateway API (Istio Ingress Gateway), auquel cas c'est encore un déploiement d'Envoy piloté par istiod.