Привет всем! Я столкнулась с ситуацией в Kubernetes: представьте, что другой

пользователь создает снапшот своего состояния Kubernetes с помощью инструментов, наподобие microk8s dbctl. Этот снимок включает поды, настроенные на работу на конкретных узлах - узлах этого пользователя.
Теперь, когда я пытаюсь восстановить эту резервную копию на своем узле с помощью команды, например, microk8s dbctl restore backup-2023-11-06.tar.gz, все восстановленные поды продолжают пытаться запуститься на узлах, указанных в снимке.
Моя цель - изменить это поведение так, чтобы при восстановлении поды назначались и работали на моих узлах, а не тех, что были указаны при создании резервной копии. И важно, что это должно происходить без редактирования YAML-файлов или других конфигураций.
Есть ли у кого-нибудь идеи, подходы или возможные инструменты, которые помогут в этой ситуации? Мне бы хотелось найти решение, которое было бы максимально доступно для конечного пользователя, не требовало бы детального знания о конфигурации YAML или настройках узлов и дало бы больше контроля над процессом восстановления.
Заранее большое спасибо за любые советы и предложения!

Если это тестовое - шлите их нахер)

Не)

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

Я понимаю, а если узлов очень много? Нужно же сделать так, чтобы пользователь сам смог ноду указать, без вмешательства в конфигурацию

Какая священная информация у вас хранится в дампе, от которой нельзя отказаться в пользу сетапа "чистого" кластера?

Различные пользователи создают различные поды с уникальными данными и настройками. Восстановление с "чистого" кластера не воспроизведет эти уникальные настройки. Моя задача - помочь пользователям восстановить их поды на своих узлах так, как они были задамплены, чтобы они могли продолжить работать без необходимости вручную изменять конфигурации или настройки

вам не нужен кубер

О_о

Ну это нетривиальная задача

Но этого требует бизнес, моя задача лишь развернуть)))

С бизнесом нужно говорить всегда)

Товарищ ниже правильно сказал - вы хотите странного

шо за наркомания

ничего необычного, просто xyproblem?

не может бизнес требовать того, чего не знает. Кто-то бизнесу сказал, что так можно, если вы, то вы ошиблись. Вернитесь к началу и продумайте все еще раз

Конфигурация - это yaml с описанием где и что должно быть. Куб управляется через yaml. Просто очень похоже, что или задача неправильно поставлена/интерпретирована или инструмент неподходящий.

У меня есть снапшоты, сделанный другим пользователем. В этом снимке уже прописано, на каких узлах должны работать приложения (поды). Когда я восстанавливаю такой снимок, поды автоматически хотят работать на тех же узлах, где и был сделан снапшот. Но у меня эти узлы могут быть другими, или их может вовсе не быть. Я хочу найти способ, чтобы при восстановлении снимков можно было быстро и просто изменить узел, на котором будут работать поды. Это нужно, чтобы не делать дополнительных настроек и чтобы пользователям было проще восстанавливать свою систему у себя. Важно, что все это хочется делать без редактирования yaml-файлов конфигурации, потому что это сложно для пользователя и занимает много времени. Есть ли функция или инструмент, который мог бы помочь в моем случае? Извините, если вы меня неправильно поняли)

Среди всего обилия есть базы?

а в чем проблема если под запустится на другой ноде?

Надо чтобы на локальной пользователя запустился

Короче, напишите композ-файл и скажите бизнесу, что это кубер.

Было так всё просто

Забудьте про снапшоты - это специфика микрок8с, похоже

Я это прочитал :) единственное, что напрашивается - mutation webhook. На запуск этих подов, но опять таки это надо настраивать.

Зачем? Тут речь о хелм-чарте, по сути. Ни одного объяснения необходимости снапшота.

Вроде то что нужно. Ознакомлюсь, спасибо)

Беги оттуда !

А состояние восстановленного пода pending? а что если ему describe сделать? возможно pv был hostpath и он хочет именно эту ноду? вообще чето не то, кубер про запуск нагрузки на любых или желаемых узлах, и от локальных томов толку ноль.