I've always wondered why only Linux can do 'true' containers without VMs. Is there a good blog post or something I can read about the various technical hurdles?
> I've always wondered why only Linux can do 'true' containers without VMs.
Solaris/illumos has been able to do actual "containers" since 2004[0] and FreeBSD has had jails even before that[1].
[0] https://www.usenix.org/legacy/event/lisa04/tech/full_papers/... [1] https://papers.freebsd.org/2000/phk-jails.files/sane2000-jai...
Many OS's have their own (sometimes multiple) container technologies, but the ecosystem and zeitgeist revolves around OCI Linux containers.
So it's more cultural than technical. I believe you can run OCI Windows containers on Windows with no VM, although I haven't tried this myself.
BSD can do BSD containers with Jails for more than a decade now?
Due to innate features of a container, it can be of the same OS of the host running on the system, since they have no kernel. Otherwise you need to go the VM route.
In this context (OCI containers) that seems very inaccurate. For instance, ocijail is a two year old project still considered experimental.
FreeBSD has beta podman (OCI) support right now, using freebsd base images not Linux. It is missing some features but coming along.
Windows can do “true” containers, too. These containers won’t run Linux images, though.
Can it? As far as I understood windows containers required Hyper-V and the images themselves seem to contain an NT kernel.
Not that it helps them run on any other Windows OS other than the version they were built on, it seems.
Source?
The following piece of documentation disagrees:
https://learn.microsoft.com/en-us/virtualization/windowscont...
> Containers build on top of the host operating system's kernel (...), and contain only apps and some lightweight operating system APIs and services that run in user mode
> You can increase the security by using Hyper-V isolation mode to isolate each container in a lightweight VM
Yes, it is based on Windows Jobs API.
Additionally you can decide if the images contain the kernel, or not.
There is nothing in OS containers that specifies the golden rule how the kernel sharing takes place.
Remember containers predate Linux.
I'm not sure about MacOS, but otherwise all major OSs today can run containers natively. However, the interest in non-Linux containers is generally very very low. You can absolutely run Kubernetes as native Windows binaries [0] in native Windows containers, but why would you?
Note that containers, by definition, rely on the host OS kernel. So a Windows container can only run Windows binaries that interact with Windows syscalls. You can't run Linux binaries in a Windows container anymore than you can run them on Windows directly. You can run Word in a Windows container, but not GCC.
[0] https://learn.microsoft.com/en-us/virtualization/windowscont...
I wouldn't think there are many use cases for Windows, but I imagine supporting legacy .NET Framework apps would be a major one.
Is there any limitation in running older.NET Framework on current Windows? Back when I was using it, you could have multiple versions installed at the same time, I think.
You can, but there are companies that also want to deploy different kinds of Windows software into Kubernetes clusters and so.
Some examples would be Sitecore XP/XM, SharePoint, Dynamics deployments.
Containers are essentially just a wrapper tool for a linux kernel feature called cgroups, with some added things such as layered fs and the distribution method.
You can also use just use cgroups with systemd.
Now, you could implement something fairly similar in each OS, but you wouldn't be able to use the vast majority of contained software, because it's ultimately linux software.
cgroups is for controlling resource allocation (CPU, RAM, etc). What you mean is probably namespaces.
Every OS can theoretically do 'true' containers without VMs - for containers which match the host platform.
You can have Windows containers running on Windows, for instance.
Containers themselves are a packaging format, and do rather little to solve the problem of e.g. running Linux-compiled executables on macOS.