1. Proposed title of this feature request

Collect, store and export container/application core dumps

2. What is the nature and description of the request?

In order to facilitate debugging of applications running in containers there is a need to be able to collect, store and export the core dumps generated when a process within a container crashes (e.g. with SIGSEGV, SIGABRT, etc.).

It is possible to configure core dump file creation and collection by modifying core_pattern (or using systemd-coredumper defaults) and using a hostPath volume mount matching the core_pattern in addition to setting ulimits and suid_dumpable permissions.

However, this is only usable where the owner of the application has control and access to the host system and the collection of core dumps is potentially manual in a multi-node K8s cluster where a pod could be rescheduled to a different worker node following a crash.

Customers would like a solution where core dumps could be collected and automatically stored in a central location and exported to an external storage platform for retrieval.

https://github.com/IBM/core-dump-handler has been cited as an example of the sort of functionality customers are requesting.

An example use case is where an application provides a unified WebUI or interface for its users to trigger the collection of troubleshooting data for the application and the troubleshooting data collected includes various logs, KPIs, traces and core dump files of any crashed processes.

3. Why does the customer need this? (List the business requirements here)

This is required to enable core dump files to be retrieved for debugging and other purposes without:

• requiring that the owner of the application has control and access to the host system
• having to know which worker node a process was running on when it crashed