Linkerd : un service mesh ultra-léger pour Kubernetes

Le service mesh est devenu un classique des architectures Kubernetes : mTLS automatique, observabilité L7, retries et timeouts déclaratifs, traffic shifting. Istio reste la référence riche en fonctionnalités, mais sa complexité et son coût en ressources rebutent. Linkerd s'est imposé comme l'alternative ultra-légère, construite autour d'un proxy Rust dédié plutôt qu'Envoy.

Cet article présente l'architecture Linkerd, le compare à Istio sur des critères pratiques, détaille la mise en place du mTLS automatique, et clarifie un point crucial souvent mal compris : depuis 2024, le projet open source ne publie plus de releases stables, seules les edge releases hebdomadaires sont disponibles côté open source. Ce qui change la stratégie d'adoption.

• Qu'est-ce que Linkerd
• Architecture : proxy Rust, control plane minimaliste
• mTLS automatique
• Observabilité et traffic management
• Comparaison Linkerd vs Istio
• Le modèle de release depuis 2024
• Cas d'usage pertinents

Linkerd est un service mesh open source, projet diplômé de la CNCF. Le code est distribué sous licence Apache 2.0. Son slogan ("ultralight, security-first service mesh") résume son positionnement : faire le minimum nécessaire pour mTLS, observabilité et fiabilité, sans la complexité d'Istio.

Le projet a été initié par Buoyant en 2016. La version 2.x (réécrite en Go + Rust en 2018) est celle utilisée aujourd'hui ; la v1 (Scala) est dépréciée et n'est plus maintenue.

Côté distribution :

• Open source : releases edge hebdomadaires (par exemple edge-26.5.1 en mai 2026). Ce sont les binaires officiels du projet.
• Stable releases : produites par Buoyant sous le nom Buoyant Enterprise for Linkerd. La dernière en date est la 2.19 (octobre 2025), avec des points de patch successifs.

Trois choix structurent le projet :

1. Un proxy dédié, écrit en Rust (linkerd2-proxy). Pas Envoy. Empreinte mémoire et CPU drastiquement plus basses, surface d'attaque réduite, latence prédictible.
2. Un control plane minimaliste. Pas de DSL ambitieux ni de cas d'usage exotiques natifs : retries, timeouts, mTLS, métriques. Le reste relève d'un autre outil.
3. Une expérience opérationnelle simple. Installation en une commande, mTLS automatique sans configuration, métriques Prometheus prêtes à l'emploi.

Linkerd suit le modèle classique d'un mesh : un proxy sidecar injecté dans chaque pod, un control plane qui orchestre les sidecars.

Le proxy (linkerd2-proxy) est écrit en Rust pour des raisons de sécurité mémoire et d'efficacité. Il intercepte le trafic entrant et sortant du pod via les iptables injectées par l'init container. Toute la communication entre pods meshés passe par les proxies, qui établissent automatiquement des connexions mTLS.

Le control plane se compose de quelques services Go :

• destination : sert la liste des endpoints disponibles aux proxies.
• identity : autorité de certification interne, émet les certificats mTLS aux proxies.
• proxy-injector : webhook qui injecte le sidecar lors de la création des pods.

Optionnellement, on installe les extensions :

• linkerd-viz : observabilité (Prometheus, Grafana, dashboard web).
• linkerd-multicluster : fédération de plusieurs clusters.
• linkerd-jaeger : intégration tracing.

# Installer le control plane (avec edge release)
linkerd install --crds | kubectl apply -f -
linkerd install | kubectl apply -f -

# Installer l'observabilité
linkerd viz install | kubectl apply -f -

# Vérifier l'installation
linkerd check

Pour mesher un namespace, on annote le namespace ou les déploiements :

apiVersion: v1
kind: Namespace
metadata:
  name: my-app
  annotations:
    linkerd.io/inject: enabled

À la prochaine création/mise à jour de pod, le sidecar est injecté.

Le mTLS est probablement la fonctionnalité la plus mise en avant par Linkerd, et la plus simple à activer. Aucune configuration n'est nécessaire au-delà de l'injection : dès qu'un pod est meshé, ses communications sortantes vers d'autres pods meshés sont automatiquement chiffrées et authentifiées en mTLS.

Le mécanisme :

1. À l'injection, le proxy reçoit une identité signée par identity (CA interne).
2. Lors d'une connexion sortante, le proxy détecte que le destinataire est aussi meshé.
3. La poignée de main TLS s'effectue avec validation mutuelle des certificats.
4. Les certificats sont rotés automatiquement (durée de vie de 24h par défaut).

Le résultat : tout le trafic intra-mesh est chiffré et authentifié, sans modification d'application, sans gestion manuelle de certificats.

# Vérifier le statut mTLS d'un déploiement
linkerd viz tap deploy/my-app

# Visualiser les routes et leur état mTLS
linkerd viz routes deploy/my-app -o wide

L'identité injectée dans chaque proxy est compatible SPIFFE depuis la 2.15, ce qui ouvre l'interopérabilité avec d'autres systèmes basés sur SPIFFE.

L'extension linkerd-viz ajoute Prometheus + Grafana et expose trois métriques golden signals par service :

• Success rate : pourcentage de requêtes 2xx/3xx.
• Request rate : RPS.
• Latency : p50, p95, p99.

Ces métriques sont calculées par le proxy lui-même, sans modification d'application. Le dashboard web (linkerd viz dashboard) en offre une vue immédiate.

Pour le traffic management, Linkerd s'appuie sur les ressources standard Kubernetes :

• HTTPRoute (Gateway API) ou ServiceProfile (legacy Linkerd).
• Retries, timeouts, traffic splitting déclaratifs.

Exemple de retry policy :

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: api-route
  namespace: my-app
spec:
  parentRefs:
    - name: api
      kind: Service
      group: ''
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /
      timeouts:
        request: 5s
        backendRequest: 1s

Linkerd applique ces politiques au niveau du proxy sortant, sans configuration côté serveur.

Le choix entre les deux dépend de critères concrets :

Pour un cluster qui veut mTLS, métriques et fiabilité de base sans casse-tête, Linkerd gagne sur la simplicité et le coût en ressources. Pour un mesh qui doit gérer du multi-protocole avancé, des extensions WASM, des politiques d'autorisation fines, ou de l'ingress geo-distribué, Istio reste le choix le plus complet.

Point critique souvent mal compris : depuis février 2024, le projet open source Linkerd ne publie plus de tags stable-2.x.y. Le modèle est devenu :

• Open source : edge releases hebdomadaires uniquement. Considérées comme stables-de-facto par l'équipe, mais sans support long terme ni patches CVE rétroactifs.
• Buoyant Enterprise for Linkerd : releases stables LTS, patches de sécurité, support commercial. C'est désormais le seul chemin officiel pour des binaires "stables" tels que définis avant 2024.

Conséquences pratiques :

• Pour de la production qui exige un cycle de patches sécurité prévisible, l'option commerciale Buoyant est désormais la voie naturelle.
• Pour un environnement où l'on suit les edge releases régulièrement (rolling weekly), l'open source reste pleinement utilisable.
• Pour des organisations qui veulent figer une version 2 ans, il faut soit s'engager auprès de Buoyant, soit accepter de courir après les patches CVE manuellement.

Cette évolution a fait débat dans la communauté. Elle reflète une réalité : maintenir des branches LTS open source coûte cher en ingénierie. Le modèle adopté par Linkerd est désormais proche de ce qu'on voit chez d'autres projets (Red Hat sur Keycloak, Elastic). À chacun d'évaluer le compromis selon son contexte.

Linkerd brille particulièrement dans plusieurs contextes.

Mesh par défaut dans des clusters multi-tenants

Pour une plateforme Kubernetes qui héberge plusieurs équipes ou clients et veut garantir mTLS entre tous les services par défaut, Linkerd est la voie la plus simple. L'injection automatique par namespace permet d'opter in/out par équipe sans toucher au code.

Compliance et zero trust

Pour les exigences zero trust qui imposent du mTLS partout, Linkerd offre la garantie sans engager une architecture Istio plus lourde. L'identité SPIFFE des proxies s'intègre nativement avec les frameworks zero trust modernes.

Observabilité L7 sans modification d'application

Quand on veut des métriques success rate / latency / RPS par service sans instrumenter les applications, le mesh fournit ces données automatiquement. Couplé à un Prometheus existant et à Grafana, le ROI est immédiat.

Multi-cluster fédéré

Linkerd supporte la mesh expansion : fédérer plusieurs clusters Kubernetes (ou même des VMs) dans un même mesh, avec du mTLS automatique entre clusters via une gateway dédiée. Pratique pour relier un cluster on-prem et un cluster cloud sans VPN dédié pour les services.

Fonctionnalités L7 plus restreintes qu'Istio. Si le besoin inclut du routing JWT-based, des transformations protocole avancées, des extensions WASM, Istio reste plus capable.

Ingress Gateway non natif. Linkerd s'appuie sur les Gateway API standards (ou un Ingress controller indépendant : NGINX, Traefik, Contour). Pas de "Linkerd Gateway" équivalent à "Istio Gateway".

Modèle de release OSS exigeant. Suivre les edge weekly demande une discipline. Pour une équipe qui ne peut pas se le permettre, le passage à Buoyant Enterprise est à anticiper budgétairement.

Pas de support multi-protocole exotique. Linkerd se concentre sur HTTP/1.1, HTTP/2, gRPC, TCP générique. Pas de support natif HTTP/3, MQTT ou des protocoles plus rares.

• Istio et le canary deployment
• Cilium et la sécurité réseau eBPF
• Architecture zero trust
• Monitorer un cluster Kubernetes en production
• mTLS entre Nginx et Apache

• Linkerd2 (dépôt GitHub) code, edge releases
• Site officiel Linkerd, documentation, concepts
• Buoyant Enterprise for Linkerd, releases stables commerciales
• Annonce Linkerd 2.15, mesh expansion, native sidecars, SPIFFE
• Clarifications sur le modèle stable 2024, explications du changement

Linkerd est aujourd'hui le service mesh le plus léger et le plus simple à opérer pour un cluster Kubernetes qui cherche du mTLS automatique et une observabilité de base. Son proxy Rust dédié offre un avantage net sur le coût en ressources comparé à Istio. La contrepartie est un périmètre fonctionnel plus restreint et un modèle de release open source qui pousse vers la version Enterprise pour les organisations qui exigent un support commercial. Pour des cas d'usage plus ambitieux (extensions WASM, multi-protocole, ingress avancé), Istio reste l'option à considérer.