Maybe so, but somehow containers aren't really there yet. As a trivial example, when I 'lsof' a container process (as root), it often cannot "see" all of the information about the process' open files, apparently because they're mapped into a different chroot, or because of other cgroups/namespace issues.

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 failure of userland tools (such as lsof) to correctly show work with containers is unfortunate, but this is partly an artifact of the Linux kernel's somewhat ramshackle approach to containerization.

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

[1] http://man7.org/linux/man-pages/man1/nsenter.1.html

They work for google, however there just arent many companies with the resources of google.

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 ?

Which OS did? From memory this sounds like Plan9.