Kubernetes部署FireFly III时MySQL Pod出现CrashLoopBackOff权限问题

从你的Pod日志里的关键错误信息 /usr/sbin/mysqld: Can't change dir to '/var/lib/mysql/' (Errcode: 13 - Permission denied)，可以直接定位问题：NFS挂载的存储卷权限和MySQL容器内运行的用户不匹配。

MySQL 5.6容器默认使用mysql用户（UID=27，GID=27）启动，但NFS共享目录的权限大概率是宿主节点的root或其他用户，导致容器内的mysql用户没有读写目录的权限。下面是具体的解决方向：

方法1：修改NFS服务器端的目录权限 #

这是最直接的解决方案，直接让NFS目录权限匹配MySQL容器的用户：

• 登录你的NFS服务器，找到对应PV指向的共享目录
• 执行命令修改目录的属主和权限：

  # 把目录权限设置为MySQL容器的mysql用户（UID=27，GID=27）
  chown -R 27:27 /path/to/your/nfs/mysql/directory
  # 确保目录有足够的读写执行权限
  chmod -R 755 /path/to/your/nfs/mysql/directory
  

• 之后删除当前故障Pod，让Deployment重建：

  kubectl delete pod firefly-iii-mysql-67bfb68cf9-6gm9l
  

方法2：在Kubernetes Deployment中配置安全上下文 #

如果无法修改NFS服务器的权限，可以通过Kubernetes的安全上下文自动调整挂载卷的权限：
修改你的MySQL Deployment YAML，在spec.template.spec下添加securityContext配置：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: firefly-iii-mysql
  labels:
    app: firefly-iii
spec:
  selector:
    matchLabels:
      app: firefly-iii
      tier: mysql
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: firefly-iii
        tier: mysql
    spec:
      # 添加这部分安全上下文配置
      securityContext:
        fsGroup: 27 # 对应MySQL容器内的mysql用户组GID
      containers:
      - image: mysql:5.6
        name: mysql
        env:
        - name: MYSQL_ROOT_PASSWORD
          valueFrom:
            secretKeyRef:
              name: firefly-iii-secrets
              key: db_password
        ports:
        - containerPort: 3306
          name: mysql
        volumeMounts:
        - name: mysql-persistent-storage
          mountPath: /var/lib/mysql
      volumes:
      - name: mysql-persistent-storage
        persistentVolumeClaim:
          claimName: mysql-pv-claim

应用修改后的配置：

kubectl apply -f your-mysql-deployment.yaml

fsGroup会让Kubernetes在挂载卷时自动将目录的组权限设置为27，确保容器内的mysql用户能正常读写。

验证修复效果 #

等Pod重建完成后，检查状态：

kubectl get pods | grep mysql

如果Pod进入Running状态，再查看日志确认初始化成功：

kubectl logs firefly-iii-mysql-xxxx-xxxx

补充说明 #

你提到FireFly III主Pod能正常运行，应该是主Pod使用的运行用户UID和NFS目录权限匹配，而MySQL的用户UID不同，才出现了差异。

内容的提问来源于stack exchange，提问作者Boudewijn Swen