Sửa lỗi MountVolume.SetUp failed for volume: mount failed exit status 32 trong Kubernetes

TL;DR

Pod của bạn bị kẹt ở trạng thái ContainerCreating với thông báo sau trong events:

MountVolume.SetUp failed for volume "my-pv" : mount failed: exit status 32

Lỗi này thường xuất phát từ một trong ba nguyên nhân chính. Volume vẫn đang gắn vào một node đã chết hoặc đang terminate (Multi-Attach). Một tiện ích filesystem bị thiếu trên node — e2fsck, xfs_repair hoặc tương tự. Hoặc có một mount cũ còn sót lại từ Pod trước. Hãy kiểm tra node nào Pod cũ đã chạy trước, rồi xử lý từ đó.

Đọc toàn bộ thông báo lỗi trước khi làm gì

Chạy lệnh này ngay để xem chuỗi lỗi thực sự:

kubectl describe pod <pod-name> -n <namespace>

Cuộn xuống phần Events. Thông thường bạn sẽ thấy một trong các mẫu lỗi sau:

• Multi-Attach error for volume ... Volume is already exclusively attached to one node
• mount failed: exit status 32 — thiếu hoặc hỏng công cụ filesystem
• Unable to attach or mount volumes: unmounted volumes=[my-pv] — PVC vẫn đang gắn với node cũ
• Output: mount: /var/lib/kubelet/pods/.../mount: can't read superblock — volume bị hỏng

Mẫu lỗi bạn gặp sẽ quyết định cách xử lý.

Nguyên nhân 1: Multi-Attach — volume vẫn bị khóa bởi node khác

Một node bị crash hoặc bị cordoned. Pod cũ chưa terminate sạch. Bây giờ Pod mới được lên lịch trên node khác — nhưng AWS EBS hoặc GCE PD chỉ cho phép gắn một lần tại một thời điểm. Kubernetes sẽ không tự động tách volume cho đến khi chắc chắn node cũ đã biến mất.

# Kiểm tra node nào đang gắn PV
kubectl get pv <pv-name> -o jsonpath='{.spec.nodeAffinity}'

# Kiểm tra các đối tượng VolumeAttachment
kubectl get volumeattachment

# Tìm Pod cũ vẫn đang giữ claim
kubectl get pods --all-namespaces -o wide | grep <pvc-name>

Nếu Pod cũ bị kẹt ở trạng thái Terminating:

# Xóa buộc Pod bị kẹt — chỉ làm điều này nếu node đã được xác nhận là chết/đã thay thế
kubectl delete pod <pod-name> -n <namespace> --force --grace-period=0

Nếu bản thân VolumeAttachment bị mồ côi (node đã biến mất):

# Liệt kê các VolumeAttachment cũ
kubectl get volumeattachment

# Xóa VolumeAttachment mồ côi
kubectl delete volumeattachment <attachment-name>

Chờ 30–60 giây sau khi xóa. Pod mới sẽ bắt đầu mount.

Nguyên nhân 2: Thiếu tiện ích filesystem trên node

exit status 32 từ lệnh mount là kernel báo rằng nó không có những gì cần thiết. Module hoặc công cụ userspace cho filesystem chưa được cài đặt. Điều này thường xảy ra sau khi nâng cấp OS hoặc khi sử dụng node image tối giản — ví dụ, bản cài đặt Ubuntu 22.04 minimal mới không đi kèm xfsprogs mặc định.

# SSH vào node bị ảnh hưởng
ssh <node-ip>

# Kiểm tra filesystem mà PV sử dụng — lấy từ kubectl trước
kubectl get pv <pv-name> -o jsonpath='{.spec.csi.fsType}'

# Trên node, kiểm tra công cụ có tồn tại không
which mkfs.ext4
which mkfs.xfs
which mount.nfs  # cho các volume NFS

Cài đặt những gì còn thiếu:

# Debian/Ubuntu
apt-get install -y e2fsprogs xfsprogs nfs-common

# RHEL/CentOS/Amazon Linux
yum install -y e2fsprogs xfsprogs nfs-utils

Sau khi cài đặt, kubelet sẽ tự động thử lại. Nếu không khởi động trong vòng một phút, hãy xóa Pod để buộc thực hiện lại mount:

kubectl delete pod <pod-name> -n <namespace>

Nguyên nhân 3: Mount point cũ hoặc filesystem bị hỏng

Một lần mount thất bại trước đó có thể để lại một entry ma chặn các lần thử mới. Kiểm tra trực tiếp trên node:

# Tìm các mount còn sót lại cho volume
cat /proc/mounts | grep <pv-name>
# hoặc theo PVC UID
ls /var/lib/kubelet/pods/ | xargs -I{} ls /var/lib/kubelet/pods/{}/volumes/

Tìm thấy entry cũ? Dọn sạch nó:

# Unmount đường dẫn cũ
umount -l /var/lib/kubelet/pods/<pod-uid>/volumes/<plugin>/<pv-name>

# Sau đó khởi động lại kubelet để làm sạch trạng thái
systemctl restart kubelet

Filesystem ext4 hoặc xfs bị hỏng? Tháo gắn volume khỏi node trước qua cloud console, sau đó chạy công cụ sửa chữa phù hợp:

# Cho ext4
e2fsck -f /dev/<device>

# Cho xfs
xfs_repair /dev/<device>

Nguyên nhân 4: Sai access mode của PVC

Chạy nhiều Pod replica với volume ReadWriteOnce (RWO) trên các node khác nhau? Điều đó sẽ không hoạt động. RWO có nghĩa là chỉ một node, không có ngoại lệ.

kubectl get pvc <pvc-name> -o jsonpath='{.spec.accessModes}'

Các tùy chọn của bạn:

• Chuyển sang storage class hỗ trợ ReadWriteMany — NFS, AWS EFS và CephFS đều xử lý được điều này
• Ghim tất cả Pod chia sẻ PVC về cùng một node bằng nodeSelector hoặc podAffinity
• Nếu RWX không khả dụng, giảm xuống replicas: 1 trong Deployment

Nguyên nhân 5: CSI driver không chạy trên node đích

# Kiểm tra CSI node plugin có hoạt động bình thường trên node bị ảnh hưởng không
kubectl get pods -n kube-system -o wide | grep csi

# Xem logs từ CSI node DaemonSet pod trên node đó
kubectl logs -n kube-system <csi-node-pod> -c <csi-driver-container>

Nếu CSI pod đang ở trạng thái CrashLoopBackOff hoặc đơn giản là không có trên node đó, mọi thứ khác đều vô nghĩa — volume không thể mount cho đến khi driver hoạt động bình thường. Hãy sửa vấn đề CSI trước, rồi quay lại xử lý Pod.

Kiểm tra kết quả

# Xem Pod events theo thời gian thực
kubectl get events -n <namespace> --watch --field-selector involvedObject.name=<pod-name>

# Xác nhận Pod chuyển sang trạng thái Running
kubectl get pod <pod-name> -n <namespace> -w

# Xác minh volume đã được mount bên trong container
kubectl exec -it <pod-name> -n <namespace> -- df -h
kubectl exec -it <pod-name> -n <namespace> -- ls <mount-path>

Pod đạt trạng thái Running và df -h hiển thị volume tại đường dẫn mong đợi? Vấn đề mount đã được giải quyết.

Phòng ngừa

• Đặt terminationGracePeriodSeconds đủ cao để Pod có thể giải phóng volume sạch — 60–120 giây là mức cơ sở hợp lý cho các workload database
• Thêm PodDisruptionBudgets để kiểm soát hành vi rolling và ngăn chặn race condition tách gắn trong quá trình node drains
• Sử dụng StatefulSet cho các workload stateful trên block storage — nó quản lý vòng đời volume đáng tin cậy hơn nhiều so với Deployment
• Giữ CSI driver luôn được cập nhật; các bản phát hành driver thường bao gồm các bản sửa lỗi về độ tin cậy khi mount