Kubernetes multicontainers
| Fiche express | |
|---|---|
| Type | Patterns de Pods à plusieurs conteneurs |
| Patterns courants | Sidecar · Init container |
| Partage | Réseau (une IP par Pod) · volumes (optionnel) |
| Voir aussi | Kubernetes · Kubernetes deployments · Kubernetes staticPods |
Un Pod peut contenir plusieurs conteneurs étroitement couplés plutôt qu'un seul. Ils partagent alors le même espace de noms réseau (donc la même IP et le même espace de ports) et, si le manifeste le prévoit, des volumes communs — c'est ce qui permet à deux conteneurs d'un même Pod de communiquer en local ou d'échanger des fichiers sans passer par le réseau du cluster.
Le pattern sidecar
Le sidecar est un conteneur secondaire ajouté à côté du conteneur applicatif principal dans le même Pod, pour lui apporter une fonction transverse (collecte de logs, synchronisation de fichiers, proxy réseau...) sans modifier le conteneur principal lui-même. C'est le pattern qu'utilisent par exemple les proxys de service mesh comme Envoy injectés par Istio.
kubectl create -f multi-container-pod.yml
kubectl get pod multi-container-pod
kubectl create -f sidecar-pod.yml
kubectl logs sidecar-pod -c sidecar
L'option -c précise le conteneur ciblé dans un Pod qui en contient plusieurs, aussi bien pour kubectl logs que pour kubectl exec (voir Kubectl).
Init containers
Un init container est un conteneur qui démarre et se termine avant que les conteneurs applicatifs du Pod ne soient lancés. Il sert typiquement à des tâches de préparation (attente d'une dépendance, initialisation de données, vérification de configuration) qu'on préfère isoler du conteneur principal.
kubectl create -f init-pod.yml
kubectl get pod init-pod
Un Pod peut définir plusieurs init containers, exécutés séquentiellement ; le conteneur applicatif ne démarre qu'une fois tous les init containers terminés avec succès.