Istio en production : sidecar, ambient mode et Gateway API

Objectifs

1. Dire ce qu'un service mesh résout, et ce qu'il ne résout pas.
2. Exposer une application avec Gateway API, avec et sans Istio.
3. Installer Istio avec istioctl et avec Helm, en sidecar comme en ambient, et savoir lire la configuration d'un proxy.
4. Livrer une version en canary, la mirror en production, et mesurer le temps de retour arrière.
5. Rendre un appel résilient : timeout, retry, circuit breaker, outlier detection, et savoir lequel aggrave la panne.
6. Chiffrer tout le trafic est-ouest en mTLS, donner une identité à chaque workload, et autoriser flux par flux.
7. Cloisonner une plateforme partagée, namespace par namespace puis à l'intérieur d'un même namespace, et prouver chaque flux dans les 2 sens.
8. Contrôler ce qui sort du cluster, jusqu'au certificat présenté au fournisseur.
9. Diagnostiquer une panne avec les 3 signaux, et savoir ce que le proxy ne saura jamais.
10. Faire tourner le même mesh en ambient, avec ztunnel et des waypoints, et chiffrer ce que ça change.
11. Fédérer plusieurs clusters, partager une racine de confiance, et mesurer la bascule quand une zone tombe.
12. Mettre à niveau le control plane sans coupure, migrer de sidecar vers ambient, et réparer un mesh cassé.

Comment cette formation est faite

Chaque commande publiée ici a été exécutée, et chaque sortie de terminal est réelle. Les versions aussi ont été vérifiées auprès de la source qui fait autorité plutôt que citées de mémoire : Istio 1.30.3, Kubernetes 1.35, Gateway API v1.5.1 en channel experimental, Cilium 1.19.4.

Les résultats contrariants sont publiés comme les autres. Quand la documentation d'Istio annonce qu'une NetworkPolicy de type deny-all sous Cilium bloque les sondes du kubelet, et que sur le lab la policy bloque bien le trafic pendant que les sondes passent, la formation dit les 2 choses et explique dans quelle configuration le piège se déclenche.

Tous les chapitres suivent la même trame : le problème, un tableau des termes à ne pas confondre, la démonstration mesurée, un exemple complet qu'on peut copier et exécuter en entier, les pièges qui coûtent une demi-journée, puis un travail pratique avec son corrigé.

Les 2 modes du data plane, dans l'ordre où ils s'apprennent

Le sidecar d'abord, parce que tout ce qu'Istio sait faire s'y exprime. Puis ambient en 2 modules dédiés, ztunnel pour le L4 et le waypoint pour le L7, et un module entier consacré à la migration entre les 2. À chaque fois, les 2 modes sont comparés sur des mesures relevées sur le même cluster.

Gateway API sert d'API de trafic partout où elle couvre le besoin, y compris pour les waypoints d'ambient qui en sont eux-mêmes des objets. VirtualService et DestinationRule sont enseignés là où Gateway API ne va pas encore : circuit breaker, outlier detection, TLS sortant, subsets.

Le fil rouge

Une application, Boutique, vous suit d'un bout à l'autre : un front, une API, un worker, un service gRPC, PostgreSQL et Redis. Elle est déployée nue au module 00, passe sous sidecar au module 03, se découpe en 3 namespaces cloisonnés au module 07, bascule en ambient au module 10 et finit répartie sur 3 clusters au module 12.

Chaque module la fait progresser d'un cran, et chaque travail pratique corrige un défaut réel qu'elle porte encore.

Le lab

4 clusters Kubernetes, dont un seul est nécessaire pour commencer et porte 13 modules sur 15. 3 machines par cluster, 4 vCPU et 8 Go de mémoire chacune sur le cluster principal. Les 3 autres clusters ne servent qu'au module 12 et peuvent être créés puis détruits ce jour-là.

Vous pouvez les créer en quelques minutes sur CETIC Cloud Platform : à la création du compte, une fois l'adresse e-mail activée, 180 euros de crédit sont offerts, valables un mois, largement de quoi suivre toute la formation. Le chapitre « Le lab » détaille la marche à suivre et fournit les vérifications à passer avant d'aller plus loin.

Prérequis

Kubernetes au niveau du quotidien : Pod, Deployment, Service, ConfigMap, Secret, namespace, et l'usage courant de kubectl. Des notions de réseau, et la ligne de commande Linux.

Aucune connaissance préalable d'Istio, d'Envoy ni de Gateway API n'est nécessaire.

Si Kubernetes n'est pas encore acquis, la formation Kubernetes du même atelier couvre exactement ce socle, et avec la même application fil rouge.