Проанализировать контейнерную файловую систему на kubernetes после ее выхода / сбоя

Question

Возможно, глупый вопрос без смысла:

В развертывании kubernetes (или мини-кубе), когда происходит сбой контейнера pod, я хотел бы проанализировать файловую систему в этот момент. Таким образом, я мог видеть дампы ядра или любую другую полезную информацию.

Я знаю, что мог бы смонтировать том или PV C, чтобы получить дампы ядра из расположения шаблона ядра, определенного хостом, и я также Я могу получить логи с помощью коляски rsyslog или любым другим способом, но я все же хотел бы сделать «посмертный» анализ, если это возможно. Я предполагаю, что kubernetes должен предоставить (но я не знаю, как, в этом причина моего вопроса) некоторый механизм для выполнения этих судебных задач, облегчающих жизнь всем нам, потому что в производственной системе нам может потребоваться анализ убитых / вышедших из строя контейнеры.

Я пытался играть напрямую с docker run без опции - rm , но не смог получить ничего полезного из проверки, чтобы получить полезную информацию или восстановить файловая система в последний момент, когда контейнер был жив.

Большое спасибо!

Answer 1

Когда происходит сбой контейнера pod, я хотел бы проанализировать файловую систему в этот момент.

POD (Контейнеры) изначально используют непостоянное хранилище. Когда контейнер выходит / завершается, то же самое происходит с хранилищем контейнера.

POD (Контейнер) может быть подключен к внешнему хранилищу. Это позволит хранить постоянные данные (вы можете настроить монтирование тома как путь к дампу ядра и т. Д. c ..), поскольку это внешнее хранилище не удаляется при остановке / уничтожении контейнера, что поможет вам с большей гибкостью для анализа файловая система. Настройка хранилища файловой системы контейнера с помощью часто используемых файловых систем, таких как NFS .. et c ..