Docker面试题汇总系列

文章目录

前言
- 第一篇：基础概念篇
- - [1. Docker是什么？为什么需要Docker？](#1. Docker是什么？为什么需要Docker？)
  - [2. Docker的整体架构是怎样的？](#2. Docker的整体架构是怎样的？)
  - [3. Docker镜像和容器的本质区别是什么？](#3. Docker镜像和容器的本质区别是什么？)
  - [4. Docker镜像为什么要分层？UnionFS是什么？](#4. Docker镜像为什么要分层？UnionFS是什么？)
  - [5. Docker容器的数据是如何持久化的？为什么删除容器数据就没了？](#5. Docker容器的数据是如何持久化的？为什么删除容器数据就没了？)
  - [6. Dockerfile是什么？CMD和ENTRYPOINT有什么区别？](#6. Dockerfile是什么？CMD和ENTRYPOINT有什么区别？)
- 第二篇：网络篇
- - [1. Docker的网络模型有哪些？](#1. Docker的网络模型有哪些？)
  - [2. 容器端口映射是怎么实现的？](#2. 容器端口映射是怎么实现的？)
  - [3. Docker容器跨主机通信是怎么实现的？Overlay网络原理是什么？](#3. Docker容器跨主机通信是怎么实现的？Overlay网络原理是什么？)
  - [4. 容器是如何访问宿主机和外网的？](#4. 容器是如何访问宿主机和外网的？)
- 第三篇：存储篇
- - [1. Docker为什么要设计Volume和Bind Mount？它们分别解决什么问题？](#1. Docker为什么要设计Volume和Bind Mount？它们分别解决什么问题？)
  - [2. Volume的数据存在哪里？生命周期是怎么样的？](#2. Volume的数据存在哪里？生命周期是怎么样的？)
  - [3. Docker Volume 的常见坑有哪些？如何清理与治理？](#3. Docker Volume 的常见坑有哪些？如何清理与治理？)
- 第四篇：Docker安全与权限篇
- - [1. 为什么不推荐容器以root用户运行？Docker是如何做权限隔离的？](#1. 为什么不推荐容器以root用户运行？Docker是如何做权限隔离的？)
  - [2. Docker的Capabilities是什么？为什么CAP_SYS_ADMIN特别危险？](#2. Docker的Capabilities是什么？为什么CAP_SYS_ADMIN特别危险？)
  - [3. Docker的Cgroups是什么？它是如何限制CPU/内存/IO的？](#3. Docker的Cgroups是什么？它是如何限制CPU/内存/IO的？)
- [第五篇：Docker CI/CD与实战优化篇](#第五篇：Docker CI/CD与实战优化篇)
- - [1. Docker镜像是如何构建的？如何优化镜像大小和构建速度？](#1. Docker镜像是如何构建的？如何优化镜像大小和构建速度？)
总结

前言

最近在准备跳槽的事情，但是并不算太如意，在复习的过程中我逐渐意识到一个问题：Docker 我用得不少，但真要在面试中系统、清晰地讲明白，却并不容易

很多场景在项目里早已驾轻就熟，比如写 Dockerfile、构建镜像、跑容器、排查问题，但这些更多停留在"会用"层面

而面试官更关心的可能是：

你是否理解 Docker 的核心设计思想
是否能讲清楚镜像、容器、网络、存储、权限、安全背后的原理
是否真正知道为什么要这样用，而不是那样用

这些零散的知识点，如果不系统整理，很容易在面试中答得断断续续，甚至自己都觉得"讲不清楚"，于是我决定把这次复习过程系统化，整理成一个《Docker面试题汇总系列》

这个系列有几个目标：

从面试视角重新梳理 Docker 知识体系
不只给"结论式答案"，更强调原理、设计逻辑和使用边界
把项目中用过但说不清的东西，变成能被清楚表达的能力

内容包括但不限于：

Docker 核心概念与架构
镜像与容器原理
Dockerfile 与镜像构建优化
容器网络模型
数据卷与存储机制
Docker 与 CI/CD
真实项目中的常见问题与优化思路

这个系列既是我自己的复习笔记，也希望能成为你准备 Docker / 云原生相关面试的一份参考

第一篇：基础概念篇

1. Docker是什么？为什么需要Docker？

Docker 是一种容器技术，通过 OS 级虚拟化把应用及其运行环境打包成镜像
它解决了环境不一致、部署复杂和交付不标准的问题
相比虚拟机，Docker 不虚拟完整操作系统，而是隔离进程，因此更轻量、启动更快，更适合微服务和 CI / CD 场景

2. Docker的整体架构是怎样的？

从使用层面看，Docker 的核心概念包括镜像、容器和仓库
从系统层面看，Docker 采用 C/S 架构，由 Client、Daemon 和 Registry 组成，Client 负责接收用户命令并通过 API 发送给 Daemon，Daemon 负责镜像和容器的实际管理，Registry 用于镜像的存储和分发
一次 docker run 大致流程为 Client 将 run 命令发送给 Daemon，Daemon 检查本地是否存在镜像，若不存在则向 Registry 拉取镜像，并基于镜像创建容器（创建 Namespace、配置 Cgroups、挂载 UnionFS），最后启动容器进程

3. Docker镜像和容器的本质区别是什么？

Docker 镜像是一个只读的分层文件系统模板；而 Docker 容器是基于镜像创建的、带有独立读写层的运行时进程
镜像的本质是由多层（Layer）组成的只读文件系统，每一层对应 Dockerfile 中的一条指令，通过 UnionFS 叠加在一起，只读且不可变，通常包含基础操作系统、应用运行环境、应用代码、启动指令等，镜像本身不运行任何东西
容器本质上是宿主机上的一组进程，区别在于容器被 Namespace 隔离，被 Cgroups 限制资源，拥有独立的 PID、网络等，当镜像变成容器时，Docker 会在镜像最上层增加一个可写层所有运行时产生的数据（如日志、临时文件、进程状态）都写在这个可写层中，容器 = 镜像 + 可写层 + 运行时状态

4. Docker镜像为什么要分层？UnionFS是什么？

Docker 镜像采用分层结构，是为了镜像复用、加快构建与分发效率；UnionFS 通过将多个只读层叠加成一个统一的文件系统视图，使容器看起来像在使用一个完整的文件系统
Dockerfile 每一条指令（如 FROM、COPY、RUN）都会生成一个新的镜像层（Layer），UnionFS 是一类文件系统的统称，核心能力是将多个目录（层）联合挂载，呈现为一个统一的文件系统视图，在运行容器时，UnionFS 会把它们从上到下叠加，生成一个看起来完整的文件系统，Docker 会在最上面加一层可写层，所有写操作都发生在这个可写层

5. Docker容器的数据是如何持久化的？为什么删除容器数据就没了？

Docker 容器默认是无状态的，容器运行时产生的数据存放在容器的可写层中；当容器被删除时，可写层随之销毁，因此数据会丢失；Docker 可以通过 Volume 或 Bind Mount 将数据挂载到宿主机或外部存储，实现数据持久化
Volume（存储卷）的特点是由 Docker 管理，独立与容器生命周期，存储在 Docker 的数据目录中，支持跨容器共享，可通过 docker volume create mydata + docker run -v mydata:/data 实现
Bind Mount（目录绑定）的特点是直接挂载宿主机目录，对宿主机路径强依赖，可通过 docker run -v /host/data:/data 实现

6. Dockerfile是什么？CMD和ENTRYPOINT有什么区别？

Dockerfile 是用来描述如何构建 Docker 镜像的声明式文件；CMD 和 ENTRYPOINT 用于定义容器启动时执行的默认命令，ENTRYPOINT 更偏向于"固定入口"，CMD 更偏向于"默认参数"
Dockerfile 本质上是一组用于描述镜像构建过程的指令集合，解决了镜像构建过程标准化、可追溯的问题，是"镜像的源代码"
当 CMD 和 ENTRYPOINT 同时存在时，Docker 会将 CMD 作为参数传递给 ENTRYPOINT，在运行容器时，CMD 可以被覆盖，而 ENTRYPOINT 默认不会被覆盖，除非显式使用 --entrypoint

第二篇：网络篇

1. Docker的网络模型有哪些？

bridge：默认网络模式，每个容器拥有独立 IP，Docker 在宿主机创建 docker0 网桥，每个容器分配一个虚拟网卡（veth pair），一端在容器内部，另一端挂载 docker0 上，容器通过 NAT + iptables 与宿主机及外网通信，容器间通信默认不跨主机，同一 bridge 网络的容器可以互相访问，跨主机通信需要 overlay
host：容器共享宿主机网络，容器内部运行的进程和宿主机一样，使用宿主机 IP，不走 NAT，优点是性能高延迟低
none：容器没有任何网络接口，适合安全或测试场景
Docker 可以自定义网络，同一网络内容器名可直接解析

2. 容器端口映射是怎么实现的？

Docker 的 -p 外部端口:内部端口是通过 iptables 的 DNAT + SNAT 将宿主机请求转发到容器内部虚拟网卡（veth pair），容器内应用无需感知外部端口变化
docker run -p 80:80 实际上做的事情是，当外部访问宿主机 80端口，Docker 会在宿主机生成 iptables 规则，通过 DNAT 将宿主机 80 端口流量重定向到容器 IP:80，通过 SNAT 保证容器响应数据包返回宿主机实现端口映射

3. Docker容器跨主机通信是怎么实现的？Overlay网络原理是什么？

Docker 跨主机通信通常通过 Overlay 网络实现，它在每台宿主机上创建虚拟网络，通过 VXLAN 隧道封装容器数据包，让不同主机的容器像在同一 L2 网络中通信，Overlay 网络通常由 Docker Swarm 或 Kubernetes CNI 管理，每个节点运行一个控制平面，维护容器 IP 映射表，节点间自动建立 VXLAN 隧道，用户只需用 docker network create -d ovelay mynet，无需关心底层细节
VXLAN 是 Overlay 的核心，原理是容器 A 要发数据给跨主机的容器 B - > 数据包在本地主机封装成 UDP VXLAN 包 -> 发送给宿主机 B 的物理 IP -> 宿主机 B 解封装 VXLAN，交给容器 B

4. 容器是如何访问宿主机和外网的？

Docker 容器访问宿主机和外网，本质上是通过宿主机作为网关进行 SNAT 转换，容器的流量最终以宿主机 IP 对外通信

第三篇：存储篇

1. Docker为什么要设计Volume和Bind Mount？它们分别解决什么问题？

Docker 之所以同时提供 Volume 和 Bind Mount，是为了在"可移植性、隔离性、可控性"与"灵活性、可调试性"之间做取舍，分别覆盖生产环境与开发调试场景
Bind Mount 的特点是：路径由用户指定、数据完全暴露给宿主机、容器对宿主机有强依赖，代价是：依赖宿主机目录结构、不利于容器迁移、安全边界较弱（容器可影响宿主机文件）等，所以不适合标准化、可复制的生产部署
Volume 带来的能力是：容器可随意销毁重建、减少人为误操作宿主机目录、方便对接外部存储（NFS / 云盘），它不关心宿主机具体路径，生命周期独立于容器，可以被多个容器复用，由 Docker 统一管理和回收，因此生产环境优先考虑 Volume

2. Volume的数据存在哪里？生命周期是怎么样的？

Docker volume 的数据默认存储在宿主机的 /var/lib/docker/volumes/<volume_name>/_data 中，Volume 的生命周期独立于容器，删除容器不会删除 Volume，除非使用 docker volume rm 显式删除
在 docker run -v mydata:/data 这条命令中，Docker 找到 Volume 对应的 _data 目录，把它挂载到容器的 /data 目录，屏蔽容器原有 /data 内容（如果有）
使用 docker run -v /data 运行容器，Docker 会自动生成随机 Volume 名，不好管理；通常是通过 docker create volume mydata 创建存储卷后再使用 docker run -v mydata:/data 运行容器
数据库容器必须使用 Volume，是因为数据库的数据生命周期远大于容器生命周期，并且对数据一致性、可靠性和可恢复性有严格要求，容器层存储无法满足这些需求，使用 Bind Mount 挂载数据库数据目录会存在数据耦合、宿主机权限容易踩坑、容器迁移成本较高等问题

3. Docker Volume 的常见坑有哪些？如何清理与治理？

使用 docker rm 的时候删除容器，但是 Volume 没删，是因为 Docker 为了防止误删数据默认不自动删除 Volume，可通过 docker volume ls + docker volume inspect mydata 查看 Volume 使用情况，再通过 docker volume prune 清理未使用的 Volume（慎用）
匿名 Volume 堆积如山，名字不可读很难判断能不能删，生产环境强烈建议命名规范
Volume 实际磁盘满了，但容器还在跑，最终会导致异常 Docker daemon 不可用，应定期巡检磁盘使用率

第四篇：Docker安全与权限篇

1. 为什么不推荐容器以root用户运行？Docker是如何做权限隔离的？

容器默认以 root 运行，但这个 root 本质上仍然是宿主机内核视角下的 root，一旦容器逃逸或配置不当，可能直接威胁宿主机安全，因此生产环境不推荐以 root 用户运行容器
Docker 通过 Linux Namespace 和 Cgroups 对容器进行隔离，其中 Namespace 用于隔离进程、网络、文件系统等视图，Cgroups 用于限制资源使用，但它们并不能完全消除 root 带来的安全风险
Docker 通过 Linux Capabilities 将 root 权限拆分，只授予容器必要的能力，从而降低权限等级，但仍需遵循最小权限原则
在生产环境中，通常通过指定非 root 用户（Dockerfile指定 USER 或 docker run --user）、限制 Capabilities（docker run --cap-drop ALL）、启用只读文件系统（docker run --read-only）等方式进一步提升容器安全性

2. Docker的Capabilities是什么？为什么CAP_SYS_ADMIN特别危险？

Docker 的 Capabilities 机制，本质上是对 root 权限的拆解与最小化控制，而 CAP_SYS_ADMIN 由于承载了大量系统级操作能力，实际上成为了"事实上的超级权限"，在容器安全中应被严格限制
赋予 CAP_SYS_ADMIN 在很多场景下等价于赋予 root 权限，会存在容器逃逸风险，在实际生产环境中应避免使用 --privileged 或随意添加 CAP_SYS_ADMIN，坚持最小权限原则

3. Docker的Cgroups是什么？它是如何限制CPU/内存/IO的？

Cgroups 是 Linux 内核提供的资源控制机制，用来限制、统计和隔离进程对 CPU、内存、磁盘 IO 等资源的使用，Docker 正是通过 Cgoups 来防止容器抢占宿主机资源
Docker 可通过 docker run --cpus=2 限制容器最多使用两个 CPU 核心，或通过 docker run --cpuset-cpu=0,1 指定容器只能在 CPU 0、1 上运行
Docker 可通过 docker run -m 512m 限制内存，当超过内存限制内核会触发 OOM KILL，杀掉容器里的主进程

第五篇：Docker CI/CD与实战优化篇

1. Docker镜像是如何构建的？如何优化镜像大小和构建速度？

镜像分层与缓存机制：Docker 镜像由多层（Layer）组成，每条 Dockerfile 指令都会生成一层；构建时，如果某层没有变化，Docker 会直接复用缓存，从而加快构建速度
构建速度优化：将不常变化的指令（如安装依赖）放在前面，减少缓存失效；使用 .dockerignore 忽略不必要的文件，减少上下文传输
镜像体积优化：选择轻量基础镜像（如 alpine）；使用多阶段构建，只把最终产物复制到运行镜像；合并 RUN 指令并清理临时文件，减少层数

总结

先更新到这里，后续会将剩下的内容补充完整

如果这篇文章对你有帮助，欢迎点赞关注支持一下～