Conteneur sidecar
Un conteneur auxiliaire qui tourne dans le même pod que l'application principale et l'étend — journalisation, proxy, sécurité — sans que l'application elle-même ait à changer. Le patron central des service meshes.
Mécanisme : les conteneurs d'un même pod partagent le réseau (même IP/localhost) et peuvent partager des volumes, ce qui permet à un sidecar de capter le trafic de l'application principale ou de lire ses journaux de façon transparente. Cas d'usage classiques : un proxy Envoy qui gère tout le trafic entrant et sortant (un service mesh comme Istio/Linkerd), un collecteur de logs qui les transfère, ou un conteneur qui va chercher des secrets. Gain : séparation des responsabilités — l'appli se concentre sur sa logique, le sidecar prend en charge les besoins transverses, et on peut les mettre à jour indépendamment. Contrepartie : plus de conteneurs = plus de surcoût en ressources par pod, ce qui a fait naître les meshes « sans sidecar » (eBPF) et la prise en charge native des sidecars dans Kubernetes (sous forme d'init container avec une restartPolicy). Un patron fondateur de l'architecture cloud-native. Voir aussi sidecar de service mesh et init container.