использование сетевого пути NFS в качестве тома персистенции kubernetes

Question

Я настроил кластер kubernetes с тремя узлами. Все узлы являются машинами Linux Centos.

Мне нужен постоянный том для хранения данных, и я пытаюсь добиться этого.

Я следовал этому уроку. Но он охватывает только один узел кластера. https://kubernetes.io/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/

Поскольку мой кластер состоит из трех узлов, я не могу использовать локальный путь. Предыдущий урок не работал для меня.

Мне нужен сетевой путь, и использование NFS кажется мне разумным решением. (Есть ли хорошая альтернатива, которую я хотел бы услышать.)

Использование сетевого монтирования NFS состоит из двух шагов. Во-первых, создание постоянного тома на сетевом пути. Во-вторых, определите этот сетевой путь как постоянный том и используйте его.

Второй шаг довольно прямой. Это объясняется в документации kubernetes и даже есть пример yaml. документация: https://kubernetes.io/docs/concepts/storage/persistent-volumes/#persistent-volumes пример: https://github.com/kubernetes/examples/blob/master/staging/volumes/nfs/nfs-pv.yaml

Первая часть также кажется прямой. Это объясняется в следующем документе

https://www.digitalocean.com/community/tutorials/how-to-set-up-an-nfs-mount-on-ubuntu-16-04#step-5-%E2%80%94-creating-the-mount-points-on-the-client

/etc/exports
directory_to_share    client(share_option1,...,share_optionN)

/etc/exports
/var/nfs/general    203.0.113.256(rw,sync,no_subtree_check)
/home       203.0.113.256(rw,sync,no_root_squash,no_subtree_check)

Но когда вы экспортируете путь как путь NFS, вы должны выполнить некоторую настройку и предоставить клиентам некоторые права. В основном вам нужен клиент ip.

В kubernetes мы используем абстракции, такие как pods, и мы не хотим иметь дело с реальными машинами и их IP-адресами. Итак, проблема начинается здесь.

Итак, я не хочу передавать узлы ip серверу nfs. (Они могут измениться в первую очередь.) Должно быть лучшее решение, чтобы все модули (в любом узле) могли подключаться к сетевому пути NFS.

Даже разрешение всех ip без ограничений или диапазон ip может решить проблему. Я хотел бы услышать, если есть такое решение. Но я также хотел бы услышать, что является лучшей практикой. Как все остальные используют сетевой путь NFS из kubernetes.

Я не смог найти никакого решения. Если вы решили похожую проблему, пожалуйста, дайте мне знать, как вы ее решаете. Любая документация по этому вопросу тоже будет хорошей. Заранее спасибо!

Answer 1

Вы спрашивали о лучших практиках, и из того, что я нашел, я думаю, что лучшим вариантом будет белый список IP-адресов. Поскольку вы не хотите этого делать, есть также несколько обходных путей ответов, опубликованных на SO , созданных людьми, у которых были похожие проблемы с динамическими IP-клиентами в NFS. Вы можете найти ссылку на развертывание, используя glusterfs в опубликованных ответах. Если вам нужна NFS с динамическим IP-адресом (поскольку он может меняться), вы можете использовать DNS-имена вместо IP-адресов. Если вам нужна динамическая подготовка, используйте glusterfs.

Я добавлю некоторую информацию о томах, как вы просили. Мог бы пролить свет на эту тему и помочь с этой проблемой.
Поскольку стручки эфемерны, вам необходимо переместить том за пределы стручка, что делает его независимым от стручков, чтобы объем сохранял свое состояние в случае отказа стручка. Kubernetes поддерживает несколько типов томов.
Вы можете использовать NFS (подробнее о NFS в предыдущей ссылке) - поэтому после удаления модуля том отключается, но он все еще существует. Это также нежелательно в вашей ситуации, поскольку пользователю необходимо знать тип файловой системы и другие сведения о томе, к которому он будет подключаться. Когда вы перейдете к примерам в документации о файлах yaml NFS, вы увидите, что их вид определяется как Заявка на постоянный том .
Этот метод основан на создании серии абстракций, которые позволят узлу подключаться к постоянному тому, но пользователю не понадобятся какие-либо подробности о бэкенде, кроме того, ваш узел может подключаться ко многим поставщикам.