Linkerd : mesh léger pour équipes small

À la fin de ce tutoriel, vous aurez Linkerd sur un cluster Kubernetes, un namespace injecté, deux services en mTLS automatique, des métriques linkerd viz, et une grille Linkerd vs Istio pour choisir sans sur-ingénierie.

Niveau : Intermédiaire · Temps estimé : 60–90 min · Versions cibles : Kubernetes 1.28+ · Linkerd stable 2.x · kubectl · Dernière vérification : 2026-09-11 · Region cloud (lab AWS/EKS) : ca-central-1

Slug : wow-linkerd-light · Série : WOW (16/50) · Mot-clé SEO : linkerd mesh · Publish : prêt (feu vert Maître)

← Précédent : Istio service mesh · → Suivant : Kubernetes Gateway API · Aussi : Argo CD · Homelab k3s · Concepts EKS

Prérequis

  • Cluster Kubernetes lab (kind, k3s, ou EKS en ca-central-1) avec kubectl admin
  • Bases pods / Services / Deployments — Architecture Kubernetes · Homelab k3s
  • Accès sortant HTTPS pour CLI et charts Linkerd
  • Optionnel : profil AWS lab en ca-central-1Démarrer avec AWS · Concepts EKS
  • Coût : kind/k3s ~0 € ; EKS = control plane + nœuds — teardown le jour même
kubectl version --client
kubectl get nodes -o wide
kubectl cluster-info

Ce que nous allons construire

Linkerd light mesh (WOW 16/50)
  ├── CLI + pre-checks
  ├── Control plane + viz
  ├── Namespace demo injecté
  ├── Frontend ↔ backend (mTLS)
  ├── Stat / tap / retries
  └── Comparaison Istio + teardown

(Schéma — alt : « Linkerd control plane, proxies sidecar, mTLS entre pods, dashboard viz ».)

Objectif : un mesh que vous savez expliquer — pourquoi Linkerd, comment l’injecter, comment prouver le mTLS, quand rester sur Istio.

Étape 1 — Pourquoi Linkerd pour une petite équipe ?

Un service mesh ajoute mTLS, observabilité et fiabilité (retries, timeouts) sans réécrire les apps. Le piège : une pile trop lourde pour l’équipe.

Option Footprint Courbe Idéal pour
Pas de mesh Minimal Nulle 1–2 services, TLS au bord
Linkerd Léger (proxy Rust) Douce Small/mid teams, mTLS by default
Istio Plus riche / lourd Raide Multi-cluster, L7 avancé — Istio

Pitch DEH : « Linkerd pour mTLS et golden metrics sans un second métier Istio. »

Étape 2 — CLI et pre-checks

Vérifiez l’URL du jour sur linkerd.io :

curl --proto '=https' --tlsv1.2 -sSfL https://run.linkerd.io/install | sh
export PATH="$HOME/.linkerd2/bin:$PATH"
linkerd version --client
linkerd check --pre

Corrigez tout Error avant le control plane (CNI, RBAC, version API).

Étape 3 — Control plane + viz

linkerd install --crds | kubectl apply -f -
linkerd install | kubectl apply -f -
linkerd check
linkerd viz install | kubectl apply -f -
linkerd viz check
linkerd viz dashboard &
# Port-forward local uniquement — jamais 0.0.0.0/0

Sur EKS ca-central-1, tags Owner=lab, Project=linkerd-wow, teardown noté dans le README.

Étape 4 — Namespace injecté + apps demo

kubectl create namespace demo
kubectl annotate namespace demo linkerd.io/inject=enabled
# manifests/demo-mesh.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: backend
  namespace: demo
spec:
  replicas: 2
  selector:
    matchLabels: { app: backend }
  template:
    metadata:
      labels: { app: backend }
    spec:
      containers:
        - name: backend
          image: buoyantio/bb:v0.0.5
          args: ["terminus", "--grpc-server-port", "8080", "--response-text", "hello-from-backend"]
          ports:
            - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: backend
  namespace: demo
spec:
  selector: { app: backend }
  ports:
    - name: grpc
      port: 8080
      targetPort: 8080
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: frontend
  namespace: demo
spec:
  replicas: 1
  selector:
    matchLabels: { app: frontend }
  template:
    metadata:
      labels: { app: frontend }
    spec:
      containers:
        - name: frontend
          image: buoyantio/bb:v0.0.5
          args:
            - "terminus"
            - "--http-server-port"
            - "8080"
            - "--grpc-proxy-port"
            - "9000"
            - "--backend-host"
            - "backend.demo.svc.cluster.local:8080"
            - "--response-text"
            - "hello-from-frontend"
          ports:
            - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: frontend
  namespace: demo
spec:
  selector: { app: frontend }
  ports:
    - name: http
      port: 8080
      targetPort: 8080
kubectl apply -f manifests/demo-mesh.yaml
kubectl -n demo get pods
# Attendu : 2/2 (app + linkerd-proxy)

Alternative : démo emojivoto (curl -sL https://run.linkerd.io/emojivoto.yml | linkerd inject - | kubectl apply -f -).

Étape 5 — Prouver le mTLS et observer

linkerd viz edges -n demo
linkerd viz stat deploy -n demo
linkerd viz tap deploy/frontend -n demo --to deploy/backend

Attendu : arêtes secured, RPS/latences visibles — mTLS sans certificats manuels côté app.

kubectl -n demo run -it --rm curl --image=curlimages/curl --restart=Never -- 
  curl -s http://frontend.demo.svc.cluster.local:8080/

Étape 6 — Retries et timeouts

ServiceProfile minimal (adaptez le DNS du Service) :

apiVersion: linkerd.io/v1alpha2
kind: ServiceProfile
metadata:
  name: backend.demo.svc.cluster.local
  namespace: demo
spec:
  routes:
    - name: grpc-default
      condition:
        method: POST
        pathRegex: "/.*"
      timeout: 300ms
      isRetryable: true
kubectl apply -f manifests/backend-profile.yaml
linkerd viz routes deploy/frontend -n demo --to deploy/backend

Documentez timeout, pourquoi retryable, et ce qui ne se retry pas (POST non-idempotents). Ce trade-off compte en entretien.

Étape 7 — Linkerd vs Istio

Critère Linkerd Istio
Footprint Faible Plus élevé
mTLS Excellent, simple Excellent, plus de knobs
Traffic L7 Pragmatique Très riche
Ops day-2 Moins de surface Plus de CRDs
Multi-cluster Possible Mature
Équipe 2–5 Souvent le bon défaut Si features Istio nécessaires

Istio si plateforme et compétences déjà là — lab Istio. Sinon Linkerd livre l’essentiel mesh avec moins de charge mentale.

Étape 8 — GitOps, preuves, teardown

Versionnez manifests + linkerd.io/inject ; Argo CD rend le mesh déclaratif — Argo CD. Corrélez avec OpenTelemetry — OTel.

Checklist entretien :

  1. Schéma control plane + sidecar + mTLS
  2. Preuve edges secured + stat
  3. Incident : kill backend → effet visible dans viz
  4. Trade-off écrit vs Istio
  5. Teardown EKS ca-central-1 documenté

En production small-team, ajoutez progressivement : Policy Validator (évite les configs invalides), alertes sur taux d’erreurs proxy, et une règle « tout nouveau Deployment passe par un namespace injecté ». Évitez d’activer dix extensions le jour 1 — livrez d’abord mTLS + viz + une app métier, puis itérez.

kubectl delete ns demo --ignore-not-found
linkerd viz uninstall | kubectl delete -f - --ignore-not-found
linkerd uninstall | kubectl delete -f - --ignore-not-found

EKS : delete cluster/nodegroups le jour même, tags Owner=lab.

Coûts

Poste Ordre de grandeur
kind / k3s ~0 €
Control plane Linkerd CPU/RAM modestes
EKS ca-central-1 control plane + nœuds — delete same day
Dashboard public ne pas exposer

Erreurs fréquentes

Symptôme Cause Correction
check --pre rouge CNI / privileges Lire le message ; patcher le lab
Pods 1/1 sans proxy Annotation absente Inject + restart pods
Edges not secured Un côté hors mesh Injecter les deux
Dashboard down Port-forward mort Relancer viz dashboard
CrashLoop proxy Ressources / CNI logs -c linkerd-proxy
Bill EKS Oubli teardown Delete + alarmes billing

Quiz (5 questions)

1. Linkerd apporte surtout, pour une small team :
– A. Un remplacement de Git
– B. mTLS + observabilité + retries sans réécrire les apps
– C. Un CDN global

2. linkerd.io/inject=enabled sur un namespace :
– A. Désactive le mesh
– B. Injecte le sidecar sur les nouveaux pods
– C. Crée un Ingress

3. Preuve rapide du mTLS :
– A. Un ping ICMP
– B. linkerd viz edges (trafic secured)
– C. Un screenshot CloudWatch seul

4. Region lab DEH pour un EKS de test :
– A. us-east-1
– B. ca-central-1
– C. ap-south-1

5. Préférer Istio quand :
– A. On veut zéro YAML
– B. Features L7 / multi-cluster riches et équipe compétente
– C. On a un seul pod

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

FAQ

Linkerd remplace-t-il Ingress / Gateway API ?

Non. Linkerd couvre l’est-ouest. Le nord-sud reste Ingress, Gateway API ou LB — Gateway API.

Istio et Linkerd ensemble ?

Presque jamais sur le même cluster pour une small team. Un mesh, un pourquoi.

Kind / k3s suffisent-ils ?

Oui pour CLI, inject, viz, mTLS. Validez sur EKS ca-central-1 si le poste est cloud.

Le proxy consomme beaucoup ?

Footprint bas (Rust). Surveillez quand même sous charge avec viz stat.

Qui gère les certificats mTLS ?

Linkerd gère identité et rotation. Pas de certs app manuels pour le mesh de base.

Peut-on injecter seulement certains Deployments ?

Oui : annotation au niveau pod template / Deployment plutôt que namespace entier. Utile pour migrer service par service sans big-bang.

Pourquoi ca-central-1 ?

Standard DevOps Elastic Hayway pour les labs cloud.

Pour aller plus loin

Maillage série WOW

← Précédent Istio service mesh (WOW 15)
→ Suivant Kubernetes Gateway API (WOW 17)
Aussi Argo CD · Homelab k3s · EKS concepts

Meta publication (SEO) — feu vert Maître (auto-push WP-CLI)

  • Title SEO : Linkerd : mesh léger pour équipes small (guide FR Kubernetes)
  • Meta description (≤ 160) : Installez Linkerd sur Kubernetes : mTLS auto, inject proxy, viz, retries. Mesh léger vs Istio pour petites équipes. Lab ca-central-1, FAQ DEH.
  • Focus keyword : linkerd mesh
  • Secondary : linkerd kubernetes, service mesh léger, linkerd vs istio, mTLS kubernetes, linkerd viz
  • Image : assets/web/devopelastichayway/cover-wow-linkerd-light-1200x630.webp (à générer)
  • Cover alt : Linkerd service mesh léger avec proxies sidecar et mTLS sur Kubernetes
  • Catégorie : WOW / Kubernetes · Niveau : Intermédiaire
  • Schema : HowTo + FAQPage + Article
  • URL cible : https://devopelastichayway.com/tutoriels/wow-linkerd-light/
  • Statut : draft box prêt — publish WP-CLI parent /tutoriels/ (5463)
  • Region lab : ca-central-1

← Catalogue Tutoriels

Pour aller plus loin — hubs live

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