Istio ajoute gestion du trafic, sécurité et observabilité à un ensemble de microservices sans toucher à leur code. Cela n’est possible que grâce à la façon dont ses deux moitiés se partagent le travail : un plan de données (data plane) qui gère réellement le trafic, et un plan de contrôle (control plane) qui dit au plan de données quoi faire. Ce guide couvre les deux, ainsi que le modèle sidecar qui les relie à vos workloads.

Le sidecar : un proxy qui voyage à côté de votre conteneur

Dans le mode par défaut d’Istio, chaque Pod de workload reçoit un second conteneur injecté à côté de celui de votre application : un proxy Envoy, configuré pour intercepter tout le trafic entrant et sortant de ce Pod. Votre application continue de se lier à son port et d’effectuer ses appels sortants exactement comme si rien n’était différent ; le sidecar se place de façon transparente sur le chemin, et c’est tout l’intérêt. L’application n’a jamais besoin de savoir que le proxy est là.

Ce que cela apporte : TLS, retries, timeouts, répartition de charge et autorisation sortent du code applicatif pour devenir de la configuration appliquée au proxy. Une équipe de développement écrit la logique métier ; le mesh gère les préoccupations réseau de manière uniforme pour tous les services, plutôt que de voir chaque équipe réimplémenter (ou oublier d’implémenter) sa propre version des mêmes préoccupations.

Le plan de données : Envoy, qui fait le vrai travail

Le plan de données est l’ensemble de tous ces proxies sidecars, qui transportent réellement chaque requête entre les services. C’est là que le trafic est chiffré, qu’une requête est rejouée après un timeout, qu’une version d’un service peut recevoir 10 % du trafic pour une release canary. Le plan de données ne décide pas de la politique de lui-même ; il applique la configuration que le plan de contrôle lui a poussée.

Le plan de contrôle : istiod

istiod est le plan de contrôle d’Istio, exécuté sous forme de Pods dédiés dans le namespace istio-system. Il remplit trois missions distinctes :

• Distribution de la configuration. Vous exprimez une intention, dans les ressources Kubernetes propres à Istio, comme « répartir le trafic 90/10 entre ces deux versions ». istiod la traduit dans le format de configuration natif d’Envoy et la pousse vers chaque sidecar concerné, de sorte que vous n’écrivez jamais de configuration Envoy à la main (la série « Learn » précédente sur Envoy dans cette bibliothèque couvre à quoi ressemble réellement cette configuration sous-jacente, pour qui est curieux de ce que génère istiod).
• Autorité de certification. istiod émet et renouvelle les certificats que chaque sidecar utilise pour le TLS mutuel, de sorte que le trafic de service à service est chiffré et que chaque côté peut vérifier l’identité de l’autre, sans qu’aucun code applicatif ne gère lui-même les certificats.
• Découverte de services et politiques. istiod suit quels services existent et où, et distribue les politiques d’authentification et d’autorisation aux proxies qui doivent les appliquer.

L’injection de sidecar : comment un Pod obtient réellement un proxy

Installer Istio ne change à lui seul rien à vos workloads en cours d’exécution. L’injection de sidecar est une étape distincte et explicite : étiquetez un namespace (istio-injection=enabled), et tout Pod créé ensuite dans ce namespace reçoit automatiquement un sidecar Envoy ajouté à sa spec au moment de sa création. Les Pods existants ne sont pas modifiés rétroactivement ; ils doivent être recréés (supprimés et réappliqués, ou renouvelés via un Deployment) une fois le label en place avant de recevoir le sidecar.

Ce choix d’adhésion volontaire par namespace est délibéré. Intégrer automatiquement au mesh tous les namespaces d’un cluster, y compris les namespaces système qui n’ont jamais été conçus pour exécuter un sidecar, ajouterait une surcharge de ressources et une complexité dont personne n’a voulu. Le label vous donne le contrôle sur les workloads exacts qui sont intégrés au mesh.

Un Pod doté de son sidecar affiche deux conteneurs là où son équivalent hors mesh en affiche un :

kubectl get pods
# NAME                READY   STATUS
# reviews-v1-abc123   2/2     Running   ← sidecar présent
# ratings-v1-def456   1/1     Running   ← pas de sidecar (namespace non étiqueté)

Pour un workload qui a besoin d’un sidecar sans étiqueter tout son namespace, l’injection manuelle (istioctl kube-inject) ajoute le sidecar à un seul manifeste avant son application ; elle est traitée dans le guide suivant avec le reste de l’installation.

Une remarque sur le mode ambient

Tout ce qui précède décrit l’architecture d’origine d’Istio, basée sur les sidecars, que couvre le reste de cette série. Istio propose aussi une alternative sans sidecar, le mode ambient, qui scinde le plan de données en un composant par nœud (ztunnel) et un proxy waypoint par namespace au lieu d’injecter un proxy dans chaque Pod, dans le but de réduire la surcharge de ressources d’un Envoy par workload. La différence architecturale est assez importante pour sortir du périmètre de cette série ; ce que vous apprenez ici sur la gestion du trafic et les concepts de sécurité s’applique toujours conceptuellement en mode ambient, mais la mécanique d’interception du trafic diffère. Consultez la documentation d’Istio si le mode ambient est précisément ce que vous évaluez.