I often see the advantage of containerisation over virtual machines is that containers use the host operating system's kernel and what not, whereas each virtual machine requires it's own operating system, thus containers have much less overhead. (image for reference.)
However, all docker containers also have some operating system that it runs on (eg. ubuntu, alpine etc.). And you can have different versions of these operating systems in different images. Now I imagine that the host and container OS just need to be somewhat relatable, and then the commands can be translated from container to host commands. But what happens if the command in the container is something that would've worked on, say Ubuntu 14, but doesnt work on the hosts Ubuntu 22? And can you run containers of completely unrelated OS', like a Windows container on Ubuntu host?
https://www.howtogeek.com/wp-content/uploads/csit/2019/06/bc4f8762.png
答案1
Now I imagine that the host and container OS just need to be somewhat relatable, and then the commands can be translated from container to host commands.
There's mostly no translation being done – "userspace" software running in the container talks directly to the host kernel. All that changes is that the kernel gives containers a different view of the filesystem, the process tree, etc. (i.e. different "namespaces"), but other than that, processes inside a container are still just processes running in the host OS.
But what happens if the command in the container is something that would've worked on, say Ubuntu 14, but doesnt work on the hosts Ubuntu 22?
Then you run Ubuntu 14 on a full VM.
Incompatibilities between the host kernel and the guest "userspace" software should be relatively rare. Although the Linux kernel does occassionally remove functionality (such as the recent removal of support for "a.out" binaries), most "apps" that you'd containerize do not actually rely on the exotic system calls all that much. It's similar to how you can still run many Win2000 apps on a Win11 system.
But most incompatible changes occur within userspace code – e.g. newer libraries becoming incompatible with older services; newer PHP or Python runtime being incompatible with older webapp code – but that's exactly what gets "containerized", each container has its own libraries and everything.
And can you run containers of completely unrelated OS', like a Windows container on Ubuntu host?
Generally no, in order for it to really be "Windows" you would need to actually run the Windows kernel (i.e. practically become a VM).
Linux in general can run a lot of Windows software through WINE (and you could certainly use WINE inside a Linux container), but that's not quite the same as actually running Windows itself.
(Similarly, if the host is Windows or FreeBSD, they both can emulate the Linux kernel to some extent and run unmodified Linux binaries – on Windows that's called "WSL 1", on FreeBSD you could probably create a 'jail' with Linux compatibility enabled and run certain Linux services that way.)
That being said, if the goal of containers is to reduce resource usage, you could also run VMs that do not have a "full" OS and therefore use less resources – for example, Windows Server has various trimmed-down variants without GUI, such as Nano Server specifically for container-like usage.