Gestion des logs Kubernetes

La gestion des logs est un enjeu central pour l'exploitation, le support et la sécurité des applications déployées sur Kubernetes. Cette page détaille les mécanismes de collecte, de centralisation, d'archivage et d'accès aux logs dans un cluster Kubernetes SdV.

Tableau récapitulatif des destinations de logs

Destination	Annotation	Cas d’usage principaux	Accès / Visualisation
ElasticSearch	`sdv/logging: elastic`	Recherche, corrélation, alerting	Kibana, Grafana, API
S3	`sdv/logging: s3`	Archivage long terme, conformité	Accès S3, outils d’audit
TCP	`sdv/logging: tcp`	Intégration SIEM, logstash, syslog	Stack externe (SIEM, etc.)
Elastic+S3	`sdv/logging: elastic,s3`	Mix temps réel + archivage	Kibana + S3

Accès direct aux logs

Kubernetes permet d'accéder aux logs des pods en temps réel via la commande suivante :

Terminal

kubectl -n <namespace> logs <nom-du-pod> [-c <nom-du-container>]

Exemple :

Terminal

kubectl -n mon-namespace logs mon-container-8xdp9

Centralisation vers ElasticSearch

Description fonctionnelle

La centralisation des logs dans ElasticSearch permet :

d’effectuer des recherches avancées et des corrélations sur l’ensemble des applications,
de visualiser les logs via Kibana ou Grafana,
de mettre en place des alertes sur des patterns d’erreur ou de sécurité.

Description technique

Le serveur ElasticSearch peut être interne ou externe au cluster.
Le paramétrage de la destination ElasticSearch est réalisé par SdV au niveau du cluster (non modifiable par l’utilisateur).
Une seule destination ElasticSearch est possible par cluster.
ElasticSearch 7.x+ est recommandé (gestion native de la rétention via les Lifecycle Policies).

Cas d’usage

Analyse d’incidents multi-applications
Recherche de logs sur une période donnée
Détection d’anomalies ou de comportements suspects

Impacts opérationnels

Les logs sont accessibles même après la suppression des pods
Possibilité de requêtes complexes (full-text, agrégations)

Activation (annotation)

L’activation se fait via une annotation sur le pod ou le template de déploiement :

annotations:
  sdv/logging: elastic # log vers ElasticSearch

Par exemple pour envoyer les logs nginx vers ElasticSearch :

deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  namespace: mon-namespace
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
      annotations:
        sdv/logging: elastic
    spec:
      containers:
        - name: nginx
          image: nginx:stable
          ports:
            - containerPort: 80

Archivage dans S3

Description fonctionnelle

L’archivage des logs dans un stockage S3 permet :

de conserver les logs sur une durée longue (compliance, audits, forensics),
de réduire la charge sur ElasticSearch,
de restaurer des historiques en cas d’incident.

Description technique

Le stockage S3 peut être interne (SdV) ou externe (compatible API S3).
Le paramétrage de la destination S3 est réalisé par SdV au niveau du cluster.
Une seule destination S3 est possible par cluster.
La rétention peut être personnalisée par annotation (en jours).

Cas d’usage

Archivage légal ou réglementaire
Analyse post-mortem d’incidents
Conservation de logs applicatifs critiques

Impacts opérationnels

Les logs archivés sont compressés et organisés par rétention, date, namespace.
L’accès nécessite des droits sur le bucket S3 cible.

Activation (annotation)

L’activation se fait via une annotation sur le pod ou le template de déploiement :

annotations:
  sdv/logging: s3 # demande l'archivage sur le S3
  sdv/s3-logging-retention: "14" # rétention spécifique de 14 jours

Par exemple pour garder les logs nginx sur 1 an :

deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  namespace: mon-namespace
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
      annotations:
        sdv/logging: s3
        sdv/s3-logging-retention: "365"
    spec:
      containers:
        - name: nginx
          image: nginx:stable
          ports:
            - containerPort: 80

Ou via kubectl :

Terminal

kubectl annotate pods mon-pod sdv/logging='s3' sdv/s3-logging-retention='365'

A propos de la rétention

L'organisation des logs dans le bucket S3 est de la forme suivante :

<retention>/<annee-mois-jour>/<namespace_kubernetes>/<timestamp>-<uuid>.log.gz

Par exemple :

3/2020-01-14/emojivoto/1579014033-416693c4-3b06-4599-88dc-6af8a5c6b549.log.gz
3/2020-01-14/emojivoto/1579017634-ec2b7dbf-6dc5-4949-8e87-2b5d20b3c802.log.gz
3/2020-01-14/emojivoto/1579021235-1c39facf-8452-456c-b691-7bb6624edf71.log.gz
7/2020-01-14/sdv-logging/1579014043-c17c10fb-4ada-40f5-b5c7-74436cd5115b.log.gz
7/2020-01-14/sdv-logging/1579017675-8a0c8669-a2d4-4969-9866-727a0c06adc1.log.gz
7/2020-01-14/sdv-logging/1579021288-45efb2ee-ec42-4e99-aab7-bfbb2f314d72.log.gz

Externalisation en TCP

Description fonctionnelle

L’externalisation des logs en TCP permet :

d’envoyer les flux de logs vers une stack de traitement externe (ex : Logstash, SIEM, syslog-ng),
d’intégrer Kubernetes dans une infrastructure de supervision/logging existante.

Description technique

Le paramétrage de la destination TCP est réalisé par SdV au niveau du cluster.
Une seule destination TCP est possible par cluster.
Le format d’envoi est généralement du JSON ou du texte brut.

Cas d’usage

Agrégation de logs multi-clusters
Intégration avec des outils de sécurité (SIEM)
Traitement temps réel (alerting custom, parsing avancé)

Impacts opérationnels

Les logs sont transmis en temps réel à la destination TCP
Dépendance à la disponibilité du collecteur externe

Activation (annotation)

L’activation se fait via une annotation sur le pod ou le template de déploiement :

annotations:
  sdv/logging: tcp # log vers destination TCP

Par exemple pour envoyer les logs nginx vers ElasticSearch :

deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  namespace: mon-namespace
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
      annotations:
        sdv/logging: tcp
    spec:
      containers:
        - name: nginx
          image: nginx:stable
          ports:
            - containerPort: 80

Destinations multiples

Description fonctionnelle

Il est possible d’envoyer les logs d’un même pod vers plusieurs destinations simultanément (ElasticSearch, S3, TCP).

Cas d’usage

Archivage long terme + recherche temps réel
Migration progressive d’une solution de logs à une autre

Impacts opérationnels

Attention à la volumétrie générée (coût, bande passante)
Les destinations sont indépendantes (une panne n’affecte pas les autres)

Activation (annotation)

Lister les destinations dans l’annotation sdv/logging, séparées par une virgule :

deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  namespace: mon-namespace
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
      annotations:
        sdv/logging: elastic,s3
    spec:
      containers:
        - name: nginx
          image: nginx:stable
          ports:
            - containerPort: 80

Limitations techniques

En raison de la représentation interne des logs dans vector, les . dans les clés des metadonnées Kubernetes sont remplacés par des _.

Exemple :

"annotations": {
  "cni_projectcalico_org/podIP": "10.42.3.38/32"
}

Bonnes pratiques

Toujours définir explicitement la rétention souhaitée pour l’archivage S3.
Utiliser des labels et annotations cohérents pour faciliter la recherche et la corrélation.
Documenter les destinations de logs dans vos chartes d’exploitation.
Surveiller la volumétrie générée par la centralisation et l’archivage.
Tester la restauration/l’accès aux logs archivés régulièrement.

Attention

Les modifications d’annotations nécessitent un redémarrage des pods pour être prises en compte.
Une mauvaise configuration des destinations peut entraîner une perte de logs.
La rétention S3 n’est pas une suppression automatique : il faut configurer un lifecycle policy côté bucket.

Notes d’exploitation

Pour des besoins spécifiques (compliance, sécurité), rapprochez-vous du support SdV pour valider la stratégie de logs.
En cas de volumétrie importante, privilégier l’archivage S3 et limiter la rétention ElasticSearch.