Docker never uses a different kernel: the kernel is always your host kernel.
If your host kernel is "compatible enough" with the software in the container you want to run it will work; otherwise it won't.
"Containers" Are Just Process Configuration
The key thing to understand is that a Docker container is not a virtual machine: it doesn't create a new virtual computer on which to run the software. Instead, Docker just runs processes in your existing OS, in a similar way to you just starting a process from the command line.
The difference between a containerized process and an ordinary process is the restrictions put on the containerized process and changes to how it sees the environment around it. (These are passed on to any child processes started by the containerized process.) Typical restrictions and changes include:
- Instead of using the host's root filesystem, mount a different filesystem on
/
(usually one supplied with the container's image). Parts of the host filesystem may be mounted underneath the new process' root filesystem, e.g. by using docker run -v /u/myprogram-data:/var/data/myprogram
so that when the containerized process reads or writes /var/data/myprogram/file
this reads/writes /u/myprogram-data/file
in the host filesystem.
- Create a separate process space for the containerized process so that it can see only itself and its children (with
ps
or similar commands), but cannot see other processes running on the host.
- Create a separate user namespace so that the users in the container are different from those in the host: e.g., UID 1234 in the containerized process will not be the same as UID 1234 for non-containerized
- Create a separate set of network interfaces with their own IP addresses, often using a "virtual router" and address translation between those and the host network interfaces. (E.g., the host, when it receives a packet on port 8080, forwards it to port 80 on the container processes' virtual network interface.)
All of this is done by facilities built into the kernel; you can do any of it yourself without Docker if you write a program to do the appropriate setup and set the appropriate parameters when it starts a new process.
Compatibility
So what does "compatible enough" mean? It depends on what requests the program makes of the kernel (system calls) and what features it expects the kernel to support. Some programs make requests that will break things; others don't. For example, on an Ubuntu 18.04 (kernel 4.19) or similar host:
docker run centos:7 bash
works fine.
docker run centos:6 bash
fails with exit code 139, meaning it terminated with a segmentation violation signal; this is because the 4.19 kernel doesn't support something that build of bash
tried to do.
docker run centos:6 ls
works fine, because it's not making a request the kernel can't handle, as bash
was.
If you try docker run centos:6 bash
on an older kernel, say 4.9 or earlier, you'll find it will work fine. (At least as far as I tested it.)
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…