Docker 深度解析:从 Namespace 到 UnionFS,吃透容器化核心原理(含 VM 对比 + 实战关联)
1、Docker 架构:客户端 - 服务器(C/S)模型... 2
一、Docker 核心定义
Docker 是基于 Linux 内核容器(Linux Container的简写:LXC)技术发展而来的开源容器化平台,遵循 Apache 2.0 协议,通过操作系统级虚拟化技术,实现应用及其依赖环境的标准化打包、分发与运行。
其核心价值在于打破 “开发 - 测试 - 生产” 环境壁垒,构建 “一次构建,处处运行” 的软件交付链路,本质是对 Linux Namespace、Cgroups、UnionFS 等内核特性的封装与抽象,为应用提供轻量级、可移植的隔离运行环境。
docker官网:https://www.docker.com
docker中文库:https://www.docker.org.cn/
二、Docker 核心使用场景
- 微服务架构部署:在 Kubernetes 等编排平台中,Docker 作为基础运行单元,实现微服务的独立打包(每个服务封装为独立容器)、弹性伸缩(基于容器实例快速扩缩容)与灰度发布(通过容器版本切换实现流量切分),解决单体应用部署复杂、扩展受限问题。
- 持续集成 / 持续交付(CI/CD):集成于 Jenkins、GitLab CI 等流水线工具,在构建阶段通过 Dockerfile 生成应用镜像,测试阶段基于镜像启动隔离容器执行自动化测试,部署阶段直接推送镜像至生产环境,消除 “构建环境与运行环境差异” 导致的交付故障。
- 多版本应用隔离:针对同一应用的不同版本(如 V1.0、V2.0),通过独立容器实现运行时隔离,共享主机内核资源的同时,避免依赖冲突(如不同版本 Python 库、数据库驱动),支持并行测试与版本快速回滚。
- 资源密集型场景优化:在大数据、AI 训练等场景中,通过 Docker 容器对 CPU、内存、IO 等资源进行精细化限制(基于 Cgroups),避免单任务资源抢占导致的集群性能波动,提升硬件资源利用率。
三、Docker 技术原理深度剖析
1、Docker 架构:客户端 - 服务器(C/S)模型
Docker 架构采用客户端 - 服务器(C/S)模型,核心组件包括 Docker Client、Docker Daemon、Containerd、RunC,底层依赖 Linux 内核三大核心技术:

- Client 通过接口与Server(docker_host)进程通信实现容器的构建,运行和发布。
- 用户不能与服务端直接交互,Docker 客户端为用户提供一系列可执行命令,用户通过这些命令与 Docker 服务端进行交互。用户使用的 Docker 可执行命令就是客户端程序。与 Docker 服务端不同的是,客户端发送命令后,等待服务端返回信息,收到返回信息后,客户端立刻执行结束并退出。用户执行新的命令时,需要再次调用客户端命令。
- Docker 服务端也就是 Docker daemon,一般在宿主机后台运行,接收来自客户的请求、并处理这些请求。在设计上,Docker 服务端是一个模块化的架构,通过专门的 Engine 模块来分发、管理各个来自客户端的任务。
- client和server可以运行在同一台集群,也可以通过跨主机实现远程通信。
所以,docker命令是从客户端命令行输入,然后发往docker服务器(docker daemon)处执行。
2、Namespace:实现容器隔离
namespace是对全局系统资源的一种封装隔离。这样可以让不同namespace的进程拥有独立的全局系统资源。
改变一个namespace的系统资源只会影响当前namespace中的进程,对其它namespace中的资源没有影响。以前Linux也有一个系统调用chroot和namespace类似。chroot内部不能访问外部的内容,namespce在此基础上提供了UTS、IPC、mount、PID、network、User等6 类隔离机制,对容器资源进行隔离:
为了支持这些特性,Linux namespace 实现了 6 项资源隔离,基本上涵盖了一个小型操作系统的运行要素,包括主机名、用户权限、文件系统、网络、进程号、进程间通信。
2.1 Namespace的6大类型汇总
| 序号 | namespace | 系统调用参数 | 功能说明 |
| 1 | User | CLONE_NEWUSER | 提供User 用户和组权限隔离 |
| 2 | UTS | CLONE_NEWUTS | (UNIX Time-sharing SystemUNIX 分时系统)提供主机名和域名的隔离 |
| 3 | PID | CLONE_NEWPID | 提供进程的 ID 空间隔离 |
| 4 | IPC | CLONE_NEWIPC | (Inter-Process Communication进程间通信)提供进程间通信隔离 |
| 5 | Network | CLONE_NEWNET | 提供独立的网络设备、网络栈,端口等隔离 |
| 6 | Mount | CLONE_NEWNS | 提供磁盘挂载点和文件系统的隔离 |
2.2 Namespace的6大类型详细介绍
1)User Namespace
用来隔离 User 权限相关的 Linux 资源,包括 User IDs 和 Group IDs。 这是目前实现的 Namespace 中最复杂的一个,因为 User 和权限息息相关,而权限又关联着容器的安全问题。 在不同的 User Namespace 中,同样一个用户的 User ID 和 Group ID 可以不一样。也就是说,一个用户可以在父 User Namespace 中是普通用户,在子 User Namespace 中是超级用户。
2)UTSNamespace
(UNIX Time-sharing System,UNIX 分时系统)提供主机名和域名的隔离,使子进程有独立的主机名和域名,这一特性在 Docker 容器技术中被运用,使 Docker 容器在网络上被视作一个独立的节点,而不仅仅是宿主机上的一个进程。
在容器中对 hostname 的命名不会对宿主机造成任何影响。
3)PID Namespace
用来隔离进程的 ID 空间,使不同 PID Namespace 里的进程 ID 号可以重复且相互之间不影响。PID Namespace 可以嵌套,也就是说有父子关系。在当前 Namespace 里面创建的所有新的 Namespace 都是当前 Namespace 的子 Namespace。在父 Namespace 里面可以 “看到” 所有子 Namespace 里的进程信息,而在子 Namespace 里看不到父 Namespacelode 与其他子 Namespacelode 进程信息,如图所示;

4) IPC Namespace
(Inter-Process Communication,进程间通信)是 UNIX 与 Linux 下进程间通信的一种方式。它实现了进程间通信的隔离,包括常见的几种进程间通信机制,如信号量,消息队列和共享内存等方式。此外,对 IPC 进行隔离后,只有在同一个 Namespace 下的进程才能相互通信。 IPC 需要有一个全局的 ID,既然是全局的,就意味着 Namespace 需要对这个 ID 号进行 隔离,不能让其他 Namespace 的进程 “看到”。
5)Network Namespace
为容器分配独立网络栈,IP 地址,IP 路由表,/proc/net 目录,端口号等。这也使得一个 host 上多个容器内的网络设备都是互相隔离的。
6)Mount Namespace
使容器拥有独立文件系统挂载点,避免主机与容器文件系统干扰。
3、Cgroups:实现资源限制
全称 Control Groups,是一个非常强大的linux内核工具,他不仅可以限制被namespace隔离起来的资源,还可以为资源设置权重、计算使用量、操控进程启停等等。
通过对 CPU(CPU Shares、CPU Quota)、内存(Memory Limit、OOM Control)、块设备 IO(BlkIO Weight)、网络带宽等资源的配额管理,防止单个容器过度占用主机资源,保障多容器并发运行的稳定性。所以cgroups实现了对资源的配额和度量。
3.1 cgroups有四大功能:
- 资源限制:可以对任务使用的资源总额进行限制;
- 先级分配:通过分配的cpu时间片数量以及磁盘I0带宽大小,实际上相当于控制了任务运行优先级;
- 资源统计:可以统计系统的资源使用量,如cpu时长, 内存用量等;
- 任务控制: cgroup可以对任务执行挂起、恢复等操作。
3.2.CPU资源限制
Linux通过CFS ( Completely Fair Scheduler, 完全公平调度器)来调度各个进程对CPU的使用。CFS默认的调度周期是100ms。可以设置每个容器进程的调度周期,以及在这个周期内各个容器最多能使用多少CPU时间。使用–cpu-period即可设置调度周期,使用–cpu-quota即可设置在每个周期内容器能使用的CPU时间。两者可以配合使用。
CFS周期的有效范围是1ms~1s, 对应的–cpu-period的数值范围是1000~1000000。容器的CPU 配额必须不小于1ms,即–cpu-quota 的值必须>= 1000。

3.3 对内存使用进行限制

限制内存使用

3.4 对磁盘IO配额控制(blkio)的限制

4、UnionFS:实现镜像分层存储
采用分层读写机制(如 AUFS、Overlay2),镜像由多个只读层(Layer)叠加而成,容器启动时在镜像顶层添加可写层。当容器修改文件时,仅在可写层操作(Copy-on-Write 机制),避免镜像层被篡改,同时实现镜像层复用(不同镜像可共享相同基础层,减少存储占用)。
四、Docker 与 VM 虚拟机的技术对比
| 对比维度 | Docker(容器) | VM(虚拟机) | 技术差异解析 |
| 虚拟化层级 | 操作系统级虚拟化(共享主机内核) | 硬件级虚拟化(模拟硬件) | Docker 无需 Hypervisor 层,直接调用主机内核,虚拟化开销降低 90% 以上;VM 需通过 Hypervisor(如 VMware、KVM)模拟 CPU、内存等硬件,资源损耗高。 |
| 启动时间 | 毫秒至秒级(平均 1-3 秒) | 分钟级(平均 30-60 秒) | Docker 仅需初始化容器进程与隔离环境,无需启动完整操作系统;VM 需加载 OS 内核、初始化系统服务,启动链路长。 |
| 资源占用 | 轻量级(单容器内存占用 MB 级) | 重量级(单 VM 内存占用 GB 级) | Docker 共享主机内核,无需为每个实例分配独立内核与系统资源;VM 需为每个实例分配独立内存、磁盘空间,资源利用率低。 |
| 隔离强度 | 进程级隔离(弱隔离) | 完全隔离(强隔离) | Docker 容器共享主机内核,存在内核漏洞导致的逃逸风险;VM 拥有独立内核与硬件环境,隔离强度等同于物理机,安全性更高。 |
| 镜像 / 镜像管理 | 分层存储(Layer),支持增量更新 | 完整磁盘镜像(如 VMDK),更新体积大 | Docker 镜像分层复用,更新时仅传输差异层(如基础层不变,仅更新应用层);VM 镜像为单一文件,更新需传输完整镜像,效率低。 |
更多推荐
所有评论(0)