Рейтинг:1

Kubernetes не может монтировать тома NFS после обновления и перезагрузки сервера NFS

флаг pk

После застежка-молнияПри установке на сервер NFS на openSUSE Leap 15.2 последней версии и перезагрузке узлы в кластере kubernetes (Openshift 4.5) больше не могут монтировать тома NFS.

Версия сервера NFS: nfs-kernel-server-2.1.1-lp152.9.12.1.x86_64.

/etc/exports содержит:

/nfs 192.168.11.*(rw,sync,no_wdelay,root_squash,insecure,no_subtree_check,fsid=0)

Затронутые модули находятся в состоянии ContainerCreating.

kubectl описать pod/<pod_name> выдает следующую ошибку:

Предупреждение FailedMount 31m kubelet MountVolume.SetUp не удалось для тома «том»: сбой монтирования: статус выхода 32
Команда монтирования: systemd-run
Аргументы монтирования: --description=временное монтирование Kubernetes для /var/lib/kubelet/pods/c86dee2e-f533-43c9-9a1d-c4f00a1b8eef/volumes/kubernetes.io~nfs/smart-services-http-video-stream --scope -- mount -t nfs nfs.example.invalid:/nfs/volume /var/lib/kubelet/pods/c86dee2e-f533-43c9-9a1d-c4f00a1b8eef/volumes/kubernetes.io~nfs/pv-name
Вывод: работающая область как единица: run-r83d4e7dba1b645aca1e4693a48f45191.scope
mount.nfs: операция не разрешена

На сервере работает только NFSv4, поэтому rpcbind отключен и команды showmount не работают.

Установка непосредственно на узел kubernetes приводит к следующей ошибке:

sudo mount.nfs4 nfs.example.invalid:/core tmp/ -v; эхо $?
mount.nfs4: тайм-аут установлен на среду, 21 июля, 12:16:49 2021 г.
mount.nfs4: пробуем текстовые опции 'vers=4.2,addr=192.168.11.2,clientaddr=192.168.11.3'
mount.nfs4: mount(2): операция не разрешена
mount.nfs4: операция не разрешена
32

Правила firewalld на сервере NFS:

  сервисы: ssh dhcpv6-client nfs mountd rpc-bind samba http tftp
  порты: 2049/tcp 2049/udp

AppArmor работал, отключение не изменило результат.

До обновления сервера NFS все работало нормально, и никаких других изменений конфигурации не производилось. Как я могу отладить это и снова сделать общие ресурсы доступными?

Рейтинг:3
флаг pk

После попытки отладить эту проблему с помощью rpcdebug безрезультатно, я прибегал к сбросу трафика на сервер nfs, поступающего с одной из нод. Этот дамп дал интересное наведение:

Ответ NFS xid 4168498669 ответ ERR 20: фиктивные учетные данные аутентификации (пломба нарушена)

Так что проблема точно не была связана с сетью или аппармором.

Затем я попытался изменить экспорт к

/nfs *(rw,sync,no_wdelay,root_squash,insecure,no_subtree_check,fsid=0)

и все заработало, подтвердив, что эта проблема кроется в какой-то экспорт неправильная конфигурация.

Переписать правило на

/nfs 192.168.11.0/24(rw,sync,no_wdelay,root_squash,небезопасно,no_subtree_check,fsid=0)

восстановил связь.

Согласно с https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/5/html/deployment_guide/s1-nfs-server-config-exports

подстановочные знаки - Где * или ? символ используется для учета группы полных доменных имен, которые соответствуют определенной строке букв. Подстановочные знаки не должны использоваться с IP-адресами; однако они могут сработать случайно, если обратный поиск DNS не удался.

Таким образом, использование * с IP-адресом было явной неправильной конфигурацией, которая каким-то образом работала в течение нескольких месяцев и, наконец, привела к ошибкам, описанным в вопросе.

Ответить или комментировать

Большинство людей не понимают, что склонность к познанию нового открывает путь к обучению и улучшает межличностные связи. В исследованиях Элисон, например, хотя люди могли точно вспомнить, сколько вопросов было задано в их разговорах, они не чувствовали интуитивно связи между вопросами и симпатиями. В четырех исследованиях, в которых участники сами участвовали в разговорах или читали стенограммы чужих разговоров, люди, как правило, не осознавали, что задаваемый вопрос повлияет — или повлиял — на уровень дружбы между собеседниками.