容器，简单来说，是一种自包含的软件打包技术。它将应用程序及其运行所需的一切依赖，如代码、运行时环境、系统工具、系统库等，统统封装在一个独立的运行环境中 。无需再为 “应用在我电脑能跑，上线就崩” 这类环境差异问题而头疼，真正实现了 “Build once, Run anywhere”（一次构建，到处运行）。一、容器是什么？1. 容器技术的定义从技术原理来讲的话，容器是基于 Linux 内核的特性，实现了轻量级的进程隔离。通过巧妙运用命名空间（Namespaces）和控制组（Cgroups），容器内的进程拥有自己独立的资源视图，彼此之间互不干扰，就像在不同的小世界里运行。这不仅保障了应用的稳定运行，启动速度可达到秒级，资源利用率大幅提高，单机可以轻松承载数千个容器实例 ，这是传统部署方式难以企及的。2. 容器与虚拟机区别很多人喜欢把容器说成是“轻量级虚拟机”，这说法吧，也不是全错，但本质上南辕北辙。容器的核心是一组被内核“欺骗”的进程，你把它理解成虚拟机，就默认它有独立内核、独立硬件抽象层。实际上容器啥也没虚拟，它跑的就是普普通通的 Linux 进程，只不过内核通过某种手段（Namespace 和 Cgroups）让这个进程以为自己独占整台机器。虚拟机是基于 Hypervisor（虚拟机监视器）实现的硬件级虚拟化。Hypervisor 如同一个中介，在物理服务器硬件之上模拟出一套完整的硬件环境，每个虚拟机都需要安装独立的操作系统（Guest OS），拥有自己专属的 CPU、内存、磁盘等资源。这就像是在一台物理电脑里又虚拟出多台独立的电脑，每台都能独立运行不同的操作系统和应用，隔离性极强，但代价是资源开销大。虚拟机镜像动辄数 GB，启动时间往往以分钟计算，在资源利用率和启动效率上存在明显短板。反观容器，它属于操作系统级虚拟化，所有容器共享宿主机的 Linux 内核 。容器利用命名空间实现进程、网络、文件系统等资源的隔离，通过 Cgroups 来限制每个容器对 CPU、内存等资源的使用。容器只包含应用及其依赖，镜像体积通常在 MB 级别，启动速度能达到秒级甚至毫秒级，性能表现接近原生应用。在单机部署密度上，容器更是展现出碾压虚拟机的优势，能极大提升硬件资源的利用效率。二、核心机制：命名空间（Namespaces）1. 命名空间技术：进程隔离的基础先来个不那么严谨但好懂的说法：Namespace 就是内核给进程画圈。一个进程被放进圈里，它只能看到圈里的东西。圈外的进程、文件系统、网络接口——统统看不见。不是说它们不存在，而是内核在“视野”层面做了过滤。Linux 里 Namespace 的实现方式是给每个进程绑一组“命名空间标识符”。当一个进程访问系统资源（读 proc、枚举网络接口、发起 IPC），内核先去查它在哪个空间里，然后只返回属于那个空间的内容。Namespace 把“系统全局资源”包装成“每个空间独立的实例”——比如你在容器里 ps aux 只看到容器内那几个进程，不是宿主机 2000 多个，因为内核给你看的 PID 树是假的，或者说，是“被隔离过”的树。这机制和 chroot 很像但比它强太多了。chroot 只改了根目录的映射，Namespace 可以隔离六七个维度：PID、Mount、Network、UTS、IPC、User，再加上后来加的 Cgroup Namespace。每一项都是独立的“视界”。(1) 进程隔离（PID Namespace）PID Namespace 是我最喜欢用的，你跑个容器进去 ps aux，PID 都是从 1 开始排，这个 1 号进程在容器里就是 init，它是所有进程的父进程，负责收养孤儿进程。但你回到宿主机上 ps aux | grep 一下那个容器的进程，你会发现它的 PID 是别的数字，比如 18723。这种“双重身份”怎么做到的？内核在 PID Namespace 里维护了一个 PID 映射表。同一个进程在内核里只有一个“真 PID”，但在不同的 PID Namespace 里可以有不同“视图 PID”。有一回我排查一个问题，在容器里 strace 一个进程的 PID 子进程，在宿主机用 nsenter -t <宿主机PID> -p 进去挂接——搞半天 PID 对不上，最后发现我进错了 Namespace。真丢人。这种低级错误写出来也挺好，提醒自己别犯懒。(2) 文件系统隔离（Mount Namespace）Mount Namespace 主要负责隔离文件系统的挂载点，它让每个容器都拥有自己独立的文件系统视图，简单来说，容器内看到的文件系统结构与宿主机以及其他容器是相互独立的，就像是每个容器都有自己专属的根目录。在 Linux 系统中，文件系统的挂载点决定了进程对文件的访问路径，通过 Mount Namespace，容器可以拥有自己的挂载点集合，这些挂载点仅在容器内部可见。例如，容器可以将宿主机的某个目录挂载到容器内的指定位置，但这个挂载操作只对当前容器有效，不会影响宿主机和其他容器的文件系统布局 。容器在启动时，会基于 Mount Namespace 构建自己的文件系统层级，结合联合文件系统（UnionFS），容器可以将多个只读层和一个可写层叠加在一起，形成一个完整的文件系统，容器内的进程对文件的读写操作都发生在这个独立的文件系统中，不会泄露到宿主机或其他容器中，确保了容器环境的独立性和安全性 。(3) 网络隔离（Network Namespace）：独立的网络栈Network namespace 给每个容器独立的网络栈。自己的 lo 接口、IP 地址、路由表、iptables 规则。容器间通信靠 veth pair，一端在容器里，一端在宿主机上，像虚拟网线一样连着，Docker 默认的 bridge 网络就是这么玩的，你用 ip netns exec 命令进去看，会感觉像开了上帝视角。(4) UTS Namespace：主机名与域名的隔离UTS Namespace 主要负责隔离主机名和域名，允许每个容器设置自己独立的主机名和 NIS（Network Information Service）域名 。这使得容器在网络中可以呈现为一个独立的节点，拥有自己独特的标识。在容器环境中，不同容器可以拥有不同的主机名，彼此之间互不干扰。IPC namespace 管 System V IPC 和 POSIX message queues，进程间通信隔离了，User namespace 最有意思，能把容器里的 root（UID 0）映射成宿主机的普通用户，大大降低了逃逸风险。(5) IPC Namespace：进程间通信隔离IPC Namespace 隔离的是 System V IPC 对象和 POSIX 消息队列。这意味着容器 A 里创建的共享内存段，容器 B 看不见也访问不到。这个维度在一般应用场景里用到的不多，但对安全隔离很重要——你不能让恶意容器通过共享内存去偷隔壁容器的数据。(6) User Namespace：用户 ID 映射与安全隔离这个太重要了，单独多讲几句。User Namespace 允许你在容器里是 root（UID 0），但在宿主机上其实是一个普通用户，比如 UID 65534（nobody）。怎么做到的？内核维护了一个 UID/GID 映射表。比如说你可以配置：容器内的 UID 0 映射到宿主机的 UID 1000，容器内的 UID 1000 映射到宿主机的 UID 2000，以此类推。这个特性是容器安全的基石，没有 User Namespace 的时候，一旦有人从容器里逃逸出来，拿到了 root 权限，宿主机直接沦陷。有了 User Namespace 后，你逃出来了也就是个普通用户，权限非常有限。但这里有个坑——User Namespace 和很多文件系统操作有兼容性问题。我记得好像是三年前我在 Docker 里开 User Namespace 然后挂载 NFS，直接炸了，日志里全是权限错误。原因是 NFS 服务端不认识你的 UID 映射。这类问题至今在部分场景下还存在，所以生产环境启用 User Namespace 之前要做充分测试。