Nous avons changé la version du nœud kubernetes à cause de ce message, et parce que pour une raison quelconque, les pods n'ont pas pu être planifiés 
Avant ce message, cependant, il y avait un pod postgres en cours d'exécution 
Comme vous pouvez le voir, le pod a disparu, pour une raison quelconque, pourquoi en est-il ainsi ? 
Je n'arrive pas à le récupérer, lorsque j'essaie kubectl get events, je constate qu'aucune ressource ne peut être trouvée, existe-t-il de toute façon pour relancer le conteneur postgres ou obtenir des informations à ce sujet, pourquoi est-il en panne ? "Que pouvais-je faire?" kubectl logs postgres ne semble pas fonctionner non plus.
Ce que je veux obtenir, c'est où s'exécutait ce pod postgres (comme le chemin de l'emplacement), ou si la configuration de ce pod est toujours disponible, ou si elle est perdue à jamais. Si le pod est mort, puis-je toujours accéder à son "cimetière" (c'est-à-dire aux données de la base de données), ou a-t-il été nettoyé ?
Mettre à jour
D'accord, il s'avère que ce pod n'a pas été géré par un contrôleur, c'est pourquoi quand il est mort, il n'y en avait aucune trace, mais pourquoi il n'y a aucune information de journal indiquant que ce pod a été tué ?
1 réponse
À en juger par le nom de votre pod, il n'a pas été provisionné à l'aide d'un déploiement ou d'un jeu de réplicas (s'il l'était, comme vos autres pods, il aurait un identifiant aléatoire après son nom)
Plus que probablement, c'est un pod autonome, ce qui signifie que le nœud est parti, le pod est parti.
Il est peut-être possible d'utiliser kubectl get pods --show-all mais c'est peu probable.
Si votre base de données a un volume persistant, vous pourrez peut-être toujours récupérer les données en les rattachent à un nouveau pod postgres.
À l'avenir, vous pourriez envisager de définir le message de fin et chemin du message et en s'assurant également que tous les pods sont dans un réplica ou un déploiement avec des volumes persistants attachés.