Passer au contenu principal

Réseau (Kubernetes)

Service Mesh

Un service mesh ajoute une couche d'infrastructure dédiée à la communication inter-services : chiffrement mTLS transparent, observabilité L7 fine (latences par route, taux d'erreur), traffic management avancé (canary, circuit breaker, retries). Il ne remplace pas les NetworkPolicies mais les complète pour les flux applicatifs.

Pourquoi un service mesh

Sans service mesh, implémenter le mTLS, les retries et le circuit breaking demande du code dans chaque application. Un service mesh déplace cette logique dans le plan de données (proxies sidecar) et le plan de contrôle, sans modifier le code applicatif.

Un service mesh n'est pas nécessaire pour tous les clusters. Les cas qui le justifient :

  • Exigences de sécurité zero-trust inter-services (mTLS obligatoire)
  • Besoin de traces distribuées et de métriques L7 par route HTTP
  • Traffic management avancé (canary deployments, A/B testing, fault injection)
  • Clusters avec de nombreux microservices et équipes

Istio

Istio est le service mesh le plus complet et le plus utilisé en entreprise. Il injecte un proxy Envoy comme sidecar dans chaque pod (ou utilise le mode ambient mesh sans sidecar, GA en 1.22). Plan de contrôle : istiod.

# Installer Istio (CLI istioctl)
istioctl install --set profile=default
kubectl label namespace production istio-injection=enabled

# Vérifier les sidecars
kubectl get pods -n production   # 2/2 READY = conteneur + sidecar Envoy

# Dashboard Kiali (observabilité service mesh)
istioctl dashboard kiali
# Traffic management : canary 10% vers v2
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: web
spec:
  hosts: ["web-service"]
  http:
  - route:
    - destination:
        host: web-service
        subset: v1
      weight: 90
    - destination:
        host: web-service
        subset: v2
      weight: 10

Linkerd

Plus léger qu'Istio, plus simple à opérer. Proxy écrit en Rust (linkerd2-proxy). mTLS automatique, métriques L7, tap (inspection du trafic en temps réel). N'implémente pas toutes les fonctionnalités d'Istio mais couvre 80% des besoins avec moins de complexité opérationnelle.

linkerd install --crds | kubectl apply -f -
linkerd install | kubectl apply -f -
linkerd check
kubectl annotate namespace production linkerd.io/inject=enabled

Ambient Mesh (Istio)

Le mode ambient (GA Istio 1.22+) élimine les sidecars : un agent ztunnel par noeud gère le mTLS L4, et des waypoint proxies optionnels gèrent le L7. Réduit significativement la consommation mémoire et CPU par rapport au modèle sidecar.

istioctl install --set profile=ambient
kubectl label namespace production istio.io/dataplane-mode=ambient

Quand éviter un service mesh

  • Cluster de moins de 10 services : les NetworkPolicies + mTLS applicatif suffisent
  • Équipe sans expertise réseau/Envoy : la courbe d'apprentissage d'Istio est significative
  • Contraintes de ressources fortes : chaque sidecar Envoy consomme ~50-100Mo RAM

Sources