IT_Octopus的博客

ConfigMap 的 key 通过items.path改名 → 进入 Volume → 被subPath选中 → 贴到mountPath指定的完整路径 → Spring Boot 按路径读取。每一步都是独立映射，不存在隐那些事儿！

*就像你用购物清单（PVC）去领取一个实物（PV），而商店（StorageClass）可以在库存（现有 PV）不足时，根据你的清单去仓库紧急调货或生产（动态创建 PV）。3.动态创建 PV: 长久存在的 longhorn-static StorageClass (由 driver.longhorn.io 驱动) 监听到这些 PVC 的请求，并根据它们的容量和要求，动态创建了相应的 PV。PVC 又通过指定的 StorageClass，触发了 PV 的动态创建和最终的绑定。这是一个完整的、自动化的流程。

实际的场景：harbor 主备双战，每次拉取的时候拉到备战导致镜像拉取失败，最终排查是因为镜像包太大了，主站在往备战同步的时候失败或者太慢，导致K8s 拉不到镜像。运维建议缩减镜像的大小。： .venv 中的 Lib （准确说是 site-packages ）是混合体，但核心涉及系统兼容性的部分是“动态链接库”。Docker 构建时，会按顺序执行每个 FROM 开始的“独立小世界”，最后只保留最后一个 FROM 的结果作为最终镜像。你想做一个干净漂亮的蛋糕（最终镜像），但做蛋糕需要厨房（Builder）。

分析下来是因为buuferSize 设置的是500条数据，但是迁移工具对一次迁移的数据是是有大小限制的，如果500条数据的总大小大于4194304，就会导致数据迁移失败。注意：这个在2.3.x 迁移到2.4.5 的时候没有出现这个问题，问题出现在2.4.5迁移到2.4.13-hotfix的时候出现的。问题是数据在批量迁移的过程中，这个错误会被忽略掉。解决方案：bufferSize 修改的条数少一点。在迁移数据的时候发现数据丢失。

出现的错误：最终命令顺序调序：docker run -it -v D:\a_docker\pip_source:/data/pip_source --name=piptest centos:7eg；控制docker的命令执行顺序！！！其次：高版本的docker desktop没有所谓的sharing功能，不要试图在里面找挂载的磁盘，网上都是这个回答，被坑的不清...