Comments 6
Администраторы кластеров kubernetes сталкиваются с задачей сохранить конфигурацию ресурсов из пространства имен и перенести в другой кластер
Разве это не решается использованием подхода CasC? То есть, не кластер должен быть источником доверия, а конфиг в гите. Особенно это справедливо для разработки в тестовом кластере: поменял что-то — закоммить, чтобы потом не выгребать и не смотреть что поменялось (для этого же есть гит).
Вы абсолютно правы и в идеальном мире так и должно быть. Но ситуации бывают разные, в связи с этим и появилась потребность в данном скрипте.
Пример: имеется несколько кластеров песочниц, и у каждого разработчика есть по персональном неймспейсу с прямым доступом для проведения экспериментов. Переодически появляются запросы восстановить или откатить что-то случайно удалённое.
China Aerospace Science and Technology Corporation? :)
IaC (Infrastructure as Code).
И "поменял что-то закоммить" должно быть крайней мерой и только для администраторов куба. И то концепция GitOps при переходе на неё меняет и это почти на 100%.
Для разработчика нормальным должно быть: заккомитил, применилось (GitOps в чистом виде).
В некоторых компаниях вижу практику, упрощённо говоря, continues apply, то есть периодически происходит apply кода манифестов куба из репозитория и это в том числе очень больно бьет по рукам тем, кто что-то вручную менял.
Есть более мощное и зрелое решение от heptio — https://velero.io/.
Velero состоит из:
- Сервер, который работает в вашем кластере
- Клиент командной строки, работающий локально
В моем же случае нет деления на клиент-сервер, что и побудило к данной более простой реализации.
Плюсую за Velero, очень мощная штука.
Использует в т.ч. CSI Volume Snapshotter, дампит stateful в какой-нибудь S3 легко и быстро. Нормально работает в т.ч. с Ceph.
Резервное копирование конфигурации ресурсов в Kubernetes