Created状态表示容器已初始化配置但未启动进程,仅注册元数据,无PID命名空间、零CPU占用、内存仅存几MB元数据、磁盘占用镜像层与可写层、网络默认不配置。

容器处于 Created 状态,表示镜像已成功加载并完成初始化配置,但尚未启动进程(即未执行 ENTRYPOINT 或 CMD),此时容器仅在 Docker daemon 中注册了元数据和资源配置,尚未真正运行。
Created状态的本质:隔离环境已就绪,但进程未启动
Docker 在调用 docker create(或 docker run --no-start)时,会完成以下关键动作:
- 解析镜像层,挂载只读 rootfs 并叠加可写层(如 overlay2 的 upperdir)
- 分配初始网络命名空间(默认为 none 模式,不配置网络接口)
- 设置 cgroups v1/v2 控制组路径(如
/sys/fs/cgroup/memory/docker/xxx),但此时限制值尚未生效(cgroup 资源限额仅在进程加入后才触发内核管控) - 生成容器 JSON 配置(
/var/lib/docker/containers/),记录挂载点、端口映射、环境变量等静态信息/config.v2.json - 创建容器工作目录(如
/var/lib/docker/containers/),但不启动任何用户进程/
该状态下,容器没有 PID 命名空间主进程(init 进程),ps aux | grep 查不到对应进程,docker top 返回空,docker exec 也无法执行——因为 exec 依赖正在运行的 PID namespace。
资源是否被实际占用?内存/CPU/磁盘/网络的真实情况
Created 容器几乎不消耗运行时资源,但存在少量静态开销:
- 内存:仅占用几 MB 主机内存,用于存储容器结构体、cgroup 目录节点、挂载信息等元数据;rootfs 层文件本身不额外加载到内存(页缓存按需触发)
- CPU:零占用;无调度实体,不参与 CPU 时间片分配
-
磁盘:占用镜像层 + 可写层的磁盘空间(即
docker system df中显示的 “Local Volumes” 和 “Images” 总和),但不会因 Created 状态而新增写入 -
网络:默认不创建 veth pair、不分配 IP;若指定了
--network container:xxx或自定义网络但未启动,则仅预留网络配置项,不实际连接
注意:使用 --memory、--cpus 等参数创建容器时,Docker 会在 cgroup 中预先写入限制值,但内核不会立即施加约束——只有当容器启动、首个进程加入该 cgroup 后,资源限制才真正生效。
为什么需要 Created 状态?典型使用场景
Created 是 Docker 实现“分离构建与运行”的关键中间态,支撑多种运维与编排需求:
-
批量预创建 + 按需启动:例如在 CI 流水线中先
docker create数十个测试容器,再根据用例并发docker start,避免启动时镜像拉取/解压延迟 -
配置校验与审计:创建后检查
docker inspect输出,确认挂载路径、权限、环境变量是否符合安全策略,再决定是否启动 -
离线环境部署:在无网络节点上提前
docker load镜像并create容器,待业务就绪后一键start -
调试与恢复:容器异常退出后保持 Created 状态(如
restart: never),便于inspect分析退出前配置,或修改hostconfig.json后重启
如何验证与管理 Created 容器
常用操作与判断依据:
- 查看所有 Created 容器:
docker ps -a --filter status=created - 检查资源关联:
docker inspect查配置值;| jq '.HostConfig.Memory, .HostConfig.CpuCount' cat /sys/fs/cgroup/memory/docker/查 cgroup 文件(存在即已写入,但未激活)/memory.limit_in_bytes - 启动容器:
docker start—— 此刻才 fork init 进程、挂载 proc/sys、加入 cgroup、触发网络配置 - 清理残留:
docker rm可直接删除 Created 容器,释放元数据和可写层目录(注意:若挂载了外部卷,卷数据不受影响)
Created 不是故障态,而是 Docker 显式暴露的可控中间状态,理解它有助于更精准地规划资源、排查启动问题,并适配自动化流程。










