K3s 使用 hostPath 卷的 pod 重启后数据丢失或权限不对

4次阅读

K3s 中 hostPath 卷数据“丢失”或权限异常，主因是宿主机路径未预创建、UID/GID 不匹配、挂载于临时目录被清理，或多个 Pod 共享同一 hostPath 导致冲突；应手动创建并设置正确权限与属主，避免临时路径，单实例场景下锁定节点调度。

K3s 中使用 hostPath 卷的 Pod 重启后数据“丢失”或权限异常，通常不是数据真被删了，而是挂载路径未就绪、权限不匹配、或 K3s 节点重启导致宿主机目录状态变化所致。核心问题在于 hostPath 完全依赖宿主机文件系统状态，而 K3s（尤其单节点轻量部署）默认不保证该路径的自动创建与属主初始化。

宿主机路径未提前创建或属主错误

hostPath 不会自动创建父目录，也不会修改已有目录的权限和属主。若 Pod 启动时路径不存在，Kubernetes 会创建一个空目录，但属主为 root:root，且 umask 可能导致非 root 容器进程无写权限。

手动创建挂载路径，并设为容器内进程所需的 UID/GID（例如 MySQL 常用 999，Nginx 常用 101）：
sudo mkdir -p /var/lib/myapp/data
sudo chown 999:999 /var/lib/myapp/data
sudo chmod 755 /var/lib/myapp/data
避免使用 type: DirectoryOrCreate —— 它只建目录，不设权限；优先用 Directory 并确保路径已预置。

Pod 重启时容器用户与宿主目录 UID 不一致

容器镜像中应用常以非 root 用户运行（如 USER 999），但宿主机目录若属主是 root 或其他 UID，就会因 Linux 文件权限机制拒绝写入，表现为“数据没保存”或日志报 Permission denied。

查清容器内实际运行 UID：
kubectl exec -- id -u
在 securityContext 中显式指定 runAsUser，并与宿主目录属主对齐：
```
securityContext:
  runAsUser: 999
  fsGroup: 999
```
（fsGroup 确保挂载卷内文件组权限自动适配）

K3s 节点重启后 hostPath 路径被清理或变更

K3s 默认将数据存于 /var/lib/rancher/k3s，但用户自定义的 hostPath 若放在 /tmp、/run 或某些 systemd-tmpfiles 清理路径下，节点重启后目录会被清空，造成“ 数据丢失 ”假象。

严格避免将 hostPath 指向临时目录（/tmp、/var/run、/dev/shm 等）。
推荐路径：固定位置如 /opt/myapp/data、/srv/myapp 或 /var/lib/myapp，并确保该路径不在任何自动清理策略范围内。
检查是否被 systemd-tmpfiles 清理：
systemd-tmpfiles --dry-run --verbose | grep "/tmp|/run"

多副本 Pod 共享同一 hostPath 的风险

若多个 Pod 副本（尤其带 replicas > 1）挂载同一个 hostPath，它们会同时读写同一目录，极易引发数据损坏、覆盖或锁冲突——这不是 K3s 特有，而是 hostPath 的设计限制。

不要在 Deployment 中对有状态服务使用共享 hostPath；应改用 StatefulSet + local PersistentVolume 或外部存储（如 NFS、Longhorn）。
仅当明确是单实例、且无需高可用时，才用 hostPath；此时建议配合 nodeSelector 锁定到特定节点，防止调度漂移。

发表于：互联网运维

近一天内