Наша установка представляет собой трехузловой кластер Kubernetes RHEL 7.3 без операционной системы, работающий на Docker.
У нас есть многопутевое блочное устройство FC SAN, обнаруженное на всех трех узлах. Это устройство используется как постоянный том Kubernetes с файловой системой ext4. Определение этого объекта следующее:
apiVersion: v1
kind: PersistentVolume
metadata:
annotations:
pv.kubernetes.io/bound-by-controller: "yes"
creationTimestamp: 2019-01-04T13:49:42Z
finalizers:
- kubernetes.io/pv-protection
labels:
...
spec:
accessModes:
- ReadWriteMany
capacity:
storage: 15Gi
claimRef:
apiVersion: v1
kind: PersistentVolumeClaim
name: ...
namespace: ...
resourceVersion: ...
uid: ...
fc:
fsType: ext4
lun: 1
targetWWNs:
- ...04
- ...15
persistentVolumeReclaimPolicy: Retain
status:
phase: Bound
Под, использующий этот том, произошел сбой, и после перезапуска он начал жаловаться на несогласованность и запрашивать запуск fsck.
Warning FailedMount 1m (x13 over 26m) kubelet, node2 MountVolume.WaitForAttach failed for volume "rtbm-prod-influxdb-pv" : fc: failed to mount fc volume /dev/dm-9 [ext4] to /var/lib/kubelet/plugins/kubernetes.io/fc/500
60e801232d404-lun-1, error 'fsck' found errors on device /dev/dm-9 but could not correct them: fsck from util-linux 2.23.2
k8s-san-0 contains a file system with errors, check forced.
k8s-san-0: Entry '675' in /data/_internal/monitor (262147) has an incorrect filetype (was 2, should be 1).
k8s-san-0: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
Однако мы не смогли запустить fsck. Мы отключили модуль, и fsck все еще жаловался на
# fsck.ext4 /dev/mapper/mpathb
e2fsck 1.42.9 (28-Dec-2013)
/dev/mapper/mpathb is in use.
e2fsck: Cannot continue, aborting.
Я попытался посмотреть, что именно использовало устройство:
# mount -l | grep -i mpathb
# lsof /dev/mapper/mpathb
# grep mpathb /proc/mounts
# fuser -m /dev/mapper/mpathb
Но для всех этих инструментов использование было незаметным. Что еще я мог проверить, чтобы узнать, что удерживает мое блочное устройство?