Minikube无Git仓库跨服务配置DVC共享缓存及故障排查

两个核心配置逻辑错误导致拉取失败：

1. 混淆了DVC本地缓存与远程存储的角色：直接将DVC本地缓存目录挂载为共享卷的方式，完全跳过了DVC原生的版本元数据同步流程。dvc repro执行后生成的版本哈希映射、阶段输出关联信息都存在于test-service工作目录下的dvc.lock、各.dvc元数据文件中，inference-service无法获取这些元数据，自然会报缺失版本信息、无对应文件哈希的错误。
2. 缺失强制同步步骤：test-service日志提示执行dvc push不是冗余提示——DVC的pull/push工作流逻辑是先读取本地工作目录的元数据拿到目标文件哈希，再到配置的remote存储中匹配对应哈希的文件块，你既没有配置可被所有服务访问的共享remote，也没有做元数据的跨Pod同步，仅挂载缓存目录完全无法支撑pull操作。

不需要Git仓库，按以下步骤调整即可实现所有服务的模型、数据视图一致：

第一步：调整共享卷规划 #

提前在Minikube中创建可被所有相关Pod挂载读写的PersistentVolume，挂载到所有Pod的/dvc-remote路径，不要直接挂载DVC默认的本地缓存路径（.dvc/cache）。这个路径将作为DVC的本地共享远程存储，替代云存储类的远端仓库。

第二步：test-service 配置调整 #

test-service作为流水线执行端，按以下流程配置启动与周期任务逻辑：

1. 容器启动时先执行无Git模式的DVC初始化：dvc init --no-scm，该参数会关闭DVC对Git仓库的依赖，不需要挂载Git目录即可运行。
2. 配置共享本地路径为默认远程存储：dvc remote add -d shared-local /dvc-remote
3. 每次周期性执行dvc repro完成流水线运行后，依次执行两个操作：
   • 执行dvc push，将新生成的模型、数据对应的哈希文件块推送到/dvc-remote共享存储中
   • 将当前工作目录下的dvc.lock、所有.dvc后缀的元数据文件、dvc.yaml、params.yaml全量拷贝到共享存储的固定元数据目录/dvc-remote/metadata/下

注意：不要直接将test-service的整个工作目录挂载为共享卷，会导致流水线运行时的临时文件跨服务冲突，仅在push完成后同步元数据即可。拷贝元数据时建议先写入临时目录，再通过mv操作原子替换/dvc-remote/metadata/下的旧文件，避免inference-service读到半写的损坏元数据。

第三步：inference-service 配置调整 #

所有推理服务不需要执行流水线重跑，按以下流程配置拉取逻辑：

1. 容器启动时同样执行dvc init --no-scm完成无Git模式初始化
2. 配置和test-service完全一致的默认远程存储：dvc remote add -d shared-local /dvc-remote
3. 每次拉取最新模型、数据前，先将/dvc-remote/metadata/路径下的所有元数据文件全量拷贝到当前服务的DVC工作目录，覆盖本地旧的元数据
4. 再执行dvc pull -f，此时DVC可从本地元数据中读取到最新的文件哈希映射，直接从/dvc-remote共享存储拉取对应文件到本地models、data目录，不会再出现哈希缺失、拉取失败的问题。

• 所有Pod对/dvc-remote挂载路径需配置读写权限，避免push、pull操作因权限失败
• 保留每个Pod本地的.dvc/cache目录即可，不需要额外共享，本地缓存可减少重复拉取的IO开销
• 元数据同步不要做增量更新，每次全量覆盖即可，避免旧元数据残留导致版本不一致

内容的提问来源于stack exchange，提问作者LinkCoder