Hacker News Reader

Comment by amolo | Hacker News Reader

So does this mean you can run containers in containers orchestrating other containers. Containers must really be the holy grail of serverless and cloud "nativeness".

View on HN

Seems reasonable to me. Outside of some weird edge cases and some "technically..."s a container is just a process with its own namespace and file system, and maybe it's own IP. If we didn't have shared-filesystem, shared-namespace, shared-ports processes for historical reasons, who would be clamoring to add them? Why wouldn't you run everything in a container, container-scheduler included?

isn't it more accurate to say, rather that just a process, a process group with its own process numbering?

Technically you can define which namespaces to inherit and which ones to create "from scratch" at process initialization time. (Actually there's an unshare() syscall that does it, but clone() is the standard way to create new namespaces and new processes in them, plus there's setns() to put a thread into some other namespace given a fd pointing to that NS.)

So, namespaces are task level things in the kernel. (Every thread is a task, and by default every process has one thread, so every process is also at least one task.)

https://elixir.bootlin.com/linux/latest/source/include/linux... (That's where the task_struct starts and it has an nsproxy member.)

I mean it's probably not something you want to do in production, but it's a godsend for developing and testing configs.

Reply on news.ycombinator.com