you want to be able to "ssh in and make changes to figure out how to fix things". why doesn't that do that for you?

Sorry, but did you not forget the --rm option to remove the container once it dies ?

For both docker and k8s, that command is 'exec into already running container', not 'spin up a new container'.

This is all getting quite heated! Please take it outside.

This was a joke. Humour.

Please contain yourself.

I interpret it as a suggestion that you allow developers access to the running container in production to debug the issue

There are more sane ways to do this than through raw kubectl access, of course: see e.g. telepresence (https://www.telepresence.io/)

By sane, you mean yet another piece of infrastructure that has to be installed, documented, packaged into containers, deployed and updated for a problem that did not exist without containers. For a very large organization (e.g. hundreds of devs) this make sense, but for a medium sized company (> billion EUR turnover per year outside of software business) this soon becomes just another piece of overhead.

This problem certainly exists without containers.

- How do you provide easy visibility into running applications?

- How do you prevent inspecting an application from affecting the behavior of an application?

You put this fairly succinctly. And I agree wholeheartedly.

I think of the phrase “adding epicycles” when this kind of stuff starts happening.