Я обнаружил осиротевшую капсулу в моем кластере kubernetes на одном узле. Когда я пытаюсь очистить его, я вижу следующее поведение:
# rm -rf /var/lib/kubelet/pods/a1fce4c0-2f64-11e9-9880-005056aed74b/
rm: cannot remove ‘/var/lib/kubelet/pods/a1fce4c0-2f64-11e9-9880-
005056aed74b/volumes/kubernetes.io~fc/harbor-jobservice-pv’: Device or resource busy
Пытаясь проверить, что его использует, я ничего не получаю:
# lsof +D /var/lib/kubelet/pods/a1fce4c0-2f64-11e9-9880-005056aed74b/volumes/kubernetes.io~fc/harbor-jobservice-pv
#
Проверяя точки монтирования я ничего не получаю:
# mount | grep -i a1fce4c0
# cat /proc/mounts | grep -i a1fce4c0
#
Папка не является символической ссылкой, ls -a
показывает, что она пуста. Я проверял теорию, что это крепление создано kubelet, но после его остановки я так и не смог его почистить. Он также не является док-томом (проверяя тома из docker volume inspect <volume>
.
Перезагрузка узла - это не то, что я ищу - я хотел бы понять проблему, а не просто обойти ее.
Заранее спасибо.
РЕДАКТИРОВАТЬ: постоянный том в области действия этого осиротевшего модуля теперь связан с новым модулем:
# kubectl get pv harbor-jobservice-pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS
CLAIM STORAGECLASS REASON AGE
harbor-jobservice-pv 5Gi RWO Retain Bound
harbor/harbor-jobservice-pvc
Эта пара PV / PVC используется
# kubectl get pod -n harbor harbor-harbor-jobservice-6b9c8598c8-x5l64 -o
yaml
...
metadata:
uid: bb60bfdd-4c8e-11e9-8b8e-005056aea3a7
...
spec:
volumes:
- name: job-logs
persistentVolumeClaim:
claimName: harbor-jobservice-pvc
...
Итак, вы можете видеть, что модуль, использующий этот PV, отличается от модуля, в папке которого у меня есть папка для хранения.