Istio service mesh : lab débutant→prod

À la fin de ce tutoriel, vous saurez expliquer un service mesh, poser Istio 1.30 en lab, injecter un sidecar Envoy, activer le mTLS STRICT, faire un canary et exposer l’app via Gateway API — puis juger sidecar vs ambient avant un passage EKS ca-central-1.

Niveau : Intermédiaire · Temps estimé : 55–75 min · Versions cibles : Istio 1.30.x (K8s 1.32–1.36) · istioctl · kind ou kubeadm · Dernière vérification : 2026-09-11 · Region : ca-central-1

Slug : wow-service-mesh-istio · Série : WOW (15/50) · Mot-clé SEO : istio service mesh · Publish : GO (Maître WP-CLI)

← Précédent : cert-manager + Let’s Encrypt · → Suivant : Linkerd : mesh léger · Aussi : Ingress / Gateway API · NetworkPolicies · Argo CD

Prérequis

  • Cluster lab 1.32+ (kind, minikube, kubeadm) avec kubectl admin — Architecture Kubernetes · kubeadm
  • Bases Services / Ingress — Services · Ingress et Gateway API
  • Helm utile, pas obligatoire — Helm
  • Optionnel : profil AWS lab en ca-central-1 pour la checklist prod EKS — Démarrer avec AWS
  • Coût estimé : ~0 € en kind. Pas d’EKS « pour tester Istio » (nœuds + NLB + sidecar CPU). Le mesh se comprend en local.
kubectl version --short
kubectl get nodes
# 2 vCPU / 4 Go RAM mini ; 8 Go plus confortable (istiod + 2 sidecars)

Ce que nous allons construire

Istio service mesh (WOW 15/50) — lab kind, cible prod EKS ca-central-1
  ├── Pourquoi un mesh (et quand s’en passer)
  ├── Sidecar vs ambient (Istio 1.30)
  ├── Install istiod (profile demo) + injection
  ├── Apps httpbin + sleep, mTLS STRICT
  ├── Canary VirtualService + DestinationRule
  ├── Entrée Gateway API (HTTPRoute)
  ├── Checklist EKS ca-central-1 + teardown
  └── Quiz + FAQ + maillage WOW

(Schéma — alt : « Client → Gateway Istio → sidecar/ztunnel → Services Kubernetes, control plane istiod ».)

Étape 1 — Pourquoi un service mesh (et pourquoi Istio) ?

Kubernetes route en L4 (Service, kube-proxy / eBPF). Dès que vous voulez mTLS entre apps, canary par header, retries/timeouts homogènes et des traces sans recoder chaque langage, vous sortez du « Service + Ingress ».

Un service mesh déplace ça dans le plan de données (proxy) gouverné par un plan de contrôle.

Besoin Sans mesh Avec Istio
Chiffrement est-ouest App TLS bricolé mTLS (identité SPIFFE)
Canary 10 % Deux Ingress + chance Poids / versions
Observabilité L7 APM par langage Métriques Envoy homogènes
Authz HTTP Logiciel métier AuthorizationPolicy

Istio (CNCF) est le mesh le plus documenté en entretien 2026. Alternative légère : Linkerd (WOW 16). Ne posez pas Istio pour un seul Deployment nginx : le coût ops (upgrades CRD, webhooks, latence) doit payer un besoin réel (mTLS, trafic, multi-équipes).

Étape 2 — Architecture 2026 : sidecar vs ambient

istiod : discovery, certificats, traduction des CR en config proxy.

Deux data planes cohabitent en 1.30 (migration progressive possible) :

Mode Plan de données Idéal pour
Sidecar Envoy dans chaque Pod (istio-proxy) Labs, features L7 historiques, clusters déjà meshés
Ambient ztunnel L4 nœud + waypoint L7 optionnel Nouveaux clusters prod : moins de RAM, pas de restart d’app pour joindre le mesh

API trafic :

  • Sidecar : VirtualService + DestinationRule + Gateway Istio ou Gateway API.
  • Ambient L7 : Gateway API (HTTPRoute, waypoint). VirtualService en ambient = alpha — ne pas mixer VS et HTTPRoute sur le même host.

Ce lab démarre en sidecar (visible, pédagogique), puis indique le virage ambient pour la prod 2026.

Étape 3 — Installer Istio 1.30 (istioctl)

curl -L https://istio.io/downloadIstio | ISTIO_VERSION=1.30.0 sh -
cd istio-1.30.0
export PATH="$PWD/bin:$PATH"
istioctl x precheck
istioctl install --set profile=demo -y
kubectl -n istio-system get pods

Attendu : istiod Running + gateways demo. En prod : profil default ou ambient, pas demo.

istioctl version et kubectl get crd | grep istio : CRD mesh + éventuellement Gateway API.

Étape 4 — Injecter le sidecar et déployer httpbin + sleep

kubectl create namespace mesh-lab
kubectl label namespace mesh-lab istio-injection=enabled
kubectl apply -n mesh-lab -f samples/httpbin/httpbin.yaml
kubectl apply -n mesh-lab -f samples/sleep/sleep.yaml
kubectl -n mesh-lab get pods

Pods 2/2 Ready (app + istio-proxy). Sinon : webhook, quota, ou label ns oublié.

SLEEP=$(kubectl -n mesh-lab get pod -l app=sleep -o jsonpath='{.items[0].metadata.name}')
kubectl -n mesh-lab exec "$SLEEP" -c sleep -- 
  curl -sS http://httpbin.mesh-lab:8000/get | head

Attendu : JSON httpbin (trafic déjà intercepté par Envoy).

Étape 5 — mTLS STRICT (le vrai premier gain)

Par défaut Istio est souvent en mTLS permissif (clair + mTLS). En prod DEH : STRICT dès que tous les clients sont dans le mesh.

# mtls-strict.yaml
apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: default
  namespace: mesh-lab
spec:
  mtls:
    mode: STRICT

kubectl apply -f mtls-strict.yaml
kubectl -n mesh-lab exec "$SLEEP" -c sleep -- 
  curl -sS -o /dev/null -w "%{http_code}n" http://httpbin.mesh-lab:8000/get

Toujours 200 via sidecar. Un Pod sans sidecar vers httpbin doit échouer (connexion refusée / reset). C’est le test d’entretien : « STRICT casse le trafic clair volontairement ».

Job hors mesh : autre ns sans injection, jamais PERMISSIVE « pour débloquer ».

Étape 6 — Canary 90/10 (VirtualService + DestinationRule)

Deux Deployments httpbin (version: v1|v2). Dupliquez le manifeste samples et changez le label :

apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: httpbin
  namespace: mesh-lab
spec:
  host: httpbin.mesh-lab.svc.cluster.local
  subsets:
    - name: v1
      labels: { version: v1 }
    - name: v2
      labels: { version: v2 }
---
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: httpbin
  namespace: mesh-lab
spec:
  hosts:
    - httpbin.mesh-lab.svc.cluster.local
  http:
    - route:
        - destination: { host: httpbin.mesh-lab.svc.cluster.local, subset: v1 }
          weight: 90
        - destination: { host: httpbin.mesh-lab.svc.cluster.local, subset: v2 }
          weight: 10

Bouclez 50 curl depuis sleep : ~10 % v2. En prod : gated par Argo CD (sync manuel) + métriques Prometheus / Grafana. Istio ne remplace pas GitOps : les CR mesh vivent dans Git.

Étape 7 — Entrée : Gateway API (chemin 2026)

Pas d’Ingress nginx « en plus pour voir ». Entrée Istio 1.30 = Gateway API (GatewayClass istio, HTTPRoute) — lab P3 Ingress / Gateway API.

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: mesh-gw
  namespace: mesh-lab
spec:
  gatewayClassName: istio
  listeners:
    - name: http
      port: 80
      protocol: HTTP
      allowedRoutes: { namespaces: { from: Same } }
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: httpbin
  namespace: mesh-lab
spec:
  parentRefs:
    - name: mesh-gw
  rules:
    - backendRefs:
        - name: httpbin
          port: 8000

TLS : couplez cert-manager (WOW 14) sur le listener HTTPS. En EKS ca-central-1, le Gateway Istio s’expose souvent via un NLB tagué Project=deh-lab, Region=ca-central-1.

Étape 8 — Vers la prod (EKS ca-central-1) et ambient

Checklist DEH « mesh prod » :

  1. Besoin écrit (mTLS, canary, authz L7) — sinon Linkerd ou pas de mesh.
  2. EKS ca-central-1, CNI validé (VPC CNI + istio-cni si ambient).
  3. Pin 1.30.x ; revue CRD + webhook à chaque minor.
  4. Quotas CPU/RAM sidecars (ou ztunnel + waypoints).
  5. STRICT par ns ; AuthorizationPolicy deny-by-default sur les APIs sensibles.
  6. Metrics Envoy → Prometheus ; CR Istio via GitOps — Argo CD.
  7. NetworkPolicies en plus du mesh ; teardown + tags AWS, zéro EKS oublié.

Ambient nouveau cluster : label istio.io/dataplane-mode=ambient, waypoints L7, HTTPRoute (pas VS). Sidecar existant : migration graduelle 1.30, workloads mixtes OK.

Troubleshooting

Symptôme Piste
Pod 1/1, pas de sidecar Label istio-injection / revision istio.io/rev ; restart des Pods après le label
503 UF / UO DestinationRule subset sans Pods ; mTLS STRICT vs client hors mesh
Gateway Address vide GatewayClass istio absent ; profile sans ingress ; LB cloud pending
Canary 100 % v1 Labels version absents sur le Deployment v2
Webhook timeout CNI / NetworkPolicy bloque istiod 15017 
istioctl proxy-status
istioctl analyze -n mesh-lab
kubectl -n mesh-lab logs "$SLEEP" -c istio-proxy --tail=50

FAQ

Istio remplace-t-il Ingress / Gateway API ?
Non. Le mesh gère surtout est-ouest. Le nord-sud passe par un Gateway (API K8s de préférence). Ingress nginx n’est plus une cible durable en 2026.

Sidecar ou ambient pour un premier lab ?
Sidecar pour voir Envoy. Ambient pour un nouveau cluster prod (moins de RAM, join sans restart).

mTLS STRICT casse mes Jobs curl ?
Normal : injectez le Job, ou sortez-le du ns meshé. Ne repassez pas PERMISSIVE « pour débloquer ».

Pourquoi ca-central-1 alors que kind est local ?
Convention DEH : tout workload AWS (EKS, NLB, tags) vise ca-central-1, jamais le défaut us-east-1.

Istio vs Linkerd vs « pas de mesh » ?
Istio = richesse (et ops). Linkerd = petit équipe, mTLS simple (WOW 16). Zéro mesh = souvent le bon choix < 5 services.

Quiz (5 questions)

1. istiod est surtout :
– A. Un Ingress nginx · B. Le control plane (discovery, certs, config) · C. Un CNI

2. En ambient L7, l’API trafic recommandée est :
– A. VirtualService seul · B. HTTPRoute (Gateway API) · C. Ingress annotations

3. PeerAuthentication STRICT implique :
– A. HTTP clair accepté · B. mTLS obligatoire entre workloads meshés · C. TLS uniquement vers Internet

4. Un canary 90/10 Istio sidecar s’exprime avec :
– A. Deux LoadBalancers · B. VirtualService weights + DestinationRule subsets · C. Un HPA

5. La région lab / prod DEH pour EKS est :
– A. us-east-1 · B. ca-central-1 · C. eu-west-3

Réponses : 1‑B · 2‑B · 3‑B · 4‑B · 5‑B

Nettoyage lab

kubectl delete ns mesh-lab --wait=false
istioctl uninstall --purge -y
kubectl delete ns istio-system --ignore-not-found
# kind delete cluster   # si cluster jetable

Ne laissez aucun EKS / NLB en ca-central-1. Vérifiez : aws elbv2 describe-load-balancers --region ca-central-1 (profil lab).

Pour aller plus loin

Maillage série WOW / Kubernetes
← WOW 14 cert-manager + Let’s Encrypt
→ WOW 16 Linkerd mesh léger
GitOps Argo CD · Flux
Hubs Kubernetes · Docker

Meta publication (Rank Math / SEO)

  • Title SEO : Istio service mesh : lab sidecar, mTLS, canary (2026)
  • Meta description : Istio 1.30 : sidecar vs ambient, mTLS STRICT, canary 90/10, Gateway API. Lab kind ~0 €, checklist EKS ca-central-1. Guide FR WOW 15/50.
  • Focus keyword : istio service mesh
  • Schemas : Article + HowTo + FAQ
  • Image mise en avant : assets/web/devopelastichayway/cover-wow-service-mesh-istio-1200x630.webp (alt : Istio service mesh — sidecar Envoy, mTLS et Gateway API)
  • Catégorie : Kubernetes / Platform · Niveau : Intermédiaire
  • Slug / URL : wow-service-mesh-istio → /tutoriels/wow-service-mesh-istio/
  • Region lab / prod : ca-central-1
  • Parent WP : tutoriels (5463) · Statut : GO — push Maître WP-CLI

← Catalogue Tutoriels

Pour aller plus loin — hubs live

Retour parcours Catalogue Tutoriels — hub de la série et leçons sœurs.

© 2023 devopelastichayway.com All rights reserved.