Хранилище Kubernetes для мультиузла на VPS
У меня есть базовая настройка Kubernetes (из некоторых руководств) на 4 серверах VPS 1 мастер узел и 3 рабочих узла. Но теперь я прочитал книгу о постоянстве и не знаю, с чего начать.
План таков: разместить веб-сайт с непрерывной загрузкой, но мне нужно, чтобы данные были доступны всем воркерам. Какой лучший вариант для кластерного типа, есть ли какой-нибудь модуль или надстройка Kubernetes, которые я могу использовать, чтобы что все 3 рабочих разделяют данные, и если один, скажем, дней, остальные продолжат работать? Пожалуйста, помогите, поскольку мне нужно, чтобы все данные, включая MySQL, были масштабированы на всех 3 рабочих узлах, и если один рабочий узел выходит из строя, вся работа продолжается с рабочими узлами 1 и 2 до тех пор, пока 3 не будут восстановлены или заменены.
Укажите правильное направление, так как я не могу создать сервер NFS на VPS.
- CNS
Если придерживаться Kubernetes, очевидным ответом будет поиск решений для хранения контейнеров (например, Ceph и Rook или GlusterFS, которые я бы не рекомендовал).
Хотя обычно это подразумевает определение размера ваших узлов и соответствующее подключение блочных устройств. В некоторых случаях могут иметь смысл выделенные узлы, позволяющие избежать проблем с параллелизмом. В противном случае убедитесь, что все модули имеют правильные запросы и ограничения процессора / памяти.
Более простое решение могло включать что-то вроде MinIO. Настроить это не так уж и сложно, можно легко полагаться на файловую систему вашего хоста. Хотя основная проблема будет в том, что ваши приложения должны реализовывать хранилище s3. Нет базы данных MySQL. Вряд ли ваш сайт может работать таким образом.
- Выделенный кластер
Другой вариант - развернуть собственный кластер хранения на отдельных узлах. Ceph - хороший кандидат, поищите на GitHub учебники, поддерживающие ceph.
Здесь использование небольших узлов (1-2 ЦП, 4-8 ГБ ОЗУ, 1-3x 1T SATA2, сеть 1x1G) будет проще, чем с Rook. Несмотря на то, что характеристики не будут впечатляющими, тем не менее, он будет надежным. Рекомендации по аппаратному обеспечению нацелены на максимальную производительность, Ceph предназначался для работы на стандартном оборудовании.
- Выделенные хосты
Проще, чем кластер хранения: что-то вроде пары FreeBSD, использующих ctld (цель iscsi), hastd (устройства синхронизируются между вашими хостами), carp (VIP) и ifstated (скриптинг hastd) синхронизация аварийного переключения на основе состояния VIP). И, возможно, ZFS, для управления томами, снимков, ...
Или пара Linux с tgt (iscsi target), drdb (синхронизация устройств) и keepalived (скрипты VIP +). И тома / снимки LVM.
Или только один сервер (не рекомендуется).
Может быть, придерживаться общих ресурсов NFS (не рекомендуется).
- Сторонние
Если повезет, ваш хостинг-провайдер действительно предлагает решение (iSCSI, ceph или блочные устройства Gluster, возможно, некоторые общие ресурсы NFS, ... избегайте использования samba). В некоторых случаях может быть дорого.
- Ничего из вышеперечисленного
В противном случае у вас останутся тома hostPath.
Данные будут записаны непосредственно на заданных узлах Kubernetes, вам нужно будет сопоставить поды с сохраняющимися данными со статическим узлом.