Существует ли промежуточный слой/кэш между модулем Kubernetes и томом Persistence или модуль напрямую обращается к PV

#kubernetes #containers #openshift #persistent-volumes #glusterfs

Вопрос:

Недавно я столкнулся со странной проблемой. У нас есть два модуля, работающих в кластере openshift, который разделяет постоянный том ( GlusterFs ) между ними. Теперь ради этого объяснения давайте предположим, что один из модулей был PodA, а другой-PodB, в этом случае PodB работал в течение трех месяцев, в POdA есть автоматизация, которая создает/обновляет файлы в общем томе сохраняемости, а PodB считывает его и выполняет некоторую операцию на основе ввода.

Теперь перейдем к проблеме: всякий раз, когда POdA создавал новый файл в общей папке, он был виден и доступен из PodA. Тем не менее, было несколько файлов, которые PodA периодически обновляла, но изменения не были отражены в PodB. Таким образом, в PodB мы могли видеть только старую версию этих файлов. Чтобы решить эту проблему, мы принудительно удалили PodB, а затем openshift воссоздал его, и проблема исчезла.

Я думал, что в PV механизме Kubernetes монтируется внешнее хранилище/папка в pod (контейнер), и там нет промежуточного слоя, кэша или чего-то подобного. Из того, что мы испытали до сих пор, кажется, что каждый контейнер (или pod ) создает локальную копию этих файлов, или, возможно, между ними есть кэш ( PV и pod ),

Я искал об этом в Google и не смог найти подробного объяснения того , как это PV крепление работает в Kubernetes, хотел бы знать реальную причину этой проблемы.

Ответ №1:

Для PVS, предоставляемых Kubernetes, не существует механизма кэширования, поэтому проблема, которую вы наблюдаете, должна находиться либо в драйвере CSI GlusterFS, либо в самом GlusterFS.

Комментарии:

1. Если это была проблема с GlusterFS, как получилось, что один из существующих модулей отображал его (файл) правильно(в PodA мы могли видеть изменения). Казалось, что это была проблема с PodB, которая работала в течение трех месяцев.