Dans Kubernetes, la règle c’est un pod = un container.
Quand il y a plusieurs containers, les containers « secondaires » sont d’ailleurs appelés des « sidecars » et leur rôle est plutôt d’accompagner le container principal.
Par exemple, dans un pod tu pourrais avoir ton application et un exporter Prometheus.
Autre exemple, dans mes pods prometheus et alertmanager, j’ai un sidecar « reloader » qui surveille les changement sur certains fichiers et fait l’équivalent d’un kill -HUP sur Prometheus ou Alertmanager.
L’exemple le plus courant (mais plus compliqué à expliquer), c’est les « service mesh » et notamment istio, qui crées des sidecar automatiquement pour leurs propres besoins.
Par contre, une application et sa base de données, c’est deux pods différents. Ça te permet de leur donner des droits différents, de limiter les ressources (CPU, RAM) différemment, d’avoir de l’autoscale sur le frontend, etc.
[^] # Re: pod
Posté par Anonyme . En réponse au journal Docker vs Podman sur fedora 32 et headless CMS. Évalué à 10. Dernière modification le 18 octobre 2020 à 03:07.
Dans Kubernetes, la règle c’est un pod = un container.
Quand il y a plusieurs containers, les containers « secondaires » sont d’ailleurs appelés des « sidecars » et leur rôle est plutôt d’accompagner le container principal.
Par exemple, dans un pod tu pourrais avoir ton application et un exporter Prometheus.
Autre exemple, dans mes pods prometheus et alertmanager, j’ai un sidecar « reloader » qui surveille les changement sur certains fichiers et fait l’équivalent d’un
kill -HUPsur Prometheus ou Alertmanager.L’exemple le plus courant (mais plus compliqué à expliquer), c’est les « service mesh » et notamment istio, qui crées des sidecar automatiquement pour leurs propres besoins.
Par contre, une application et sa base de données, c’est deux pods différents. Ça te permet de leur donner des droits différents, de limiter les ressources (CPU, RAM) différemment, d’avoir de l’autoscale sur le frontend, etc.