Kubernetes 011 – Pods : les multi-conteneurs, sidecars, adapters et ambassadors

TL;DR

Un pod multi-conteneurs sert a faire vivre ensemble des processus fortement couples. Le sidecar ajoute une capacite a l’application principale, l’adapter transforme une interface ou des donnees, l’ambassador simplifie l’acces a un service externe. Tous partagent le reseau et le cycle de vie du pod.

La video de reference

Video: https://www.youtube.com/watch?v=33HwfEGifyc

Elle approfondit le modele du pod en montrant qu’il peut encapsuler plus qu’un conteneur applicatif.

Pourquoi plusieurs conteneurs dans un pod ?

La regle generale reste simple: un pod doit contenir des conteneurs qui doivent etre colocalises. S’ils peuvent vivre separement, mieux vaut les separer dans des pods differents.

Les conteneurs d’un meme pod partagent l’IP du pod, les volumes declares et un cycle de vie lie. C’est utile pour des fonctions transverses comme proxy, collecte de logs, synchronisation ou adaptation de protocole.

Les patterns classiques

| Pattern | Idee |

|---|---|

| Sidecar | ajouter une fonction autour de l'application principale |

| Adapter | transformer une sortie ou une interface |

| Ambassador | representer un service externe localement |

Exemple simplifie

apiVersion: v1
kind: Pod
metadata:
  name: app-sidecar
spec:
  containers:
    - name: app
      image: nginx
    - name: sidecar
      image: busybox
      command: ["sh", "-c", "while true; do sleep 30; done"]

Liens utiles

• Video: https://www.youtube.com/watch?v=33HwfEGifyc
• Pods: https://kubernetes.io/docs/concepts/workloads/pods/
• Sidecar containers: https://kubernetes.io/docs/concepts/workloads/pods/sidecar-containers/
• Init containers: https://kubernetes.io/docs/concepts/workloads/pods/init-containers/

FAQ

Faut-il mettre tous les services d’une application dans un meme pod ?

Non. Un pod multi-conteneurs est reserve aux conteneurs fortement couples.

Les conteneurs partagent-ils le meme port ?

Ils partagent le meme namespace reseau. Deux conteneurs ne peuvent donc pas ecouter le meme port dans le meme pod.

Un sidecar peut-il etre remplace par un service separe ?

Parfois oui. Le choix depend du couplage, du besoin de colocalisation et du cycle de vie.

Quand le multi-conteneurs est une bonne idee

Un pod multi-conteneurs est pertinent quand les conteneurs forment une unite operationnelle. Par exemple, une application qui ecrit des fichiers dans un volume partage et un sidecar qui les synchronise. Ou une application qui expose des metriques dans un format brut et un adapter qui les transforme.

Le critere simple est le suivant: si les deux conteneurs doivent etre deployes, planifies et supprimes ensemble, le meme pod peut se justifier. Sinon, il faut envisager des pods separes relies par un Service.

Observer les logs de chaque conteneur

Dans un pod multi-conteneurs, kubectl logs doit savoir quel conteneur lire:

kubectl logs app-sidecar -c app
kubectl logs app-sidecar -c sidecar
kubectl describe pod app-sidecar

Cette distinction devient essentielle en debug. Un pod peut etre en erreur a cause d’un seul conteneur, alors que l’autre fonctionne.

Volumes partages

Les volumes sont souvent le point de liaison entre conteneurs d’un meme pod:

volumes:
  - name: shared
    emptyDir: {}
containers:
  - name: app
    volumeMounts:
      - name: shared
        mountPath: /data
  - name: sidecar
    volumeMounts:
      - name: shared
        mountPath: /data

emptyDir vit avec le pod. Quand le pod disparait, le contenu disparait aussi. C’est parfait pour certains usages temporaires, pas pour de la persistance durable.

Erreurs frequentes

• Utiliser un sidecar pour masquer une application mal decoupee.
• Oublier que tous les conteneurs partagent la meme IP.
• Ne pas specifier le conteneur avec kubectl logs -c.
• Mettre dans le meme pod des services qui devraient scaler differemment.

A retenir

Le pod multi-conteneurs est un outil de composition locale. Il ne remplace pas l’architecture applicative. Il doit rester lisible: un role principal, des roles auxiliaires bien identifies.

Sidecar ou init container ?

Un sidecar vit en meme temps que le conteneur principal. Un init container, lui, s’execute avant les conteneurs applicatifs puis se termine. Le choix depend donc du besoin.

Si le conteneur auxiliaire doit preparer un fichier, attendre une dependance ou effectuer une initialisation ponctuelle, un init container est souvent plus adapte. Si le conteneur doit rester actif pour collecter des logs, synchroniser des fichiers, exposer un proxy ou enrichir le comportement de l’application, le sidecar est plus logique.

Impact sur le debug

Plus il y a de conteneurs dans un pod, plus le diagnostic demande de precision. Il faut savoir quel conteneur redemarre, lequel produit les logs utiles et lequel porte le port expose. Les commandes doivent donc etre explicites:

kubectl get pod app-sidecar -o jsonpath='{.status.containerStatuses[*].name}'
kubectl logs app-sidecar -c app
kubectl logs app-sidecar -c sidecar
kubectl describe pod app-sidecar

Cette approche evite de conclure que "le pod est casse" alors qu’un seul conteneur auxiliaire est en erreur.

Scalabilite et responsabilites

Un piege courant consiste a mettre ensemble deux composants qui n’ont pas le meme rythme de vie. Si l’application principale doit scaler a dix replicas mais que le composant auxiliaire devrait etre unique ou mutualise, le sidecar n’est peut-etre pas le bon choix.

Le multi-conteneurs doit rester une decision de proximite: meme noeud, meme IP, meme cycle de vie, meme besoin operationnel. Si le lien est seulement logique ou fonctionnel, un Service separe est souvent plus clair.

Notions et definitions

• Pod: plus petite unite deployable dans Kubernetes.
• Controleur: objet qui maintient un etat attendu, comme Deployment, ReplicaSet, DaemonSet ou StatefulSet.
• Reconciliation: boucle permanente qui compare l’etat reel et l’etat desire.

Ces definitions donnent le vocabulaire minimal pour suivre l’article sans reduire Kubernetes a une simple commande. Chaque notion doit etre reliee a un objet visible avec kubectl ou a un composant du cluster.

Exemple concret

Un Deployment a trois replicas recree automatiquement un pod supprime afin de revenir a l’etat attendu declare dans sa specification.

Cet exemple sert de fil conducteur: il montre quel probleme operationnel Kubernetes cherche a resoudre et quelle ressource permet de le formaliser.

How-to rapide

• Declarer le workload avec un manifest YAML ou une commande kubectl.
• Observer les pods crees et leurs labels.
• Lire les events pour comprendre scheduling, pulls d’images et redemarrages.
• Modifier le controleur plutot que les pods generes directement.

Le how-to est volontairement court: l’idee est d’obtenir un resultat observable, puis d’utiliser les commandes de verification pour comprendre ce qui s’est passe.

Approfondir cet article

Cet episode doit surtout permettre de maitriser le passage d’un conteneur isole a un workload controle par Kubernetes. L’objectif n’est pas seulement de refaire les commandes, mais de comprendre quel objet Kubernetes est cree, quel composant le prend en charge et comment verifier le resultat.

Questions a se poser

• Quel est l’etat desire exprime dans Kubernetes ?
• Quel composant observe cet etat et tente de le reconciler ?
• Quels symptomes montrent que l’objet est cree mais pas encore operationnel ?
• Quelle commande donne l’information la plus fiable pour diagnostiquer ?

Commandes de verification

• kubectl get pods -o wide --show-labels
• kubectl describe pod <pod> pour lire scheduling, events et conditions
• kubectl rollout history deployment/<name> quand un Deployment est concerne

Ces commandes ne sont pas a apprendre par coeur. Elles servent a construire un reflexe: partir de l’objet Kubernetes, lire son etat, puis descendre vers les pods, les events, les logs ou le noeud uniquement si c’est necessaire.

Points de vigilance

• modifier un pod gere par un controleur au lieu de modifier le controleur lui-meme
• ignorer les events alors qu’ils expliquent souvent le probleme
• oublier que les labels sont le lien entre controleurs, pods et Services

Exercice conseille

Lancez un Deployment nginx a trois replicas, supprimez un pod manuellement, puis observez comment le controleur reconcilie l’etat attendu.

Pour valider la comprehension, gardez une trace courte: manifest utilise, commandes lancees, resultat attendu, resultat observe et correction appliquee. Cette methode rend les episodes suivants beaucoup plus faciles a enchainer.

Lien interne conseille

Pour poursuivre la progression, consultez aussi Kubernetes 012 – Pods : les status, CrashLoopBackOff, Running, Completed.

Conclusion

Les pods multi-conteneurs sont puissants, mais a utiliser avec intention. Ils clarifient certaines architectures, tout en pouvant compliquer le debug si chaque conteneur n’a pas un role net.