Autant, récupérer les logs des applis du cluster c'est simple à coup de Promtail/Alloy/Loki, ELK ou autre stack, mais pour récupérer les logs d'audit du control-plane ce n'était pas évident... Jusqu'à maintenant 😉

OVHCloud Managed Kubernetes Service & Logs Data Platform

La Logs Data Platform (aka "LDP") permet de centraliser les logs. Je ne ferai pas une présentation de cette plateforme, car j'utilise ma propre stack, et j'ai des besoins d'archivage/export de logs sur d'autres environnements, pour de l'archivage, SOC, etc.

Cette Logs Data Platform est notamment utilisée pour permettre l'envoi des logs d'audit du control-plane des clusters MKS, sur lesquels nous n'avons pas la main.

En effet, depuis l'interface du manager OVHCloud, on peut transférer les logs :

Pour paramétrer l'envoi de ces logs, je vous renvoie sur la doc officielle.

Vector & websocket

OK, jusque là j'ai mes logs sur la "LDP", mais je veux pouvoir les récupérer chez moi (ou pouvoir les envoyer ailleurs) !

A la suite d'articles comme Falco, j'ai découvert qu'il était possible de récupérer les logs via websocket ! Et si, par chance, il n'existerait pas un outil pour ça ?

Vector

Vous l'aurez deviné, Vector est un outil qui permet de récupérer, transformer, envoyer des logs, métriques et traces, un très bon outil d'observabilité !

Parmi ses qualités, on notera :

• sa rapidité de traitement vs sa faible empreinte cpu/mémoire (oui, c'est écrit en rust)
• son écosystème de plugins riches
• sa facilité de déploiement.

Et, "comme par hasard", la version v0.49.0 vient de sortir avec une fonctionnalité qui m'intéresse :

"A websocket source was introduced. A WebSocket source in Vector enables ingestion of real-time data from services that expose WebSocket APIs."

Bon, ben y a plus qu'à !!

Paramétrage & test local

Avant de déployer ça sur mes clusters, on va tester ça localement, pour éviter trop de git push, rollout et CrashLoopBackoff 😅. Etant sous MacOS, l'install se fait facilement avec brew :

1$ brew tap vectordotdev/brew && brew install vector
2$ vector --version
3vector 0.49.0 (aarch64-apple-darwin dc7e792 2025-08-12 13:47:08.632326804)

Ensuite, il faut :

1. Récupérer l'URL websocket

   • Depuis l'interface OVH, allez dans l'onglet "Flux de Données", "Suivre en direct"
   • Puis cliquer sur "Actions", "Copier l'adresse WebSocket"
   • L'adresse sera de type wss://gra1.logs.ovh.com/tail/?tk=abcdefghijklmnopqrstuvwxyz

2. Paramétrer Vector, en éditant un fichier vector.yaml

   • Définir un objet source de type websocket
   • Définir les transforms souhaitées et les sinks (destinations)

Pour l'exemple, on va simplement renvoyer sur la console :

 1# vector-1.yaml
 2sources:
 3  ovh_ldp_source:
 4    type: websocket
 5    uri: "wss://gra1.logs.ovh.com/tail/?tk=abcdefghijklmnopqrstuvwxyz"
 6    tls: # le websocket OVHCloud est en TLS, sinon vous aurez une erreur de connection ^^
 7      enabled: true
 8
 9sinks:
10  stdout_sink:
11    type: console
12    inputs:
13      - ovh_ldp_source

On lance !

1$ vector -c vector-1.yaml
22025-08-29T09:05:09.371791Z  INFO vector::app: Log level is enabled. level="info"
32025-08-29T09:05:09.373257Z  INFO vector::app: Loading configs. paths=["vector-1.yaml"]
42025-08-29T09:05:09.575776Z  INFO vector::topology::running: Running healthchecks.
52025-08-29T09:05:09.575874Z  INFO vector: Vector has started. debug="false" version="0.49.0" arch="aarch64" revision="dc7e792 2025-08-12 13:47:08.632326804"
62025-08-29T09:05:09.575918Z  INFO vector::topology::builder: Healthcheck passed.
72025-08-29T09:05:09.575929Z  INFO vector::app: API is disabled, enable by setting `api.enabled` to `true` and use commands like `vector top`.
8{"message":"{\"message\":\"{\\\"_audit_apiVersion\\\":\\\"audit.k8s.io/v1\\\",\\\"_audit_objectNamespace\\\":\\\"default\\\",\\\"_audit_authorizationReason\\\":\\\"\\\",\\\"_audit_requestReceivedTimestamp_date\\\":\\\"2025-08-29T09:05:13.486642Z\\\[...]"}
9{"message":"{\"message\":\"{\\\"_audit_apiVersion\\\":\\\"audit.k8s.io/v1\\\",\\\"_audit_objectNamespace\\\":\\\"kyverno\\\",\\\"_audit_authorizationReason\\\":\\\"RBAC: allowed by RoleBinding \\\\\\\"kyverno:reports-controller/kyverno\\\\\\\" of Role[...]"}

Cool, j'arrive à récupérer les logs, et vais pouvoir les envoyer sur ma propre stack et/ou ailleurs, au choix !! On va quand même faire un peu de ménage dans le format des messages, y a du redondant. Ce qui nous donne le fichier de conf suivant :

 1# vector-2.yaml
 2sources:
 3  ovh_ldp_source:
 4    type: websocket
 5    uri: "wss://gra1.logs.ovh.com/tail/?tk=abcdefghijklmnopqrstuvwxyz"
 6    tls:
 7      enabled: true
 8    decoding:
 9      codec: json
10
11transforms:
12  ovh_ldp_transform:
13    type: remap
14    inputs:
15      - ovh_ldp_source
16    source: |
17      . = parse_json!(.message)
18      . = parse_json!(.short_message)
19
20sinks:
21  stdout_sink:
22    type: console
23    inputs:
24      - ovh_ldp_transform
25    encoding:
26      codec: "json"
27      json:
28        pretty: true

 1$ vector -c vector-2.yaml
 22025-08-29T09:20:09.555364Z  INFO vector::app: Log level is enabled. level="info"
 32025-08-29T09:20:09.559014Z  INFO vector::app: Loading configs. paths=["vector-2.yaml"]
 42025-08-29T09:20:09.787928Z  INFO vector::topology::running: Running healthchecks.
 52025-08-29T09:20:09.789154Z  INFO vector::topology::builder: Healthcheck passed.
 62025-08-29T09:20:09.789801Z  INFO vector: Vector has started. debug="false" version="0.49.0" arch="aarch64" revision="dc7e792 2025-08-12 13:47:08.632326804"
 72025-08-29T09:20:09.790055Z  INFO vector::app: API is disabled, enable by setting `api.enabled` to `true` and use commands like `vector top`.
 8{
 9  "annotations": {
10    "authorization.k8s.io/decision": "allow",
11    "authorization.k8s.io/reason": "RBAC: allowed by RoleBinding \"kyverno:background-controller/kyverno\" of Role \"kyverno:background-controller\" to ServiceAccount \"kyverno-background-controller/kyverno\""
12  },
13  "apiVersion": "audit.k8s.io/v1",
14  "auditID": "f861cf50-a561-4ad7-b8f0-8bbb068152d3",
15  "kind": "Event",
16  "level": "Metadata",
17  "objectRef": {
18    "apiGroup": "coordination.k8s.io",
19    "apiVersion": "v1",
20    "name": "kyverno-background-controller",
21    "namespace": "kyverno",
22    "resource": "leases",
23    "resourceVersion": "37003755025",
24    "uid": "9fca9fef-d75f-4342-a69f-eada6f93de0f"
25  },
26  [...]

Ahh, c'est beaucoup mieux 👍 !

La suite

On a pu voir comment récupérer les logs de la "Logs Data Plaform" d'OVHCloud via websocket, grâce notamment à l'outil Vector.

Ca marche très bien en local, maintenant à vous de configurer vos transforms et sinks pour traiter vos logs comme bon vous semble.

De mon côté, c'est déployé via chart Helm en mode Aggregator sur mes clusters, avec quelques transforms nécessaires pour coller avec d'autres logs envoyés dans Loki.

Amusez-vous bien avec tous ces nouveaux logs !

X509 Certificate Exporter

Proposé par la société Enix, l'exporter x509-certificate-exporter permet de suivre les certificats x509 de vos applications, et être notifié sur l'expiration de ceux-ci.

J'utilise en général cert-manager et Let's Encrypt, qui permet d'automatiser la création et renouvellement de certificats, surtout au niveau ingress et HTTPS, mais cela n'empêche pas d'avoir des alertes sur le renouvellement des certificats :

• Le challenge Let's Encrypt qui échoue pour diverses raisons (principalement des erreurs réseaux).
• Un secret Kubernetes qui contient un ancien certificat qui n'est pas nettoyé.

Un dashboard est même fourni avec, que vous pourrez modifier selon vos envies :

Helm Exporter

J'utilise beaucoup de charts Helm pour déployer les applications sur Kubernetes, surtout les briques d'infrastructure (prometheus, nginx, cert-manager, velero, etc.). G Je souhaitais alors pouvoir suivre les versions de charts Helm sur l'ensemble des clusters administrés, et je suis tombé sur 2 outils:

1. Nova de la société Fairwinds, un outil en CLI qui permet de lister les charts dépréciés. L'outil est pratique, mais difficile d'avoir une visualisation globale, ainsi qu'un tableau de bord

2. L'exporter helm-exporter qui va générer des métriques Prometheus pour les charts installés au sein du cluster, avec les versions également dépréciées.

Je me suis arrêté sur ce deuxième choix, car il est ainsi facile d'avoir un dashboard dans Grafana.

La configuration est un tout petit peu "pénible", dans le sens où il faut définir la source de chaque chart (le tout est expliqué sur le dépôt GitHub).

 1config:
 2  helmRegistries:
 3    override:
 4      - registry:
 5          url: "https://charts.jetstack.io"
 6        charts:
 7          - "cert-manager"
 8        allowAllReleases: true
 9      - registry:
10          url: "https://charts.gitlab.io"
11        charts:
12          - "gitlab-runner"
13        allowAllReleases: true
14      - registry:
15          url: "https://shanestarcher.com/helm-charts"
16        charts:
17          - "helm-exporter"
18        allowAllReleases: true
19      - registry:
20          url: "https://kubernetes.github.io/ingress-nginx"
21        charts:
22          - "ingress-nginx"
23        allowAllReleases: true
24[...]

Ainsi, on peut voir que mes clusters ont bien le chart précédemment installé à jour ;)

Blackbox Exporter

On revient aux fondamentaux, le blackbox_exporter reste un exporter très utile lorsqu'on doit monitorer des sites ou équipements distants, ne répondant qu'en HTTP(S), DNS, TCP.

Je l'utilise surtout pour avoir les temps de réponse des sites déployés, depuis un site tiers.

Harbor Exporter

Un petit dernier, quand on est en environnement conteneurs et qu'on gère une registry (Harbor notamment), on peut suivre son état avec celui-ci. Il existe l'exporter harbor_exporter.

Je l'utilise assez peu, mais cela me permet de voir quels projets consomment le plus de place quand il faut y faire du ménage (il est si facile de créer des images Docker...).

Prometheus MS Teams

Ce n'est pas un exporter, mais je note quand même l'outil prometheus-msteams, qui est un serveur web léger en Go qui permet de récupérer des alertes générées via webhook pour les transmettre à un canal MS Teams.

Testé chez moi avec succès !

Cabourotte & Appclacks

Si cela nous vous suffit pas, allez voir aussi ce que fait @mcorbin, avec Appclacks et sa sonde health-check cabourotte. Projet prometteur !

Les probes se pilotent via API au travers d'une CLI, et il existe même un provider Terraform. On peut soit utiliser les sondes fournies, soit ses propres sondes avec cabourotte, qui ira récupérer sa config auprès du serveur central.

D'autres ressources

Dernier petit lien, si vous devez administrer un serveur Mastodon (rien à voir avec Kubernetes, certes), allez voir ici.

Il est très simple à installer en tant que daemonset dans un cluster, pour y récupérer les logs des conteneurs. Mais parfois on a besoin de récupérer également les logs des nodes du cluster, sur lesquels tournent ces conteneurs.

Ci-après une explication rapide pour la mise en place d'un tel setup.

Installation simple

Note: Cet article utilise Promtail v2.5.0, la configuration présentée peut différer selon la version que vous utiliserez.

Par défaut, l'installation de Promtail se fait avec un chart Helm, qui fonctionne "out-of-the-box". On considère que Loki et Grafana sont déjà déployés dans le cluster.

1$ helm repo add grafana https://grafana.github.io/helm-charts
2$ helm repo update
3$ helm --install --namespace observability --create-namespace promtail grafana/promtail

On peut voir maintenant que les agents Promtail tournent sur les nodes, et que les logs arrivent dans Loki. Grafana permet l'exploration des logs, tout est bon.

1$ kubectl get pods -l app.kubernetes.io/name=promtail
2NAME READY STATUS RESTARTS AGE
3promtail-47jwn 1/1 Running 0 13m
4promtail-mwkcb 1/1 Running 0 14m

Paramétrage

Pour l'instant, on a un setup simple, mais fonctionnel.

Cependant, pour les besoins exprimés cela ne suffit pas, car on doit transmettre les logs du répertoire /var/log/ des nodes vers Loki, ici plus spécifiquement le fichier /var/log/syslog. Pourquoi ne pas utiliser ces daemonsets pour cela ? On va configurer Promtail en ce sens.

Montage du dossier hôte

Tout d'abord, on doit monter le dossier de l'hôte /var/log sur le pod. On montera le dossier dans /var/log/host pour éviter tout problème d'écrasement / nommage.

On spécifie cela dans les paramètres du chart Helm, dans un fichier custom-values.yaml :

 1# Mount folder /var/log from node
 2extraVolumes:
 3  - name: node-logs
 4    hostPath:
 5      path: /var/log
 6
 7extraVolumeMounts:
 8  - name: node-logs
 9    mountPath: /var/log/host
10    readOnly: true

On upgrade le chart helm, et le dossier /var/log/host est bien là, parfait !

1$ helm upgrade --install --namespace observability promtail grafana/promtail -f custom-values.yaml
2$ kubectl exec -it promtail-mwkcb --mount | grep /var/log/host
3/dev/sda1 on /var/log/host type ext4 (ro,relatime,data=ordered)

Avant d'aller plus loin, voyons si l'on peut lire les fichiers à l'intérieur :

1$ kubectl exec -it promtail-mwkcb --tail /var/log/host/syslog
2tail: cannot open ‘/var/log/host/syslog’ for reading: Permission denied
3command terminated with exit code 1

Mmmm, il y a quelque chose d'incorrect ici, voyons les permissions des fichiers :

1$ kubectl exec -it promtail-mwkcb — ls -l /var/log/host/syslog
2-rw-r---- 1 102 adm 72327736 Jun 29 20:01 /var/log/host/syslog

Le fichier appartient à l'utilisateur avec l'ID 102 et groupe "adm". Avec getent on a un peu plus d'infos sur ce groupe :

1$ kubectl exec -it promtail-mwkcb -- getent group adm
2adm:x:4:

Donc, si l'on veut que promtail puisse lire ce fichier, il faut ajouter des contextes de sécurité avec l'option fsGroup, que l'on définit dans les custom values du chart Helm :

1# Set fsGroup to allow syslog file reading
2podSecurityContext:
3  fsGroup: 4

On upgrade le chart Helm, et on vérifie l'accès au fichier :

1$ helm upgrade promtail grafana/promtail -f custom-values.yaml
2$ kubectl exec -it promtail-2dbh9 -- tail /var/log/host/syslog
3Jun 29 20:16:28 worker-pool-node-d5353e kubelet[1596]: I0629 20:16:28.374480 1596 clientconn.go:897] blockingPicker: the picked transport is not ready, loop back to repick
4Jun 29 20:16:28 worker-pool-node-d5353e docker[1888]: I0629 20:16:28.375267 1 utils.go:81] GRPC call: /csi.v1.Node/NodeGetVolumeStats

Cela semble mieux ! Maintenant on peut lire les fichiers du node depuis notre pod Promtail.

Configuration Promtail

On va ensuit configurer Promtail pour lire (scrape) ce nouveau fichier, avec un simple "File Target Discovery" (voir ici). On y rajoute quelques labels pour les retrouver facilement dans Loki plus tard. Toujours dans les custom values :

 1# Scrape config to read syslog file from node
 2config:
 3  snippets:
 4    extraScrapeConfigs: |
 5      # Add an additional scrape config for syslog
 6      - job_name: node-syslog
 7        static_configs:
 8        - targets:
 9          - localhost
10          labels:
11            job: node/syslog
12            __path__: /var/log/host/syslog

On upgrade une fois de plus le chart, et on peut maintenant voir les logs syslog du node, en plus des logs des conteneurs, être transmis dans Loki, nickel !

Ajout de labels dynamiques

Les logs sont là, mais avoir des labels supplémentaires ne serait pas de refus, comme le nom du node.

On va alors utiliser l'option -config.expand-env qui récupère les variables d'environnement, et on va les rajouter dans la configuration de Promtail :

 1# Allow environment variables usage
 2extraArgs:
 3  - -config.expand-env=true
 4
 5# Scrape config to read syslog file from node
 6config:
 7  snippets:
 8    extraScrapeConfigs: |
 9      # Add an additional scrape config for syslog
10      - job_name: node-syslog
11        static_configs:
12        - targets:
13          - localhost
14          labels:
15            job: node/syslog
16            __path__: /var/log/host/syslog
17            node_name: '${HOSTNAME}'

On upgrade une dernière fois le chart, on vérifie les logs dans Grafana... Et voilà ! On a bien les logs des nodes, avec les labels qui vont bien !

Récapitulatif

Pour résumer, afin d'avoir les logs des nodes dans Loki en utilisant Promtail, il "suffit" de :

1. Monter le dossier /var/log du node dans le pod Promtail
2. Utiliser le bon fsGroup pour pouvoir lire les fichiers
3. Ajouter une configuration de scraping static_configs
4. Utiliser les variabels d'environnement pour ajouter des labels

On retrouvera le fichier custom-values.yaml pour déployer le chart Helm dans mon dépôt GitLab.

On peut maintenant fouiner dans les logs, vérifier ce qu'il ne va pas sur les nodes, et plus encore... Bonne recherche !

Si cela n'est pas fait, on peut arriver dans des situations délicates, comme ne pas avoir assez de ressources disponibles si un serveur (node) est indisponible, quelques process OOMKilled à cause de limites de mémoire trop restrictives, des pods non schedulés, etc. De plus, par défaut, certaines valeurs de déploiements ne sont pas toujours alignées avec l'utilisation que l'on en a (comme certains charts Helm publics).

Alors, comment valider nos déploiements, et adapter les Requests & Limits pour coller au mieux à l'utilisation que l'on en a ? Cela peut être fait avec un mix d'outils Open Source, que l'on verra dans cet article.

Vertical Pod Autoscaler

Kubernetes Vertical Pod Autoscaler permet de suivre l'utilisation CPU et RAM des pods d'un cluster, et les adapter automatiquement si besoin. On retrouvera plus d'information ici : https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler

Le VPA a 3 composants: le Recommender, l'Updater et l'Admission Plugin. Dans notre cas, on ne souhaite avoir que des recommendations, alors on n'utilisera que le Recommender.

L'installation peut se faire de plusieurs façons, mais on utilisera ici le chart Helm fourni par Fairwinds.

Comme l'on utilise Prometheus comme outil de monitoring, on s'en servira plus tard de source pour récupérer les métriques VPA. On active cela dans les valeurs du chart Helm :

1$ helm repo add fairwinds-stable https://charts.fairwinds.com/stable
2$ helm repo update
3$ helm install vpa fairwinds-stable/vpa --namespace vpa --create-namespace -f vpa-custom-values.yaml # See below

 1admissionController:
 2  enabled: false
 3recommender:
 4  enabled: true
 5  extraArgs:
 6    prometheus-address: |
 7      http://prometheus-operated.observability.svc.cluster.local:9090
 8    storage: prometheus
 9updater:
10  enabled: false

Comme dit plus haut, Prometheus est utilisé ici comme fournisseur de métriques, pour avoir des informations plus pertinentes, et permettant d'avoir un historique plus grand. On ne couvrira pas l'installation de l'outil dans cet article.

Maintenant qu'on a le VPA fonctionnel (du moins, le recommendeur), on peut créer une configuration VPA. Un exemple est disponible ici.

La définition d'un VPA est assez simple, mais souhaitant plus d'automatisation, on va utiliser Goldilocks !

Goldilocks

Goldilocks est un utilitaire de la société Fairwinds, qui va permettre de gérer les requêtes et limites simplement, basé sur les VPA, comme précédemment installé.

L'outil va vérifier les déploiements, et automatiquement créer les VPA en fonction de labels. Donc si l'on souhaite activer les VPA sur un déploiement, un namespace ou une autre resource Kubernetes, il suffit d'y ajouter un label, et Goldilocks fera le reste !

L'installation se fait avec un chart Helm :

1$ # Goldilocks Helm repository is already there
2$ helm install goldilocks --namespace vpa fairwinds-stable/goldilocks

Une fois Goldilocks déployé, on retrouve 3 pods :

1. Goldilocks controller, qui scrute les labels et créer les VPA en conséquence.
2. Goldilocks dashboard, qui permet d'avoir un dashboard standalone pour voir les reommendations VPA.
3. VPA recommender, qui calcule les recommendations sur les Requests et Limits CPU et RAM.

1$ kubectl get pods
2NAME                          READY   STATUS    RESTARTS   AGE
3goldilocks-controller-5bf99   1/1     Running   0          49d
4goldilocks-dashboard-699f4    1/1     Running   0          49d
5vpa-recommender-74fdc         1/1     Running   0          67d

Maintenant, il suffit de rajouter le label qui va bien (goldilocks.fairwinds.com/enabled=true) sur un namespace pour voir la magie opérer : on ajoute ici les labels sur le namespace "velero", et les VPA seront automatiquement créés :

1$ kubectl label ns velero goldilocks.fairwinds.com/enabled=true
2$ kubectl get namespace velero --show-labels                  
3NAME     STATUS   AGE    LABELS
4velero   Active   112d   goldilocks.fairwinds.com/enabled=true,name=velero
5
6$ kubectl get vpa -n velero                 
7NAME                MODE   CPU   MEM         PROVIDED   AGE
8goldilocks-restic   Off    15m   183046954   True       67d
9goldilocks-velero   Off    11m   183046954   True       67d

Note: Fairwinds propose aussi un chart Helm qui installe les VPA et Goldilocks en même temps, mais ne le recommendent pas.

Maintenant que l'on a nos VPAs créé automatiquement, on peut voir les recommendations sur le dashboard dédié !

OK, c'est très bien, mais on a généralement déjà de beaux tableaux de bord avec des outils de monitoring comme le couple Prometheus & Grafana. Pourquoi ne pas les utiliser au lieu du dashboard dédié ? On y va !

Prometheus & Grafana

En cherchant un peu dans les paramètres des VPA et les métriques disponibles, on peut voir que kube-state-metrics expose les informations suivantes :

• kube_verticalpodautoscaler_status_recommendation_containerrecommendations_lowerbound
• kube_verticalpodautoscaler_status_recommendation_containerrecommendations_upperbound

Toutes ces métriques sont définies ici.

Si on utilise l'opérateur Prometheus, il faudra le mettre à jour pour explicitement activer le collecteur verticalpodautoscalers dans le déploiement kube-state-metrics.

On a maintenant les VPA, les métriques Prometheus, on peut donc arêter le dashboard Goldilocks et créer le notre dans Grafana, et récupérant les bonnes métriques !

1. On va donc mettre à jour le déploiement de Goldilocks pour désactiver le dashboard :

1$ helm upgrade goldilocks --namespace vpa fairwinds-stable/goldilocks -f goldilocks-custom-values.yaml

1dashboard:
2  enabled: false

2. On crée un dashboard Grafana !

Cool ! On peut maintenant suivre et adapter les Requests & Limits de nos applications depuis notre outil de dashboard préféré, et adapter les différents seuils pour s'adapter au cluster. On peut aussi étendre l'historique des recommendations, pour mieux adapter les valeurs.

Un exemple de tableau de bord est disponible ici : https://grafana.com/grafana/dashboards/16294

Fun fact, j'ai utilisé Goldilocks pour adapter les Requests & Limits de Goldilocks lui-même ;)

Ressources

On peut récupérer un autre tableau de bord ici, lequel j'ai utilisé comme source pour crée le mien.