TP25 : Service mesh avec Linkerd (mTLS, observabilité, répartition du trafic)

Dans un cluster, les services se parlent en HTTP en clair et chaque équipe réimplémente à sa façon les retries, les timeouts et les métriques. Un service mesh confie ces fonctions à une couche d’infrastructure : un proxy placé à côté de chaque Pod chiffre les échanges en mTLS, mesure chaque requête et applique des règles de trafic, sans modifier le code. Ce TP utilise Linkerd, maillage CNCF diplômé, plus léger qu’Istio et adapté à un cluster K3s de lab.

Fichiers de départ : manifests.zip

1. Objectifs pédagogiques

À l’issue du TP, vous serez capable de :

• expliquer l’architecture d’un service mesh (plan de contrôle, plan de données, sidecar) ;
• installer Linkerd, injecter le proxy et vérifier que le trafic est chiffré en mTLS ;
• lire les métriques « dorées » (taux de succès, requêtes par seconde, latence) par service et par route ;
• répartir le trafic entre deux versions avec une HTTPRoute (Gateway API) ;
• configurer retries et timeouts au niveau du maillage ;
• comparer Linkerd, Istio et la livraison progressive d’Argo Rollouts.

Les images de cette page sont des schémas explicatifs, pas des captures d’écran.

2. Environnement du TP

• Le cluster K3s du TP14 (≥ 2 Go de RAM libres).

• Installer les CRD Gateway API (requises par Linkerd), puis la CLI Linkerd (versions edge open source) :

  kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.3.0/standard-install.yaml
  curl --proto '=https' --tlsv1.2 -sSfL https://run.linkerd.io/install-edge | sh
  export PATH=$HOME/.linkerd2/bin:$PATH
  linkerd version --client
  linkerd check --pre

  Depuis 2024, les versions stable de Linkerd sont distribuées par Buoyant ; le projet open source publie des versions edge hebdomadaires, utilisées ici.

3. Partie 1 : Installer Linkerd et l’extension viz

• Installer le plan de contrôle puis l’extension d’observabilité :

  linkerd install --crds | kubectl apply -f -
  linkerd install | kubectl apply -f -
  linkerd check
  linkerd viz install | kubectl apply -f -
  linkerd viz check

• Ouvrir le tableau de bord : linkerd viz dashboard --address 0.0.0.0 & (port 50750).

4. Partie 2 : Injection et mTLS

• Déployer l’application (le namespace porte l’annotation linkerd.io/inject: enabled) :

  kubectl apply -f manifests/00-app.yaml
  kubectl -n tp25 get pods            # 2/2 conteneurs : application + linkerd-proxy
  kubectl -n tp25 logs deploy/frontend -c client --tail=5

• Vérifier que les échanges sont chiffrés et authentifiés :

  linkerd viz -n tp25 edges deployment       # colonne SECURED = √
  linkerd viz -n tp25 tap deploy/frontend    # tls=true sur chaque requête

• Expliquer d’où vient l’identité de chaque proxy (ServiceAccount → certificat de courte durée émis par le composant identity). Pourquoi le mTLS fournit-il à la fois le chiffrement et l’authentification des deux côtés ?

• Déployer un Pod hors maillage dans un autre namespace et appeler http://api.tp25 : la requête passe-t-elle ? Est-elle chiffrée ? (Voir le défi pour l’interdire.)

5. Partie 3 : Métriques « dorées »

• Afficher les métriques sans avoir instrumenté l’application :

  linkerd viz -n tp25 stat deploy
  linkerd viz -n tp25 top deploy/api-v1

• Comparer avec le TP21 : qu’apporte le maillage, et que ne remplace-t-il pas (métriques métier, logs applicatifs, traces internes) ?

6. Partie 4 : Répartition du trafic entre deux versions

• Compléter 10-httproute-split.yaml (90 % v1, 10 % v2), appliquer, puis observer la répartition :

  kubectl apply -f manifests/10-httproute-split.yaml
  kubectl -n tp25 logs deploy/frontend -c client --since=1m | sort | uniq -c
  linkerd viz -n tp25 stat deploy/api-v1 deploy/api-v2

• Passer progressivement à 50/50 puis 0/100, en modifiant uniquement les poids. Comparer avec le canary « par nombre de Pods » d’Argo Rollouts (TP23) : qu’apporte un routeur de trafic ?

7. Partie 5 : Retries et timeouts

• Renommer 20-flaky-retries.yaml.example, remplacer l’image (celle du TP21, qui renvoie 30 % d’erreurs), sans annotation de retry dans un premier temps. Générer du trafic vers http://flaky/api/orders depuis le frontend et relever le taux de succès (linkerd viz -n tp25 stat deploy/flaky).
• Ajouter les annotations de retry et de timeout sur l’HTTPRoute, puis relever à nouveau le taux de succès vu par le client. Expliquer pourquoi les retries ne doivent concerner que des requêtes idempotentes et pourquoi ils peuvent aggraver une panne (retry storm).

8. Partie 6 : Synthèse

• Compléter le tableau :

Défi

1. Imposer une politique d’autorisation Linkerd (Server + AuthorizationPolicy + MeshTLSAuthentication) pour que seule l’identité du ServiceAccount du frontend puisse appeler l’API : le Pod hors maillage de la partie 2 doit être refusé.
2. Lire le mode ambient d’Istio (sans sidecar) et expliquer son intérêt par rapport au modèle sidecar.

9. Livrables

Captures à déposer dans captures/ :

Ainsi que les manifests complétés et le tableau de synthèse.