Deployment必须显式声明volumeMounts和volumes，否则Pod会卡在ContainerCreating状态；volumeMounts.mountPath须为绝对路径且与volumes.name严格一致；hostPath仅适用于单节点调试，生产环境应优先使用PV/PVC组合实现真正持久化。
Deployment必须显式声明volumeMounts和volumes
Go应用本身不自动挂载存储，Kubernetes也不会“猜”你要存什么。哪怕只是想把日志写到磁盘、或加载一个配置文件，都得在deployment.yaml里手动配volumeMounts（容器内路径）和volumes（底层存储定义）。
常见错误是只写了volumeMounts但漏掉volumes，导致Pod卡在ContainerCreating状态，kubectl describe pod会报错：MountVolume.SetUp failed for volume "xxx": couldn't propagate mount to host。
-
volumeMounts.mountPath必须是容器内绝对路径，比如/data/logs，不能是相对路径 -
volumes.name必须和volumeMounts.name严格一致（大小写敏感） - 如果用
hostPath，path指向的是宿主机路径，不同节点内容不共享，仅适合单节点调试或临时数据 - 生产环境避免
hostPath，优先用PersistentVolumeClaim（PVC），由集群管理员统一管理存储后端
ConfigMap/Secret不能当持久化存储用
很多人误以为把配置文件塞进ConfigMap再挂载到容器里，就算“持久化”了——不是。ConfigMap和Secret本质是只读的键值对，挂载后修改内容不会同步回源，且删除Pod后挂载点数据就没了。它们解决的是配置分发问题，不是数据留存问题。
真正需要持久化（比如用户上传文件、数据库本地存储、缓存目录），必须用PersistentVolume（PV）+ PersistentVolumeClaim（PVC）组合：
立即学习“go语言免费学习笔记（深入）”；
- Go服务代码里要确保写入路径（如
/data/uploads）与volumeMounts.mountPath一致 - PVC的
accessModes需匹配实际需求：ReadWriteOnce（单节点读写）、ReadWriteMany（多节点并发读写，需支持该模式的存储后端如NFS、CephFS） - 若Go服务启用了多副本（
replicas: 3），又用了ReadWriteOncePVC，则只有1个Pod能成功挂载，其余会Pending——这是最常踩的坑
EmptyDir适合临时共享，但重启即丢
同一个Pod里的多个容器（比如Go主程序 + 日志收集sidecar）需要共享临时数据时，emptyDir是最轻量的选择。它不依赖外部存储，生命周期绑定Pod：Pod删，emptyDir立刻清空。
注意两个关键点：
- Go服务若把关键状态（如session缓存、未提交事务日志）写进
emptyDir，Pod被驱逐或崩溃重启后数据全丢 - 设置
emptyDir.medium: Memory可提升I/O性能，但占用的是容器内存限额，且节点重启后tmpfs内容消失 - 不要给
emptyDir设sizeLimit后还让Go程序无节制写入，超出限制会导致Pod被OOMKilled
Go代码里必须适配挂载路径的权限和存在性
Kubernetes挂载卷后，容器内路径的属主、权限、目录结构不一定符合Go程序预期。尤其用alpine镜像+非root用户运行时，容易因权限不足失败。
实操建议：
- 启动时检查挂载路径是否存在且可写：
os.Stat("/data")+os.IsPermission(err) - Dockerfile里提前
RUN mkdir -p /data && chown nobody:nogroup /data，再用USER nobody - 如果挂载的是
hostPath，宿主机目录权限需对容器UID开放（比如nobodyUID是65534，宿主机目录chown 65534:65534 /data） - 避免在
initContainers里用touch或mkdir硬创建文件——PVC可能还没绑定完成，initContainer会失败重试
挂载不是“配完就完事”，Go服务得主动适配。最隐蔽的问题往往出在路径权限和初始化时机上，而不是YAML语法。
