企业官网建设流程全解析

• 云原生
• 开发工具
• DevOps
• 容器编排

DevSpace 的devspace cleanup命令组负责回收开发过程中积累的冗余资源，本篇以官方命令文档devspace cleanup为骨架，结合当前仓库的源码实现，完整讲解devspace cleanup images与devspace cleanup local-registry两个子命令的作用、执行流程、相关的全局标志，以及它们背后对 Docker API 和 Kubernetes 资源的调用链，帮助你在反复构建镜像、使用本地镜像仓库后安全地清理本地 Docker 守护进程和集群中的残留物。

命令总览：devspace cleanup 是什么

devspace cleanup用于"清理资源"（Cleans up resources），它本身是一个父命令，不接收位置参数，也不直接执行删除动作。真正的清理逻辑由子命令承担。从命令注册源码 NewCleanupCmd 可以看到其结构：

// cmd/cleanup/cleanup.go cleanupCmd := &cobra.Command{ Use: "cleanup", Short: "Cleans up resources", Args: cobra.NoArgs, } cleanupCmd.AddCommand(newImagesCmd(f, globalFlags)) // devspace cleanup images cleanupCmd.AddCommand(newLocalRegistryCmd(f, globalFlags)) // devspace cleanup local-registry // 允许插件注册 "cleanup" 分组下的扩展子命令 plugin.AddPluginCommands(cleanupCmd, plugins, "cleanup")

也就是说，devspace cleanup提供两个内置子命令：

• devspace cleanup images—— 删除本地 Docker 中由 DevSpace 构建的镜像，并顺带清理 dangling（悬空）镜像；
• devspace cleanup local-registry—— 删除 DevSpace 部署到集群中的本地镜像仓库（Local Registry）。

同时该命令组还通过plugin.AddPluginCommands(cleanupCmd, plugins, "cleanup")预留了插件扩展点：已安装的 DevSpace 插件可以注册名为cleanup xxx的子命令（可用devspace list plugins查看已注册的插件命令）。

全局与继承标志（Global & Inherited Flags）

devspace cleanup及其子命令继承了 DevSpace 的全部全局标志。以下按官方命令文档（devspace cleanup --help）完整列出，这些标志对两个子命令同样生效：

对清理命令而言，最常用的通常是-n/--namespace、--kube-context（决定去哪个命名空间查找本地 registry）和--config（指定配置文件位置）。

devspace cleanup images：清理本地 Docker 镜像

适用场景

如果你经常通过devspace build构建镜像，本地 Docker 守护进程里可能已经堆满了大量带不同 tag 的镜像（例如带${devspace.git.commit}、random-####这类 schema 标签）。devspace cleanup images会删除devspace.yaml中images配置段声明的所有镜像，再清理所有 dangling 镜像。

执行流程（源码级解读）

核心逻辑位于 RunCleanupImages，完整调用链如下：

1. 定位项目：通过configLoader.SetDevSpaceRoot(log)找到devspace.yaml所在的项目根目录；如果找不到配置，直接返回message.ConfigNotFound错误——因此该命令必须在包含devspace.yaml的项目目录下运行；
2. 创建客户端：先根据--kube-context/-n创建 kube 客户端，再通过 docker.NewClientWithMinikube 创建 Docker 客户端，且preferMinikube=true——即如果当前集群是 minikube，会优先把构建/删除操作落到 minikube 虚拟机内的 Docker 守护进程，失败时回退到本机环境；
3. 加载配置：configLoader.Load(...)解析并合并出最终配置。若len(config.Images) == 0，直接输出No images found in config to delete并结束；
4. 连通性检查：client.Ping(ctx)失败时报错Docker seems to be not running: ...，即要求本地（或 minikube 内的）Docker 守护进程处于运行状态；
5. 逐镜像删除：遍历config.Images，对每个imageConfig.Image（镜像仓库与名称）调用 DeleteImageByName。

底层删除的实现值得注意，见 DeleteImageByFilter：

// pkg/devspace/docker/images.go func (c *client) DeleteImageByFilter(ctx context.Context, filter filters.Args, log log.Logger) ([]image.DeleteResponse, error) { summaries, err := c.ImageList(ctx, image.ListOptions{Filters: filter}) // ... for _, summary := range summaries { deleteResponse, err := c.ImageRemove(ctx, summary.ID, image.RemoveOptions{ PruneChildren: true, // 级联清理因删除该镜像而失效的子层/子镜像 Force: true, // 强制删除，即使有容器依赖 }) // ... } }

即先按reference过滤出镜像，再逐个ImageRemove，并且带Force与PruneChildren选项，保证构建产生的中间层也会被连带回收。日志中会区分输出Deleted xxx（真正删除）与Untagged xxx（仅移除 tag）。

6. 循环清理 dangling 镜像：

// cmd/cleanup/images.go L111-L128 for { response, err := client.DeleteImageByFilter(ctx, filters.NewArgs(filters.Arg("dangling", "true")), log) // ... if len(response) == 0 { break } }

命令以dangling=true过滤反复删除悬空镜像，直到一轮没有任何可删项为止，最终输出Successfully cleaned up images。

用法示例

# 在包含 devspace.yaml 的项目目录下 devspace cleanup images # 指定配置文件 devspace cleanup images --config ./devspace.dev.yaml # 若镜像构建在 minikube 的 docker 中，会优先清理 minikube 内的镜像 devspace cleanup images --kube-context minikube

对应的镜像声明来自devspace.yaml的images段（详见 images 配置参考）：

images: backend: image: ghcr.io/org/project/image # cleanup images 会删除该镜像在本地的副本 tags: - latest - dev-${devspace.git.commit} dockerfile: ./Dockerfile

devspace cleanup local-registry：删除集群中的本地镜像仓库

背景：Local Registry 是什么

当本地环境没有目标镜像仓库的推送权限时，DevSpace 的降级策略是：如果目标是 KinD 集群，则用kind load docker-image直接载入；其他集群则由 DevSpace 在集群内部署一个本地镜像仓库（Local Registry），并把项目里的所有镜像地址透明改写为localhost:[NODE_PORT]/...（不修改磁盘上的devspace.yaml）。更多细节可参考 Local Registry 配置文档。

这个本地 registry 默认以registry:2.8.1镜像、emptyDir卷 +Deployment的方式部署（启用persistence时改为StatefulSet+ 持久卷）。当你要卸载它（例如切换到有真实仓库权限的环境、或回收集群存储）时，就使用devspace cleanup local-registry。

相关默认值定义在 localregistry 包的 Options：

// pkg/devspace/build/localregistry/options.go RegistryName = "registry" // 资源默认名称 RegistryImage = "registry:2.8.1" BuildKitImage = "moby/buildkit:master-rootless" RegistryPort = 5000 RegistryDefaultStorage = "5Gi" // persistence 默认卷大小

devspace.yaml中可通过localRegistry段覆盖这些默认值：

localRegistry: name: registry # 资源名（默认 registry） namespace: [KUBE CONTEXT NAMESPACE] # 部署命名空间 localbuild: false # true 时使用本地 docker/podman 构建再推送 image: registry:2.8.1 # registry 镜像 port: 5000 # 容器端口 persistence: enabled: true # true 时改为 StatefulSet + PVC size: 10Gi storageClassName: "" # 为空则用集群默认 StorageClass

执行流程（源码级解读）

核心逻辑位于 RunCleanupLocalRegistry，流程比cleanup images多了一层"破坏性操作确认"：

1. 定位项目并加载配置：同样要求存在devspace.yaml，否则报ConfigNotFound；同时通过LoadLocalCache()读取本地缓存，用kubectl.CheckKubeContext校验当前 kube-context / namespace 是否与上次部署一致（可用--no-warn关闭警告、-s/--switch-context自动切回上次上下文）；

2. 探测 registry 资源是否存在：结合config.LocalRegistry与 NewDefaultOptions 得到资源名与命名空间，然后分别Get该命名空间下同名的StatefulSet、Deployment和Service（见 local_registry.go L97-L130）：

   • 三者都不存在时，输出No local registry found.并安全退出；
   • 任一存在则继续下一步；

3. 交互确认：由于删除 registry 会连同其中所有镜像一起消失，命令会弹出确认问题：

   This will delete your local registry and all the images it contains. Do you wish to continue? (Yes / No)

   选择No直接取消，不产生任何删除动作；

4. 按存在情况删除：分别删除检测到的StatefulSet、Deployment、Service，对IsNotFound错误做幂等容错（并发或重复执行不会报错），最终输出Successfully cleaned up local registry。

用法示例

# 删除默认命名空间中的本地 registry devspace cleanup local-registry # 明确指定 registry 所在命名空间与 context devspace cleanup local-registry -n dev --kube-context my-cluster # 使用特定配置 devspace cleanup local-registry --config devspace.yaml

与其他清理类命令的关系

devspace cleanup专注于"镜像与本地 registry"两类资源。DevSpace 文档的 Cleanup 指南 还介绍了其他几类互补的清理手段，可与之搭配使用：

实践注意事项

• 两个子命令都要求项目目录下存在devspace.yaml，否则返回ConfigNotFound；--config可用于显式指定配置文件。
• devspace cleanup images只删除images配置段声明的镜像名以及 dangling 镜像，不会误删项目中未声明的其他本地镜像；它要求 Docker 守护进程可达（minikube 场景优先使用 VM 内的 Docker），否则会报Docker seems to be not running。
• devspace cleanup local-registry是破坏性操作：会删除 registry 内的全部镜像，且命令内置了交互式确认；它只会删除名为localRegistry.name（默认registry）的 StatefulSet/Deployment/Service，不影响集群中其他资源。
• 命名空间一致性很关键：registry 部署在哪个 namespace，清理时就需要用-n/--namespace（或--switch-context切回）指向同一命名空间，否则可能探测不到资源。若确认目标无误，可加--no-warn跳过上下文切换警告。
• 子命令帮助文本可分别在 devspace_cleanup_images.md 与 devspace_cleanup_local-registry.md 中查阅；父命令帮助见 devspace_cleanup.md。

• 云原生
• 开发工具
• DevOps
• 容器编排