Лучшая практика для управления дампом ядра заключается в том, чтобы эти дампы отправлялись извне на сервер дампов ядра или внешнее хранилище.
Простым способом добиться этого было бы изменение пути, по которому создаются дампы ядра, и после этого вы можете настроить точку монтирования так, чтобы этот путь был HostPath (локальный энергозависимый диск, может быть? / Mnt )
/mnt$ ll
total 28
drwxr-xr-x 3 root root 4096 Mar 24 19:24 ./
drwxr-xr-x 23 root root 4096 Apr 8 06:16 ../
-r--r--r-- 1 root root 639 Mar 24 19:24 DATALOSS_WARNING_README.txt
drwx------ 2 root root 16384 Mar 24 19:24 lost+found/
$> mkdir -p /mnt/cores
$> chmod a+rwx /mnt/cores
$> echo “/mnt/cores/core.%e.%p.%h.%t” > /proc/sys/kernel/core_pattern
Затем можно написать процесс демона, который будет монтировать ту же папку и запускать электронные письма при создании нового файла в /mnt/cores.
Что также может централизованный дамп памяти в одном файле Azure, используя PV C и PV типа Azure File.
https://docs.microsoft.com/en-us/azure/aks/azure-files-volume
Это позволит каждому процессу создать свой файл дампа в сетевое хранилище. Затем вы можете просмотреть контейнер Azure Файл (учетная запись хранения) в программном c способе обнаружения новых файлов. Или настроить оповещение при изменении использования хранилища (оно сообщает, что у вас есть новые данные). Это должно быть выполнено с помощью стандартной функции Azure Monitor для учетной записи хранения.
Я обнаружил статью, которая более или менее похожа на эту идею, но на GCP она должна быть очень похожа.
https://medium.com/faun/handling-core-dumps-in-kubernetes-clusters-in-gcp-b1b2a54c25dc