Gestion de la log d’un cluster Kubernetes

Kubernetes est l’orchestrateur de containers leader du marché aujourd’hui. Cependant, malgré son immense popularité, certaines intégrations peuvent s’avérer un peu complexe, et il peut être difficile de trouver de la documentation détaillée à son besoin.

C’est en particularité le cas lorsqu’on souhaite obtenir de Kubernetes des informations sur les actions qui sont réalisées par le cluster sur les Pods, les Services, les Réplication Controllers… etc…  afin de répondre à des questions telles que:

       =>  Combien de pods ont été créés cette semaine sur Kubernetes ?

       => Certains services Kubernetes ont-ils été supprimés ?

       => Ai-je une croissance significative de l’activité du cluster Kubernetes ?

L’objectif de ce billet est précisément d’apporter ces réponses techniques en détaillant, étapes par étapes, les actions nécessaires à la collecte des logs du cluster Kubernetes, à leur centralisation sur un outil dédié, puis à la requête de ce dernier pour obtenir les informations recherchées.

Nous parlons bien de la log « d’audit »  de l’apiverser

Entre l’operating system, le runtime container, Kubernetes, les containers eux-mêmes, l’identification et la collecte des logs peut être un vrai casse-tête.

La log qui nous intéresse pour répondre aux questions exprimées plus haut est la log d’audit du cluster Kubernetes… plus exactement, la log des actions réalisées par l’apiserver, module présent sur le master node du cluster…  Or, chose surprenante, cette log n’est pas activée par défaut !!

Il faut configurer le cluster pour activer cette log et cela peut se faire au moment de l’installation du cluster Kubernetes ou en post-install, sur un cluster existant. Ces deux façons sont décrites plus bas.

Comment savoir si mon cluster à la log d’audit activé ?

Le plus simple pour savoir si le logging de l’apiserver est activé sur le cluster Kubernetes est de passer la commande suivante: 

kubectl get cm -o yaml -n kube-system kubeadm-config

Cette commande permet de voir la configuration du cluster et, si la log est activée, vous devriez avoir à minima les deux propriétés suivantes: ‘audit-log-path’ et ‘audit-policy-file’.

L’apiserver est lui-même un pod et il va donc loguer dans son file system à l’intérieur de son pod. Le paramètre « audit-log-path » indique le chemin ou l’apiserver va positionner son fichier dans le file system du pod.

La log peut être très verbeuse, et il est nécessaire de définir une politique de logging conforme à son besoin sans toutefois être trop gourmand. « audit-policy-file » est la propriété qui vous permet de pointer sur la politique de votre choix; chemin vu depuis l’intérieur du pod également.

Configurer le logging de l’apiserver à l’installation ou en vie courante

Pour cela il suffit de positionner les deux paramètres ci-dessus et d’y associer les montages nécessaires pour faire correspondre les chemins vus depuis l’intérieur du pod, aux fichiers présents sur l’OS du node.

Le cluster se configure lors de l’installation initiale lorsqu’on exécute la commande :

 kubeadm init -config [MON_CONFIG_FILE]

Voici un exemple de fichier de configuration pour kubeadm avec en bleu les éléments relatifs au logging :

Ce fichier décrit ainsi que deux volumes seront montés sur l’apiserver :

=> Le premier définit le fichier de policy sur l’OS du master :  /etc/kubernetes/audit-  policies/policy.yaml

=> Le second définit la localisation de la log sur l’OS du master :  /var/log/kubernetes/apiserver/audit.log

A noter qu’on peut également reconfigurer un cluster à postériori. Pour cela il suffit de créer un fichier de configuration compatible avec le cluster (j’invite à conserver la version installée pour ne pas effectuer d’upgrade de version) et de rejouer la configuration, par exemple ainsi:

kubeadm upgrade apply --config [MON_CONFIG_FILE] --ignore-preflight-errors all --force --v=5

Quelle politique d’audit choisir ?

Avant de (re)configurer le cluster, il faut définir la politique d’audit qui est dans /etc/kubernetes/audit-policies/policy.yaml.

Pour commencer et simplement vérifier que tout fonctionne correctement on peut mettre quelque chose de très général.

Par exemple, on log les metadatas de tous les events (et les metadas seuls apportent déjà beaucoup d’nformations…).

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
- level: Metadata
EOF

On pourra ensuite changer cette politique pour la remplacer par une moins verbeuse et optimisée par rapport à son besoin.

Un autre exemple de policy permettant de ne garder que les opérations de ‘create’ et de ‘delete’. Elle permet de limiter davantage encore le volume de log, mais on perd certaines informations.

apiVersion: audit.k8s.io/v1
kind: Policy
# On Ne log pas les stages 'RequestReceived'
omitStages:
  - "RequestReceived"
rules:
  # On ne log pas les verbes (get, list, watch, patch et update....)
  - level: None
    verbs: ["get", "list", "watch", "patch", "update"]
  # Log tout le reste (verbe create et delete) en Level Metadata
  - level: Metadata

Plus d’info sur la policy de logging ici : https://kubernetes.io/docs/tasks/debug-application-cluster/audit/

Vérifier que le logging de l’apiserver fonctionne

Selon les paramètres entrés plus haut dans le fichier de configuration de l’apiserver, la log d’audit est ici :  /var/log/kubernetes/apiserver/audit.log

On doit obtenir quelque chose de similaire :

Comment remplacer une politique de logging en vie courante ?

Remplacer la politique de logging nécessite de mettre à jour le fichier: /etc/kubernetes/audit-policies/policy.yaml, puis de redémarrer l’apiserver.

Il y a plusieurs façons de réaliser cette dernière opération, par exemple:

• En déplaçant aller/retour le fichier de configuration du cluster : 

mv /etc/kubernetes/manifests/kube-apiserver.yaml  /tmp/

  Puis après quelques secondes :

  mv /tmp/kube-apiserver.yaml /etc/kubernetes/manifests/

• Ou en redémarrant le container de l’apiserver :

docker ps | grep apiserver   => pour identifier l’id du container

                    docker restart [id]

Le pod de l’apiserver va redémarrer et prendre en compte la nouvelle configuration. Cela peut prendre quelques dizaines de secondes.

Centraliser les logs et les visualiser

Maintenant que le fichier de log Kubernetes existe sur le master node, nous pouvons en extraire la donnée utile.  Pour cela j’utilise vRealize Log Insight de VMware et je considère dans ce qui suit que le produit est déjà installé.

Cette solution permet de centraliser la log, de la requêter, d’en extraire l’information pertinente et de la présenter sous la forme souhaitée. Quelques exemples de cas d’usage sont : Suivi dans le temps des créations/suppressions des objets Kubernetes (pods, service,…), tracking des erreurs, identifier les intervenants, alerting sur volume, forward vers un outil tier des logs jugées importantes…

Pour cela commençons par installer l’agent Log Insight sur le Kubernetes master pour envoyer les logs vers le serveur de log.

Cela se fait facilement :

1/ Télécharger le rpm (ou .bin ou .deb ou .msi) depuis le server Log Insight

2/ Installer le package

3/ Configurer la communication de l’agent avec le serveur :

     Dans /var/lib/loginsight-agent/liagent.ini.  

a/ Identifier le serveur Log Insight

b/ Mettre le port en fonction du protocole souhaité et de la config ssl

c/ Attention à la config ssl  (‘yes’ ou ‘no’ en fonction de la config du serveur Log Insight)

4/ Redémarrer l’agent log Insight pour la prise en compte :  systemctl restart liagentd

D’autres configurations sont nécessaires : il faudra bien sûr identifier l’emplacement de la log pour indiquer à l’agent quel fichier surveiller.

Ces éléments de configurations supplémentaires (emplacement du fichier de log, parsing, tags additionnels…) peuvent être centralisés coté serveur Log Insight, puis automatiquement poussés sur les clients éligibles (ici notre master Kubernetes).

Ainsi, on définit un « groupe » comme étant une configuration affectée à un ensemble de clients.

Pour notre besoin nous créons un nouveau groupe :

Tous les agents faisant partie de ce groupe hériteront de la configuration du groupe .

Ici nous identifions les clients (agents) qui obtiendront cette configuration. Dans notre cas il s’agit de nos Master Nodes Kubernetes. On peut également ajouter des wildcards :

Toujours dans la configuration du groupe d’agent nous créons dans ‘File Logs’ un fichier de configuration :

Puis nous identifions les fichiers de log à prendre en compte en remplissant les champs « Directory » et « Include Files ». 

Comme la log Kubernetes est en JSON, nous allons également activer le parsing JSON. Ainsi, tous les champs du JSON vont être automatiquement créés dans le Log Insight Server, et cela rendra d’autant plus simple la requête et le traitement de la log par la suite.

Enfin, ne pas oublier d’activer le tout.

A ce stade on peut visualiser les logs dans le serveur Log Insight, les champs sont présents sur la droite.

Grâce au parsing du JSON configuré, nous voyons des noms de champs qui sont des sous-clés dans la log Kubernetes : 

Par exemple pour un tableau "user.groups[X,Y,Z]"  on obtiendra les champs :

user_groups0, user_groups1, user_groups2   respectivement pour X, Y et Z.

Il reste désormais à écrire les requêtes pour identifier les actions réalisées sur le cluster Kubernetes.

Requêter la log du cluster Kubernetes en quelques exemples  

Log insight dispose de tout un outillage pour rechercher des mots, appliquer des filtres, grouper par champs, prendre des moyennes, des min/max et présenter le résultat sous diverses formes visuelles tels  des histogrammes, tableaux, time-series ou autres camemberts.

Voici quelques exemples appliqués à la log Kubernetes :

Exemple 1 : Représentation par type d’action : create ou delete

Exemple 2 : Représentation par type d’action (create ou delete) et par ressources (pods, service, RC, ….)

Exemple 3 : Nombre de pods supprimés sur l’intervalle de temps

Exemple 4 : Suppression des pods dans le temps avec leur nom

Exemple 5 : Pods créés dans le temps avec leur nom

Nous voilà arrivé au terme de cette aventure : Nous pouvons désormais extraire de la log du cluster kubernetes les informations essentielles à son exploitation.

Il ne reste plus qu’à faire les Dashboards, configurer les éventuelles alertes, et partager les dashboards pour rendre ces informations visibles des bons interlocuteurs.