Go应用部署前必须确认三件事：是否需写本地文件、是否依赖有状态组件（须绑定PVC）、是否实现优雅关闭（监听SIGTERM并等待连接完成）。
Go应用部署前必须确认的三件事
直接用 kubectl apply -f deployment.yaml 部署 Go 服务却没配存储，等于把数据库跑在 emptyDir 上——Pod 一重建，数据全丢。部署前务必确认：
• Go 服务是否需要写本地文件（如上传临时目录、日志归档、缓存）
• 是否依赖有状态组件（PostgreSQL、Redis、MinIO 等），这些必须绑定 PVC
• 应用是否已实现优雅关闭：监听 SIGTERM，关闭 HTTP server 并等待活跃连接完成
为什么不能直接在 Deployment 里写 hostPath 或 emptyDir
hostPath 看似简单，但实际是反模式：
• 只能在单节点调度，破坏 Kubernetes 的弹性调度能力
• 节点故障时 Pod 迁移后无法访问原路径，PVC 处于 Pending 状态
• 多副本场景下各 Pod 写入不同节点路径，根本不是“共享存储”
而 emptyDir 生命周期完全绑定 Pod，重启即清空，连日志都留不住。
真正可落地的方案只有两种：动态供应（推荐）或静态 NFS PV（适合小集群）。
用 StorageClass 实现 PVC 动态创建（最简可行版）
不用手动建 PV，让 Kubernetes 自动按需分配存储。前提是集群已部署支持动态供应的 Provisioner（如 nfs-client-provisioner 或云厂商插件）。验证是否存在可用 StorageClass：kubectl get storageclass
若输出为空，需先部署 Provisioner（参考官方 helm install nfs-subdir-external-provisioner）。
然后定义 PVC，关键点：
• storageClassName 必须与 get storageclass 输出的名称一致（如 nfs-client）
• accessModes 按需选：ReadWriteOnce（单节点读写，数据库首选）、ReadWriteMany（多节点读写，文件共享场景）
• 不要写 volumeName —— 动态模式下该字段会阻断自动绑定
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: go-app-data
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 2Gi
storageClassName: nfs-client在 Go 应用的 Deployment 中挂载：
• 使用 volumeMounts 指向容器内路径（如 /data）
• volumes 下用 persistentVolumeClaim 引用上面的 PVC 名称
• 不要漏掉 subPath（如需复用 PVC 给多个目录）
Go 代码里怎么安全使用挂载路径
别硬编码 /data/uploads，运行时检查路径可写性并设默认 fallback：
• 启动时用 os.Stat() + os.IsNotExist() 判断挂载点是否存在
• 用 os.MkdirAll(path, 0755) 初始化子目录，避免因权限问题启动失败
• 日志写入不要直写根路径，例如：os.OpenFile("/data/logs/app.log", os.O_CREATE|os.O_APPEND|os.O_WRONLY, 0644)
• 若用 SQLite 或 BadgerDB，确保数据库文件路径落在 PVC 挂载点内（如 /data/db/），否则仍会写进容器层被丢弃
最容易被忽略的一点：
• PVC 绑定是异步的，Pod 启动时卷可能尚未就绪 → 在 Go main() 中加 5 秒重试逻辑，或用 initContainers 显式等待：command: ["sh", "-c", "until ls /mnt/data; do sleep 2; done"]
