Docker容器进程疑问：为何容器内ps -aux仅显示服务进程？

这个问题问到点子上了——这正是Docker和你之前用的传统虚拟机最核心的区别之一！我来一步步给你掰扯清楚：

1. 为啥容器里ps -aux看不到系统进程？ #

传统虚拟机是完整的操作系统，有自己的init（或systemd）进程作为PID 1，所有系统进程（比如sshd、crond这些）都是它的子进程，所以你用ps -aux能看到全量进程。

但Docker容器不一样，它默认用Linux PID命名空间做隔离：每个容器都有自己独立的PID编号空间。容器启动时，你指定的启动进程（比如你登录容器用的bash，或者你部署的服务）会成为容器里的PID 1，而宿主机的系统进程、其他容器的进程都在另一个独立的PID命名空间里，容器内部完全看不到。

举个例子：你在容器里执行ps -aux，看到的PID 1就是你当前的bash，其他只有你自己安装的服务进程——这不是系统进程“消失”了，而是容器的隔离机制让你看不到外面的空间。

2. 那些系统进程到底在哪？ #

所有系统进程都在宿主机（或Docker依托的虚拟机）的根PID命名空间里。你可以直接在宿主机（如果是Linux）或者Docker Desktop里的那个Linux虚拟机终端里执行ps -aux，就能看到所有进程，包括容器里的进程（只不过容器内的进程在宿主机上有一个真实的PID编号，和容器内部的PID不一样）。

如果你想快速查看某个容器对应的宿主机进程，也可以用Docker自带的命令：docker top <你的容器ID/名称>，它会直接列出容器内进程在宿主机上的PID、用户等信息。

3. 这个隔离机制是怎么运作的？ #

Docker的核心是利用Linux内核的**命名空间（Namespace）**特性，其中PID命名空间就是用来隔离进程视图的：

• 当创建容器时，Docker会给它分配一个全新的PID命名空间；
• 容器内的所有进程都在这个命名空间里重新编号，从PID 1开始；
• 每个命名空间里的进程只能看到自己空间内的进程，无法访问其他命名空间的进程；
• 除了PID命名空间，Docker还会用Mount、Network、User等命名空间，分别实现文件系统、网络、用户权限的隔离，让容器看起来像一个独立的系统，但实际上共享宿主机的内核。

这里还要提一句：容器默认没有传统OS的init进程，如果你容器里的主进程（比如bash）退出，整个容器就会停止。如果需要容器内有类似init的进程来管理子进程，可以用tini这类工具作为PID 1，它会帮你回收僵尸进程、管理子进程生命周期。

4. 宿主操作系统（虚拟机）被容器化了吗？ #

先纠正一个小误区：Docker在Linux物理机上是直接运行在Linux内核上的，不需要虚拟机；只有在Windows/macOS上，因为没有原生Linux内核，Docker Desktop才会启动一个轻量Linux虚拟机来提供内核环境。

然后回到问题：宿主操作系统（不管是物理机Linux还是虚拟机里的Linux）并没有被容器化。容器所谓的“基于debian:jessie镜像”，其实只是借用了debian的用户空间文件系统（比如/bin、/etc这些目录里的内容），而内核是完全共享宿主机（或虚拟机）的Linux内核。

换句话说：不同发行版的容器，只是用户空间的工具、库、配置不一样，底层内核都是同一个。比如你用debian容器和ubuntu容器，它们的内核都是宿主机的Linux内核，只是用户层的软件包不同而已。

内容的提问来源于stack exchange，提问作者Valdir