Всем привет! Методологический вопрос: Насколько разумно грузить кубер прикладными задачами? Например,

мне нужно, чтобы файлики (несколько тысяч шт.) были разложены по внешним s3-бакетам по определённому принципу (они описаны декларативно). Чтобы это поддерживать, нужно раз в час проверять-перекладывать их.

Мерещатся два варианта реализации:

1) old way: хранить данные в СУБД и запускать по крону (upd: тут подсказали, что можно куберовской CronJob) некий батч-скрипт из прикладного кода (СУБД для приложения у нас уже есть, она не в кластере)
2) new way: хранить данные в самом control-plane кубера (т.е., завести отдельный ресурс типа AppFile, хранить его статус, и т.п.), а активную логику реализовать в виде куберовского оператора.

п.2. вообще делается или баловство это?)

И там и там хочется получить от кубера интроспекцию в плане эксплуатации джобов (ресурсы, время, ошибки, логи) — это понятно. А вот сами данные?)

как по мне использовать CR куба как базу данных для приложения, которое по сути использует куб только как платформу запуска не очень круто (то есть там будет этих AppFile несколько тысяч как я понимаю). С таким подходом можно дойти до того что вы стейт бэкендов в CR куба будете хранить =). Юзер заходит на сайт, а там под капотом: clientset.CRVersion().User(namespace).Get(context.TODO(), username, metav1.GetOptions{}) 😄 Куб все таки фреймворк для инфры (платформы), а не часть приложения. Так вы будете нагружать kube-apiserver и etcd не тем, для чего они нужны Третий пункт 3) запускать в cronJob и использовать СУБД

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

В официальной документации есть про то когда стоит использовать CR https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/#should-i-add-a-custom-resource-to-my-kubernetes-cluster

Нет, смысл куба точно не в этом В чем смысл интеграции? Какую задачу это решает?

Имхо вы не туда воюете) Смысл куба это запускать контейнеры на больше чем одной машине 💁‍♂

Посмотри Apache Airflow для управления задачами. https://airflow.apache.org/

Жестко - ребята бы из проекта KubeEdge и подобных обиделись бы) K8s это же framework и многое что позволяет реализовывать

Это фреймворк для инфраструктуры

следовательно это зависит не от данных, а от задачи

Естественно. Использовать куб как базу для своих ворклоадов вместо условного postgresql очевидная дичь, я не понимаю что тут обсуждать. Этот подход не масштабируется (там etcd под капотом), влияет на все приложения в кластере, и естественно опасен для стабильности клатера

я это к тому что это не только для "запуска контейнеров на больше чем одной машине "

Не означает ли это, что замена етцд на постгрес решает подобную задачу?

нет

Спасибо и на этом.)

А как по мне смысл куба в охуенном апи из коробки, которое можно применять как дела вздумается)

От замены СУБД ничего особо не меняется же, основные проблемы остаются Мне кажется это достаточно понятная история

я не раз использовал куб, для сохранения данных, например, для сохранения статуса синхронизации нетворк полиси с ngfw, обновление статуса ноды через нод проблем детектор, на основании которого мог производиться дешедулинг подов, обновления статуса для внешнего балансера, на основании которого осущестлялся сервис дискавери ноды куда пускать трафик. Для меня это были хорошие кейсы когда через апи куба можо было получить нужные данные не создавать для этого внешнюю БД, так как нагрузка была копеечная. Те для меня куб это не про запустить контейнер боольше чем на одной ноде (для этого я успешно исползовал и ансибл) - это скорее рантайм среда для стандартизации запускаемых ворклоадов с довольно гибким апи для кастомизации своих процессов.

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