J'ai un pod dans un état de CrashLoopBackOff , les logs que je vois à partir de kubectl logs 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 Réponses :
En gros, vous avez plusieurs options ici.
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
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
Avez-vous essayé l'indicateur --previous ?
C'est comme
$ kubectl logs <pod-name> <container-name> --previous
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 :
emptyDir {} au pod mountPath étant le répertoire dans lequel il écrit les journaux 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
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
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
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.loga également été écrit sur stdout, vous devriez pouvoir y accéder depuis le nœud worker sur lequel il s'exécutait à l'origine.