Динамический персистентный том Kubernetes Azure. Утверждение тома: Сбой монтирования по истечении времени ожидания. Pod находится в статусе "ContainerCreating" навсегда
Постановка задачи:
Заявка на динамический постоянный том диска Azure. Сбой монтирования по истечении времени ожидания Pod находится в состоянии "ContainerCreating" навсегда.
kubectl describe pod myPod
дает следующую информацию:
Warning FailedMount 1m (x5 over 12m) kubelet, k8-node-2 Unable to mount volumes for pod "mongodb-76bd56459f-hxjdc_kubeapps(8189f2e4-0017-11e8-82ac-000d3aa33484)": timeout expired waiting for volumes to attach/mount for pod "kubeapps"/"mongodb-76bd56459f-hxjdc". list of unattached/unmounted volumes=[data]
Warning FailedMount 21s (x8 over 12m) kubelet, k8-node-2 (combined from similar events): MountVolume.SetUp failed for volume "pvc-516aeece-ff9d-11e7-82ac-000d3aa33484" : mount failed: exit status 32
Mounting command: systemd-run
Mounting arguments: --description=Kubernetes transient mount for /var/lib/kubelet/pods/8189f2e4-0017-11e8-82ac-000d3aa33484/volumes/kubernetes.io~azure-disk/pvc-516aeece-ff9d-11e7-82ac-000d3aa33484 --scope -- mount -t ext4 -o bind /var/lib/kubelet/plugins/kubernetes.io/azure-disk/mounts/m3083936425 /var/lib/kubelet/pods/8189f2e4-0017-11e8-82ac-000d3aa33484/volumes/kubernetes.io~azure-disk/pvc-516aeece-ff9d-11e7-82ac-000d3aa33484<br> Output: Running scope as unit run-rf9126bab6fba44d9a499370260ed5fe8.scope. mount: special device /var/lib/kubelet/plugins/kubernetes.io/azure-disk/mounts/m3083936425 does not exist
Информация о кластере Kubernetes:
Это голая металлическая установка с одним мастером и двумя миньонами. Все три виртуальные машины Ubuntu 16.04 LTS находятся на Azure. Кластер создается с помощью "kubeadm".
Client Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.1", GitCommit:"3a1c9449a956b6026f075fa3134ff92f7d55f812", GitTreeState:"clean", BuildDate:"2018-01-04T11:52:23Z", GoVersion:"go1.9.2", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.2", GitCommit:"5fa2db2bd46ac79e5e00a4e6ed24191080aa463b", GitTreeState:"clean", BuildDate:"2018-01-18T09:42:01Z", GoVersion:"go1.9.2", Compiler:"gc", Platform:"linux/amd64"}
Дополнительная полезная информация из моего собственного расследования:
1. ПВХ и PV созданы и связаны. Увидеть ниже:
~$ kubectl -n kubeapps get pvc
NAME|STATUS|VOLUME|CAPACITY|ACCESS|MODES|STORAGECLASS|AGE
mongodb-data|Bound|pvc-516aeece-ff9d-11e7-82ac-000d3aa33484|8Gi||RWO|k8storage |14h
~$ kubectl -n kubeapps get pv
NAME|CAPACITY|ACCESS|MODES|RECLAIM POLICY|STATUS|CLAIM|STORAGECLASS|REASON|AGE
pvc-516aeece-ff9d-11e7-82ac-000d3aa33484|8Gi|RWO|Retain|Bound|kubeapps/mongodb-data|k8storage| |14h
2. Управляемые диски Azure автоматически создаются и подключаются к соответствующему узлу. Смотрите скриншоты с портала Azure:
Заранее спасибо!!!
2 ответа
Основываясь на полученной информации, вы можете перейти к точке зрения kubelet об этой проблеме ("события kubectl", "journalctl -u kubelet"), а также к возможным проблемам операционной системы, включая взаимодействие с Azure "journalctl -p 3" - "-p 3" предназначен для фильтрации только основных проблем (-p может идти от 0 до 7).
Вы должны разрешить этой учетной записи выделять хранилище.
Вы можете сделать это здесь: Статус поставщика ресурсов