This is one of a number of issues that make containers hard to deal with.
(We also see an issue where containers interact badly with the OOM killer, leading the entire system to hang because /proc/*/cmdline cannot be read at all.)
This is one of a number of issues that make containers hard to deal with.
(We also see an issue where containers interact badly with the OOM killer, leading the entire system to hang because /proc/*/cmdline cannot be read at all.)
The kernel doesn't have a concept of containers, but rather of kernel namespaces. For example, it's possible for a process to create a new namespace that is the same as that of a default process, except with a new file system namespace — i.e., a chroot.
Hopefully we'll see these tools updated to better understand kernel namespaces. In the meantime, if you need to interact with containers, use the nsenter [1] tool. For example, it allows you to enter the same PID namespace as the container, but still use the host file system.
For example, run to lsof against a container's PID 1 (corresponding to the host PID 1234):
$ nsenter -p 1234 lsof -p 1
If you had a small army of SRE and seriously senior devs / devops you could easily manage containers.
If you are just stuck on running containers and k8s I suggest you leverage their resources and get to GKE
But then releasing k8s might just have been the plan to get people into GKE instead of AWS
Who am I to speculate on googles marketing acumen ?