kubectl debug: image debugging

[ardaguclu]

What would you like to be added?

Currently, in order to use kubectl debug, user has to pass resource name which should already exist and that might prevent users, if they want to debug just any built image without creating manually.

From kubectl debug ephemeral containers perspective(whose they are running inside the existed pods), this has no meaning. However, from kubectl debug --copy-to perspective, user simply can debug an image by executing;

kubectl debug -it --image=busybox --copy-to=my-debugger

Why is this needed?

In order to debug the built images without relying on any existed resources.

[k8s-ci-robot]

@ardaguclu: 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.

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/test-infra repository.

[ardaguclu]

/sig cli

[ardaguclu]

@verb what do you think about this feature request?, if you have any concerns or think that not an general use case, I can close issue.

cc: @soltysh @KnVerey @eddiezane @brianpursley

[verb]

Hi @ardaguclu, I think this use case is more intuitive for kubectl run. Is there anything that kubectl debug would provide that's not provided by kubectl run?

[ardaguclu]

@verb thanks for the response!

We had an exact same discussion in downstream(oc) about this and basically the argument is;

"Debug is better than run because debug is solving a different problem - debug is "how do i get a shell in an environment efficiently". Run is about "how do i actually launch a pod". The two are not equal. And run frankly is a ux nightmare, while debug is about making opinionated choices to get that experience cleanly." ref

That said it is more about semantically instead functionality.

[sftim]

Should we track this as a kubectl issue (ie: prow command /transfer kubectl)?

[ardaguclu]

Thanks @sftim

/transfer kubectl

[eddiezane]

/triage accepted