Possibility to connect to CrashLoopbackOff pod about kubectl-debug HOT 9 CLOSED

Sure! I will implement a working prototype this days, hope that fits your case.

from kubectl-debug.

This feature can be really useful but cannot be implemented "directly" IMHO, because the problematic container in the crashing pod is re-created constantly, there is no consistent pid namespace to diagnose the container process.
A possible workaround is 'fork' a new pod, overwrite the container entrypoint to something like 'bash', and diagnose the new pod, which is adopted by the oc debug command. I planned to add the same feature in #1

from kubectl-debug.

Oh sorry, you're right, I should read old issues more carefully.
I was thinking about this problem and come to the same conclusion.
BUT, we need fork bad pod/container with some "bash" command AND possibility to attach to it with debug image at the same time.

Btw, I have a lot of opportunities to test your utility if you interesting.

from kubectl-debug.

@andreioss
I've add the basic support in #11 , would you like to try it out and give me some feedback?

Note: when you enter the debug container, the filesystem of forked container is located in /proc/$pid/root. If you want to run some binaries of forked container, run chroot /proc/$pid/root sh first.

from kubectl-debug.

@aylei
Hi!
Of course I'll try and test!
Should I build plugin binary from your PR files?

from kubectl-debug.

Just fetch the issue-1 branch, or I will release a preview binary this night😄

from kubectl-debug.

If you'll provide the binary, it would be great, thanks :)

from kubectl-debug.

https://github.com/aylei/kubectl-debug/releases/tag/0.0.2-pre

Tested locally and seems fine for me, looking forward to your advice!

from kubectl-debug.

@andreyradygin
I've merged this feature and you may access it in the pre-release before the 0.2.0 release comes out.

from kubectl-debug.