LINUX.ORG.RU

Kube-dump 1.0

 , ,


2

2

Состоялся первый релиз утилиты, при помощи которой производится сохранение ресурсов кластера Kubernetes в виде чистовых yaml манифестов без лишних метаданных. Скрипт полезен для тех, кому нужно перенести конфигурацию между кластерами без доступа к исходным файлам конфигурации, или для настройки резервного копирования ресурсов кластера. Запуск возможен локально в виде bash-скрипта, но для тех, кому не хочется устанавливать зависимости в виде kubectl, jq и yq подготовлен контейнер. Также контейнер готов для работы в виде CronJob с использованием ролей, назначенных в Service Account.

Ключевые особенности:

  • Сохранение выполняется только для тех ресурсов, к которым у вас есть доступ на чтение.
  • На вход можно передать перечень пространств имен, в противном случае будут использованы все доступные для вашего контекста.
  • Сохранению подлежат как ресурсы пространств имен, так и глобальные ресурсы кластера.
  • Использовать утилиту можно локально как обычный скрипт или запустить в контейнере или в кластере kubernetes (к примеру, как CronJob).
  • Может создавать архивы и ротировать их за собой.
  • Может фиксировать состояние в git-репозитории и отправлять в удаленный репозиторий.
  • Вы можете указать конкретный перечень ресрусов кластера для выгрузки.

Подробнее о настройке и работе со скриптом читайте документации

>>> Репозиторий

Я сам не жалую ненужнистов и считаю, раз какую-то программу написали, значит она востребована хотя бы её автором, но хочется спросить, а каков сценарий возникновения потребности:

перенести конфигурацию между кластерами не имея исходных файлов конфигурации

ugoday ★★★★★ ()
Ответ на: комментарий от ugoday

хочется спросить, а каков сценарий возникновения потребности

Я хз на счёт «не имея исходных файлов конфигурации», но и без этого выглядит привлекательно, чтобы не мудохаться со 100500 своих yaml.

Кроме того, секреты обычно в готовом виде не хранят.

no-such-file ★★★★★ ()
Ответ на: комментарий от ssh2

А разве корректно их сравнивать?

Да, вполне. Docker тоже умеет масштабироваться и является оркестратором. Но масштабируется он в ручном режиме, в отличие от кубера :) В общем, для небольшой инфраструктуры Docker (вероятно, в Swarm-режиме) может подходить гораздо лучше.

anonymous ()

Запуск возможен локально в виде bash-скрипта, но для тех, кому не хочется устанавливать зависимости в виде kubectl, jq и yq

А чего не на Golang, чтобы был один небольшой бинарник без кучи внешних зависимостей? Большинство утилит, связанных с кубером, делают именно так.

sT331h0rs3 ★★★★★ ()
Ответ на: комментарий от GP

swarm это отдельный проект оркестрации и к тому же в заброшенном состоянии.

Какую букву тебе расшифровать в Swarm Mode?

Docker не является оркестратором сам по себе

Конечно является.

anonymous ()
Ответ на: комментарий от ugoday

а каков сценарий возникновения потребности

Легко. Есть кластер, который поставил какой-то энзутиаст и свалил в закат. Документация? Не, не слышал. А тебе с этим жить

Утилита интересная, смотрю

router ★★★★★ ()
Ответ на: комментарий от no-such-file

Обычный сценарий использования подразумевает, что у вас есть исходники: просто yaml файлы или helm chart’ы и вы их разворачиваете на кластере. Если нужно развернуть их на другом кластере kubectl config use-context $ДругойКластер и раскатываете свои ресурсы на нём. Резервных копий делать не надо, всё, что требуется, уже надёжно хранится в git.

ugoday ★★★★★ ()
Ответ на: комментарий от ugoday

Ты удивишься…

И есть второй сценарий. Некоторый интырпрайзный софт стали поставлять в виде кластера k8s, который вендор разворачивает из собственного репозитория. Внутри всё тот же мистер Хэнки, зато в модном кубере. Но желательно понимать, как оно работает и как это счастье мониторить

В любом случае, дамп в yml будет полезен хотя бы для бекапа

router ★★★★★ ()
Последнее исправление: router (всего исправлений: 1)
Ответ на: комментарий от router

О, держи третий сценарий: Кластер развёрнут для нужд разработчиков. В творческом процессе разработки они что-то поставили, но уже не помнят, что именно

З.Ы. без обид, но у них другое мышление и другие приоритеты. Стабильность и повторяемость не всегда их интересует

router ★★★★★ ()
Ответ на: комментарий от router

Вы каким-то безумием занимаетесь. Остановитесь! Если инфраструктуру сопровождает вендор, то у вас: а) не должно быть прав лезть туда что-то менять своими грязными руками; б) факт, что вы куда-то залезли и всё испортили, является основанием, чтобы вендор послал вас в жопу и отказал в обслуживании. Так что вам ещё от начальства прилетит за самодеятельность.

ugoday ★★★★★ ()
Ответ на: комментарий от ugoday

Вы каким-то безумием занимаетесь. Остановитесь! Если инфраструктуру сопровождает вендор, то у вас: а) не должно быть прав лезть туда что-то менять своими грязными руками; б) факт, что вы куда-то залезли и всё испортили, является основанием, чтобы вендор послал вас в жопу и отказал в обслуживании. Так что вам ещё от начальства прилетит за самодеятельность.

В идеальном мире да. В реальном - тикеты в суппорт висят месяцами (привет индусам из IBM), а клиент и менеджеры ждут сервис сейчас. И если для восстановления сервиса нужно что-то простое, типа перезапуска компонента или небольшая правка конфигурации, то это возможно сделать самому. Понятно, что это неправильно, но клиенту насрать на ваш контракт с вендором и ваши проблемы, он платит за работающий сервис.

skyman ★★ ()
Ответ на: комментарий от skyman

небольшая правка конфигурации,

В случае k8s правка конфигурации осуществляется через commit в соответствующий репозитарий. А если вы делаете не так, значит вы делаете это неправильно.

ugoday ★★★★★ ()
Ответ на: комментарий от ugoday

б) факт, что вы куда-то залезли и всё испортили, является основанием, чтобы вендор послал вас в жопу и отказал в обслуживании.

Так, на всякий. Я сказал «мониторить», а не «менять»

router ★★★★★ ()
Ответ на: комментарий от Pavval

https://kubernetes.io/docs/reference/using-api/api-concepts/

The Kubernetes API is a resource-based (RESTful) programmatic interface provided via HTTP.

Ресурсы это деплойменты, конфигмапы, роли, аккаунты и т.д. Они могут быть как cluster-scope (глобальные для всего кластера), так и namespaced (ресурсы в рамках одного пространства имен)

WoozyMasta ()
Ответ на: комментарий от sT331h0rs3

Это была первая итерация, что бы сделать быстро и не упороться, если будет спрос и запрос фитч будет расти, возможно будет переписано на go.

А пока оформление репы заняло больше времени чем сам скрипт)

WoozyMasta ()
Ответ на: комментарий от Rinaldus

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

https://kubernetes.io/ru/docs/concepts/overview/what-is-kubernetes/

anonymous ()
Ответ на: комментарий от demidrol

аффтар не может в длинные предложения. Ну не говорят так психически здоровые люди.

Когда я занимался техническим переводом, нас призывали переводить именно так. Не выпендриваться, а писать понятно.

olegd ★★ ()