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-1Slug :
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) aveckubectladmin - Bases pods / Services / Deployments — Architecture Kubernetes · Homelab k3s
- Accès sortant HTTPS pour CLI et charts Linkerd
- Optionnel : profil AWS
laben ca-central-1 — Dé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 :
- Schéma control plane + sidecar + mTLS
- Preuve
edgessecured +stat - Incident : kill backend → effet visible dans viz
- Trade-off écrit vs Istio
- Teardown EKS
ca-central-1documenté
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
- Istio service mesh
- Kubernetes Gateway API
- Argo CD GitOps
- Homelab k3s
- Concepts EKS
- OpenTelemetry
- Architecture Kubernetes
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
Pour aller plus loin — hubs live
Retour parcours Catalogue Tutoriels — hub de la série et leçons sœurs.