4
votes

Kubernetes - Comment lire les journaux qui sont écrits dans des fichiers dans des pods au lieu de stdout / stderr?

J'ai un pod dans un état de CrashLoopBackOff , les logs que je vois à partir de kubectl logs -p ne présentent qu'une image partielle. D'autres journaux se trouvent dans d'autres fichiers (par exemple /var/log/something/something.log ).

Comme ce pod est en panne, je ne peux pas kubectl exec dans un shell et regarder les fichiers.

Comment puis-je consulter les fichiers journaux produits par un conteneur qui n'est plus en cours d'exécution?

Pour être plus précis, je recherche un fichier de fichiers journaux sous $ HOME / logs / es.log (dans le conteneur qui a échoué)


3 commentaires

Les journaux Docker sont stockés sur les nœuds de travail sous / var / log / containers / . Sauf si vous avez activé la rotation, celles-ci sont persistantes même si les pods ne sont pas en cours d'exécution.


Je ne cherche pas de journaux de docker. peut-être que j'aurais dû être plus clair. Les journaux que je recherche se trouvent dans $ HOME / logs / es.log


Ah. Dans ce cas, si les journaux ne sont pas écrits sur un volume persistant, il n'y a aucun moyen d'y accéder après la suppression d'un conteneur. Gardez à l'esprit cependant que toute sortie stdout et stderr est capturée par docker et écrite dans / var / log / containers / . Donc, si le contenu de $ HOME / logs / es.log a également été écrit sur stdout, vous devriez pouvoir y accéder depuis le nœud worker sur lequel il s'exécutait à l'origine.


3 Réponses :


0
votes

En gros, vous avez plusieurs options ici.

Si vous souhaitez procéder tel quel avec votre configuration,

vous pouvez accéder aux fichiers du conteneur quitté depuis l'hôte sur lequel le conteneur s'exécute.
Découvrez le worker sur lequel se trouve le conteneur:

$ ID=$(docker ps -a | grep my-pod | grep -v POD | cut -d" " -f1)
$ docker cp $ID:/my.log .
$ cat my.log
log entry

Ensuite, si vous avez accès à ce nœud (par exemple via shh), vous pouvez trouver le conteneur:

$ kubectl get pod my-pod -o custom-columns=Node:{.spec.nodeName} --no-headers
my-worker-node

Si vous ne disposez pas d'un accès ssh au nœud, vous pouvez utiliser des plugins comme celui-ci: https://github.com/kvaps/kubectl-enter

Mais ce n'est généralement pas la meilleure pratique

Vous ne devriez pas écrire de journaux dans fichiers, au lieu de cela, votre application devrait écrire dans stdout / stderr, il serait alors beaucoup plus facile de déboguer


0 commentaires

-1
votes

Avez-vous essayé l'indicateur --previous ?

C'est comme

$ kubectl logs <pod-name> <container-name> --previous


0 commentaires

4
votes

J'étais tellement frustré de ne trouver aucune solution à ce problème apparemment courant que j'ai créé une image docker qui file les fichiers journaux et les envoie vers stdout, pour être utilisée comme conteneur side-car.


Voici ce que j'ai fait :

  1. J'ai ajouté un volume avec emptyDir {} au pod
  2. J'ai monté ce volume sur mon conteneur principal, le mountPath étant le répertoire dans lequel il écrit les journaux
  3. J'ai ajouté un autre conteneur au pod, appelé "logger", l'image étant le journal de suivi que j'ai écrit ( lutraman / logger-sidecar: v2 ), et monté le même volume sur / logs (j'ai programmé le script pour lire les logs de ce répertoire)

alors, tous les journaux écrits dans ce répertoire sont accessibles par kubectl logs -c logger


Voici un exemple yaml:

#!/bin/bash

trap cleanup INT

function cleanup() {
  while read pid; do kill $pid; echo killed $pid; done < /tmp/pids
}

: > /tmp/pids

for log in $(ls logs); do
  ./addTail n logs $log
done

inotifyd ./addTail `pwd`/logs:n 

Pour tous ceux qui sont intéressés, voici comment j'ai créé le conteneur side-car:

Dockerfile:

#!/bin/sh

(exec tail -F logs/$3 | sed "s/^/$3: /" ) &
echo $! >> /tmp/pids

addTail:

FROM alpine:3.9

RUN apk add bash --no-cache

COPY addTail /addTail
COPY logtrack.sh /logtrack.sh

CMD ["./logtrack.sh"]

logtrack.sh:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: dummy
  labels:
    app: dummy
spec:
  selector:
    matchLabels:
      app: dummy
  template:
    metadata:
      labels:
        app: dummy
    spec:
      volumes:
        - name: logs
          emptyDir: {}
      containers:
        - name: dummy-app # the app that writes logs to files
          image: lutraman/dummy:v2
          ports:
            - containerPort: 8080
              name: http
              protocol: TCP
          env:
            - name: MESSAGE
              value: 'hello-test'
            - name: LOG_FILE
              value: '/var/log/app.log'
          volumeMounts:
            - name: logs
              mountPath: /var/log
        - name: logger # the sidecar container tracking logs and sending them to stdout
          image: lutraman/logger-sidecar:v2
          volumeMounts:
            - name: logs
              mountPath: /logs


4 commentaires

qu'en est-il du «logrotate»? est-ce que cela a été couvert?


Merci d'avoir partagé! Cela ressemble aux sections «Utilisation d'un conteneur side-car avec l'agent de journalisation» dans la documentation officielle de k8s. kubernetes.io / docs / concepts / cluster-administration / logging /…


Semblable à la question de @Tun, avez-vous régulièrement nettoyé le fichier journal? Puisque maintenant le fichier journal est dupliqué sur stdout, il doublera l'utilisation du disque


@yusong vous avez raison, cela doublera la taille sur le disque pendant que le pod est en cours d'exécution. Pour mon cas, ce n'était pas très pertinent, car les fichiers originaux étaient enregistrés dans le fs du conteneur, ce qui est éphémère et sera supprimé à chaque redémarrage (ce qui était assez fréquent dans mon cas pour ne pas s'inquiéter). Les autres journaux sont enregistrés dans élastique, pour lequel j'ai une rotation. C'est une préoccupation valable si vous avez de gros fichiers journaux et un long délai entre les redémarrages