K8S持久化存储挂载逻辑

以 MySQL 为例实现 K8S 容器的持久化挂载

步骤如下：

第一步定义物理底座：PersistentVolume (PV)

apiVersion: v1
kind: PersistentVolume
metadata:
  name: my-local-pv
spec:
  storageClassName: manual	# 存储分类名称
  capacity:					# 资源容量
    storage: 1Gi
  accessModes:  			# 声明底层存储具体支持哪些读写模式。
    - ReadWriteOnce
  hostPath:					# 宿主机上的物理路径
    path: "/mnt/host/f/Projects/Go/gin_learning/mysql-live"

第二步提交存储申请：PersistentVolumeClaim (PVC)

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: webook-mysql-live-claim
spec:
  storageClassName: manual		# PV 的存储分类名称
  accessModes:  				# 声明需要的读写模式
    # 一个读写
    - ReadWriteOnce
  resources:
    requests:					# 请求的容量
      storage: 1Gi

第三步在 Pod 中引用存储：Volumes

volumes:
  - name: mysql-storage
    persistentVolumeClaim:
      claimName: webook-mysql-live-claim # 指向上面定义的 PVC 名字

第四步最终挂载进容器：VolumeMounts

1
2
3

volumeMounts:
  - mountPath: /var/lib/mysql # 容器内部路径
    name: mysql-storage       # 对应上面 volumes 定义的名字

当 MySQL 往容器里的 /var/lib/mysql 写数据时，这些数据会通过 PVC 和 PV，直接写到你宿主机的 /mnt/host/f/.../mysql-live 目录中

注意：

权限问题：由于使用的是 hostPath，要确保宿主机的 /mnt/host/f/.../mysql-live 目录具有可读写权限，否则 MySQL 容器启动时可能会因为无法初始化数据文件而报错（CrashLoopBackOff）。
Node 限制：hostPath 意味着 Pod 如果漂移到其他节点（Node），数据就找不到了。在单机开发环境（如 Docker Desktop 或 Minikube）中这没问题，但在多节点集群中，通常会使用云存储（如 AWS EBS, NFS 等）。