Objectifs du chapitre et prérequis

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

En réalité, un simple crash aboutira à la création d’un nouveau conteneur 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)
Opensearch/Elasticsearch

Dans le cas où les équipes n’auraient pas de connaissances préliminaires, privilégiez Loki, qui reste plus simple à mettre en œuvre et surtout qui consomme - à...

Principe de la centralisation des journaux

1. Architecture

Principe de fonctionnement de la centralisation de l’activité des différents nœuds

Toutes les solutions qui vont suivre s’appuient sur le même mécanisme :

collecte des journaux d’activités sur chaque nœud à l’aide d’un agent ;
envoi de ces journaux vers un point de stockage centralisé.

Certains clusters sont préconfigurés (c’est généralement le cas des services managés) quand d’autres sont à déployer (c’est le cas d’Amazon ou des clusters installés manuellement).

2. Caractéristiques de l’agent déployé

L’agent en charge de ce travail s’appuie sur un objet DaemonSet. Chaque nœud lance un pod ayant accès aux répertoires de la machine hôte :

Le répertoire /var/lib/docker/containers pour accéder aux logs des conteneurs.
Le répertoire /var/log pour accéder aux logs de la machine.

Le pod garde des fichiers de traces afin de savoir où en est le travail de collecte des logs.

Dans le cas de Fluentd, ces fichiers se présentent sous la forme de fichiers .pos stockés sur la machine principale dans le répertoire /var/log. Ces fichiers de positions sont au format texte et contiennent une ligne par journal où figurent les champs suivants...

Centralisation dans le cloud

1. Centralisation à l’aide d’un service managé

Les fournisseurs de cloud proposent des outils pour centraliser les journaux d’activité. Certains de ces services sont définis nativement à la création du cluster (Google ou Azure) quand d’autres réclament une configuration spécifique (Amazon).

Il s’agit de la solution à privilégier dans un premier temps (surtout lorsque l’intégration est déjà faite par défaut). Attention toutefois à prendre en compte les coûts que peuvent engendrer ce type de solution, d’autant que ces outils n’ont pas toujours la convivialité ou la puissance d’une solution basée sur Loki et Grafana.

2. Google Stackdriver

a. Présentation de Stackdriver

La centralisation des journaux d’activité chez Google se fait à l’aide de l’outil Stackdriver. Par défaut, l’envoi des logs vers ce service est réalisé à la création du cluster.

La centralisation des logs nécessite que l’API Stackdriver soit active. Visitez la page Stackdriver Logging API dans la console Google Cloud.

b. Pod Fluent Bit (cluster GKE)

L’envoi des logs d’un cluster GKE s’appuie sur le logiciel Fluent Bit déployé à l’aide d’un DaemonSet. Les pods associés sont marqués à l’aide du label app=fluent-bit-gke et sont lancés dans l’espace de noms kube-system.

Ci-dessous la commande permettant de consulter ces pods :

$ kubectl -n kube-system get pods -l k8s-app=fluentbit-gke

Ci-dessous un exemple de résultat sur un cluster composé de trois nœuds :

NAME                  READY   STATUS    RESTARTS   AGE  
fluentbit-gke-d8bdg   2/2     Running   0          6d21h  
fluentbit-gke-pwrpw   2/2     Running   0          6d21h  
fluentbit-gke-wgj98   2/2     Running   0          6d21h...

Centralisation des journaux avec Loki

1. Présentation de Loki

a. Origine de Loki

Loki est un outil développé par la société à l’origine de Grafana. Le but de Loki est de proposer un outil semblable à Prometheus, mais à destination des logs.

Tout comme Prometheus, Loki récupère et stocke les labels des pods. Il est également très léger et consomme très peu de ressources (surtout comparé à une solution basée sur Opensearch/Elasticsearch).

Le produit a néanmoins une contrainte : il n’indexe pas le contenu des logs. Il n’y a donc pas possibilité de faire de la recherche textuelle directe.

b. Loki vs Opensearch/Elasticsearch

Ce qui peut paraître un désavantage en fait également sa force. Du fait qu’il n’y a pas de travail d’indexation, le processus de stockage des journaux est très peu gourmand.

Là où un processus Loki consommera moins d’un Go de mémoire, les processus Opensearch/Elasticsearch peuvent faire facilement monter cette valeur à plus de 10 Go de mémoire.

Malgré tout, il ne s’agit pas de savoir si Loki doit remplacer Opensearch/Elasticsearch, mais plutôt d’être conscient de ces avantages et inconvénients. Ne pas oublier par exemple que Loki ne fait pas d’indexation du texte. Pour ce type de besoin, Opensearch/Elasticsearch reste indispensable.

c. Conseil d’utilisation

Du fait de la consommation des labels des pods, la recherche pourra se faire à l’aide de ces derniers.

Une bonne pratique avec cet outil est de déterminer quand a eu lieu l’incident à l’aide de Prometheus puis de basculer sur Loki pour trouver les journaux associés aux problèmes détectés.

2. Installation de Loki

Loki s’installe à l’aide d’un...

Centralisation des journaux avec Opensearch/Elasticsearch

1. Avertissements et limitations

Cette section n’a pas pour vocation de comprendre le fonctionnement global d’Opensearch ou Elasticsearch. Elle ne doit être vue que comme une aide à une mise en œuvre dans Kubernetes.

Vous êtes invité à vous tourner vers la documentation officielle d’Opensearch ou d’Elasticsearch pour respecter les bonnes pratiques.

2. À propos d’Opensearch et d’Elasticsearch

Opensearch est dérivé du projet Elasticsearch. Tous les deux s’appuient sur Lucene pour fonctionner. Ce type de base de données permet de stocker des éléments sous une forme déstructurée. Dans la mise en place de Kubernetes, il peut être utilisé pour centraliser les journaux d’activité des conteneurs.

Par la suite, Opensearch sera déployé (principalement pour des raisons de simplicité), mais les instructions sont tout à fait compatibles avec Elasticsearch.

Pour la suite, la centralisation des journaux se fera à l’aide d’un agent Fluent-bit déployé sur chaque nœud du cluster (d’autres solutions sont possibles avec fluent-bit ou fluentd, par exemple). Le déploiement se fait naturellement avec un objet DaemonSet.

Le déploiement d’Opensearch ou d’Elasticsearch réclame une certaine quantité de ressources. Il est déconseillé de le déployer sur un cluster constitué de nœuds ne disposant pas au moins de 2 CPU et 4 Go de mémoire.

3. Déploiement des briques Opensearch/Elasticsearch

a. Installation d’Opensearch

Dans le cas où vous disposeriez déjà d’un cluster Elasticsearch ou Opensearch externe à Kubernetes, vous pouvez passer à la section suivante.

L’installation d’Opensearch se fera à l’aide du chart Helm opensearch/opensearch. Avant l’installation du chart, ajoutez la source des paquets à l’aide de la commande suivante :

$ helm repo add opensearch \ 
      https://opensearch-project.github.io/helm-charts/

Lancez ensuite l’installation d’Opensearch dans un espace de noms séparé :

$ helm -n opensearch install --create-namespace...

Gestion d’Opensearch/Elasticsearch

1. Utilisation de Kibana/Opensearch Dashboards

a. Accéder à l’interface de Kibana ou Opensearch Dashboards

Les deux interfaces Kibana et Opensearch Dashboards sont similaires.

Afin de se connecter à l’interface d’Opensearch Dashboards, lancez la commande suivante :

$ kubectl -n opensearch port-forward deploy/opensearch-dashboards 5601

Entrez ensuite l’adresse http://localhost:5601 dans un navigateur afin d’accéder à la racine de Kibana/Opensearch Dashboards.

Page d’accueil de Kibana/Opensearch Dashboards à la première connexion

b. Création de l’index

Depuis la page d’accueil, cliquez sur le lien Explore on my own puis procédez à la création de l’index.

Création de l’index d’Opensearch/Elasticsearch

Choix de l’index temporel (par défaut le champ @timestamp)

Contenu de l’index suite à l’initialisation

2. Branchement sur Grafana

a. Source de données Opensearch/Elasticsearch

Grafana est en mesure d’interroger un moteur Opensearch ou Elasticsearch. Tout comme pour Loki, il est possible de passer par un objet ConfigMap avec un champ data contenant le contenu brut d’une déclaration au format YAML.

Ci-dessous une déclaration Grafana valide pour une source de données pointant vers Opensearch/Elasticsearch...

Centralisation des journaux d’activité