[Enhancement] Add --share-volumes to kubectl debug

[specterops-avongluck]

What would you like to be added?

kubectl debug has a --share-processes flag to allow the debug containers to share processes of the debugged (likely distroless) container.

To help enhance debugging distroless containers, it would be nice ™️ if kubectl debug also supported a --share-volumes flag.

Why is this needed?

This flag would attempt attach the currently mounted volumes of the target container to the newly spawned debug container.

There are some situations in-which this could fail, which seems like perfectly valid risk for a debug container.

[k8s-ci-robot]

This issue is currently awaiting triage.

If a SIG or subproject determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[specterops-avongluck]

/sig cli

[ardaguclu]

I think you can patch whatever volume mount you want to use by using --custom flag in kubectl debug. See https://kubernetes.io/blog/2024/08/22/kubernetes-1-31-custom-profiling-kubectl-debug/ how to use it.

[pauloappbr]

Hi @ardaguclu, thank you for the reference! I've reviewed the Custom Profiling (K8s 1.31) documentation and, while it’s a powerful tool for enforcing security contexts or resource limits, I believe it doesn't solve the specific friction point of this feature request:

Dynamic Volume Discovery: To use --custom for volume sharing, an SRE must first inspect the PodSpec to find the specific volumeName. This manual step is counter-productive during active troubleshooting.

Declarative vs. Operational: The --custom flag is great for reusable profiles (e.g., always attaching a specific set of tools with predefined resource limits). A native --share-volumes flag, however, is an operational shortcut—similar to --share-processes—intended to instantly mirror the target container's environment.

In distroless environments, where we lack basic shell tools, having a one-step command to 'see what the app sees' (logs, configs, certs) without writing a YAML profile would be a significant UX improvement for kubectl.

[pauloappbr]

Hi @ardaguclu, following up on our discussion, I have just opened PR kubernetes/kubernetes#135950 implementing the --share-volumes flag.

After analyzing the Custom Profiling (K8s 1.31) workflow, I’ve validated that while --custom is great for static profiles, a native flag is essential for operational agility. It allows SREs to instantly mirror volume mounts without the manual overhead of inspecting PodSpecs and drafting YAML profiles during an incident.

I’ve successfully tested this implementation in a local cluster, and it provides a seamless experience similar to the existing --share-processes flag. I'd love to get your thoughts on the PR!

[lmktfy]

/transfer kubectl