[regularfry]

You've gained that happening much less frequently. The tradeoff is making every other problem harder to diagnose.

[NewJazz]

Debug containers are a thing.

Add an ephemeral container to an already running pod, for example to add debugging utilities without restarting the pod.

https://kubernetes.io/docs/reference/kubectl/generated/kubec...

[xmodem]

Yup! They are a good solution to the massive problem you caused for yourself by implementing a different "solution" to a non-problem.

And even that's only true if you assume kubernetes is the only place your container runs where you might want to also debug it.

[NewJazz]

You want to ship every debug utility you will need in every image? Just seems wasteful. What about 3rd party images, you will respin images just to add your preferred toolset?

[xp84]

> every debug utility you will need in every image? Just seems wasteful

How wasteful though? I have to admit, I envy the person whose codebase itself they have to support is so lean and space-conservative that the size of the gnu coreutils, curl, nano, etc., would show up as anything but a rounding error in the image size.

I see it like putting a thermometer in a turkey before I stick it in the oven. Sure, the thermometer adds thermal mass itself, making the turkey take a few seconds longer to cook, but the value of it being there is greater than the cost imposed.

[xmodem]

Nope, not my position at all. I want to have a minimal OS environment with rudimentary tools available with zero extra friction. FROM alpine:latest adds less than 10MB and covers 95% of use cases. Typically depending on the container I will often throw in curl and some other QoL tools too.

For the rare cases where you find yourself needing to attach a debugger to your pods running in staging/prod, a debug container is absolutely the right tool to reach for.