Я запускаю кластер с одним узлом k3s и использую k3s local-path-provisioner в качестве хранилища. Поскольку я хочу иметь возможность добавлять узлы в будущем, я решил использовать minio в качестве хранилища поверх локального пути. Но я не уверен, что это правильный выбор, потому что мои рабочие нагрузки в основном используют mariadb для данных, и я читал, что корзина, совместимая с s3, не лучший вариант для приложений баз данных.
Надеюсь, вы поможете мне разобраться в этом.
Если вы не хотите использовать хранилище объектов, вот ваши варианты запуска локального поставщика хранилища:
GlusterFS StorageClass Не имеет большого количества документации о том, как его настроить. Но если вы разбираетесь в GlusterFS, это будет хорошим вариантом.
local-path-provisioner предоставляет способ чтобы пользователи Kubernetes могли использовать локальное хранилище на каждом узле
OpenEBS-> имеет механизм хранения локальных томов, но я думаю, что он не предназначен для работы с общим томом, и в конечном итоге он привязывает модуль к определенному узлу, поскольку данные не существуют на других узлах.
лонгхорн [рекомендуется]
Он создает выделенный контроллер хранилища для каждого тома блочного устройства и синхронно реплицирует том по нескольким репликам, хранящимся на нескольких узлах.
Rook — это оператор хранилища для Kubernetes. Он поддерживает несколько серверных хранилищ. Не используйте NFS, потому что мы упираемся в стену, когда используем ее с нашими БД.
