Удалять старые baremetal и заводить новые

Я так и делаю на baremethal, очень удобно https://kubernetes.io/blog/2018/10/02/building-a-network-bootable-server-farm-for-kubernetes-with-ltsp/

👍 У меня только MAAS

👍 У меня только MAAS

да в принципе норм. прикрутил его к CI/CD который сделан вокруг kubernetes при изменении, тестируется на gcp/aws/azure, и заодно проверяется на baremetal пришлось написать свой power management для железок без ipmi и вообще remote power control, железки бутаются по wake on lan, и ребутаются через ssh врпинципе оно работает уже 2 года, но переодически, раз в сезон MAAS нужно перезагружать, в нем как-то ОЧЕНЬ сильно ломается iscsid который раздает диски. diskless не пробовал и вообще туда не копал, из CI хожу к MAAS через rest, все ок, плоская модель прав :/

👍 У меня только MAAS

коллеги, подкиньте идею, есть задача - разворачивать большую и толстую(20гб) субд(постгре) на тесты в кол-ве N экземпляров за максимально короткое время. При этом данные чтобы хранились в PV на ceph. Про снапшоты читал, но пока слишком сырое это добро. Есть шальная мысль предподготавливать PV (в кол-ве N штук) и потом монтировать в нужные поды, но это тот еще костыль

20гб можно и копернуть

коллеги, подкиньте идею, есть задача - разворачивать большую и толстую(20гб) субд(постгре) на тесты в кол-ве N экземпляров за максимально короткое время. При этом данные чтобы хранились в PV на ceph. Про снапшоты читал, но пока слишком сырое это добро. Есть шальная мысль предподготавливать PV (в кол-ве N штук) и потом монтировать в нужные поды, но это тот еще костыль

можно, но долго, в идеале не больше пары минут должно занимать

Сделай просто имадж на 20гб

А поменьше её сделать никак?

ну сделайте так, что-бы pvc не удалялся...

пока просто имадж заливается без pvc, мы ж не можем директорию из контейнера запихать в pv в процессе старта

видимо я задачи до конца вашей не понимаю, хранить эталонный образ с дампом от живой psql? и подсовывать разным подам, что-бы они быстрее поднимались? после тестов, удалить pod, но что-бы pvc оставалась?

Да все просто, есть задача делать EaaS, на данный момент их 12, нужно чтобы среда поднималась с подготовленной базой, и жила столько - сколько нужно, не теряя данные при пересоздании подов

одна из идей - это как раз делать заранее подготавливать пул PV с данными и монтировать его при старте пода с базой

на все про все минут 10-12 уходит

Предлагаю забить

щас так и есть, но если под удаляется - данные идут лесом

это сделать возможно. например такое умеет helm из коробки. при деплойменете вашего вокрлоада, можно указать что-бы PVC были переиспользованы (и при удалении workload'a) они не удалялись. Можно это сделать и руками. Тут скорее вопрос, ваши тесты меняют саму базу? и если да, то для следующих тестов она уже не пригодна?

В смысле идут лесом, если они в образ вшиты?

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

Если есть любовь к извращениям - hostpath и снапшоты lvm

А нельзя использовать одну субд с разными базами внутри?

А кто-нибудь sysdig использует для мониторинга кубера?

Тогда это тем более выглядит как хотелка

И даже объём базы был сравнимый, гигов 30-40

коллеги, подкиньте идею, есть задача - разворачивать большую и толстую(20гб) субд(постгре) на тесты в кол-ве N экземпляров за максимально короткое время. При этом данные чтобы хранились в PV на ceph. Про снапшоты читал, но пока слишком сырое это добро. Есть шальная мысль предподготавливать PV (в кол-ве N штук) и потом монтировать в нужные поды, но это тот еще костыль

про более быстрые способы restore? я так понимаю речь о -j core_count? или есть еще какие-то отработанные вещи?

щас так и есть, но если под удаляется - данные идут лесом

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

Значит база ок живёт на overlayfs? Можно свой собрать тогда, будет копироваться все равно, но растянуто по времени. Базовый слой монтировать в read-only без проигрывания журналов, тогда ни байтика на блочное устройство не запишется :)

Вливка дампов или упаковка самой базы в имадж- крайне не удачное решение

Да я чет подумал если просто весь контейнер заранее готовить )

да в принципе норм. прикрутил его к CI/CD который сделан вокруг kubernetes при изменении, тестируется на gcp/aws/azure, и заодно проверяется на baremetal пришлось написать свой power management для железок без ipmi и вообще remote power control, железки бутаются по wake on lan, и ребутаются через ssh врпинципе оно работает уже 2 года, но переодически, раз в сезон MAAS нужно перезагружать, в нем как-то ОЧЕНЬ сильно ломается iscsid который раздает диски. diskless не пробовал и вообще туда не копал, из CI хожу к MAAS через rest, все ок, плоская модель прав :/