Sommaire

Objectifs du chapitre et prérequis

Lors des précédents chapitres, le lecteur a appris à consulter les journaux d’activité des containers. Il a également appris qu’un container avait une durée de vie particulièrement courte.

En réalité, un simple crash aboutira à la création d’un nouveau container et l’impossibilité de consulter le journal d’activité qui aurait pu expliquer ce crash. Pour parer à cette éventualité, Kubernetes offre la possibilité de centraliser les journaux d’activité.

Les différentes solutions natives aux services managés seront étudiées :

  • Google Stackdriver,

  • Azure Monitor,

  • Amazon Cloudwatch.

Dans le cas de Google et Azure, ces solutions sont préconfigurées à la création du cluster. Dans le cas d’Amazon, une proposition de solution sera étudiée avec le service Cloudwatch.

Dans le cas d’un cluster hébergé (on premise), le lecteur se verra présenter deux solutions :

  • Loki (développé par la société du logiciel Grafana),

  • Elasticsearch.

Les deux solutions autour de Loki et Elasticsearch ont chacune leurs inconvénients et avantages. Elles seront évoquées un peu plus loin dans la section dédiée à la mise en place de Loki.