~18кк Job, вытащить из них логи и результат выполнения (код возврата) на локальную тачку. Хорошо, если это будет какая-нибудь embedded база (ну или я потом туда перелью). Я запускал самопальный скрипт, он у меня в один поток 15к job запускал порядка суток.
логи большие получаются? >10к строк? скрипт лучше перепишите на асинхронность
Не, обычно меньше, думаю около 1к (под рукой образцов нет). Логи с stdout мне нужны
я сначала думал порекомендовать вам забирать логи через kubectl logs, но это нагрузка на apiserver, потому на вашем месте я бы взял стек Vector+S3
Не уверен что это лучший вариант, но как насчёт тектона?
Логи в ЭЛК, определенно
А он не захлебнётся? Gitlab на тысячах погиб
> он у меня в один поток 15к job запускал порядка суток. А тут сутки это по какому алгоритму. На каждую итерацию запускаем job, дожидаемся выполнения, читаем логи? Их наверное лучше пачками запускать. По 100-1000 штук например. И только потом логи вытаскивать. Мб так быстрее будет?
Да, именно так и было. Молотила рабочая тачка, не хотел не сильно нагружать
Так не хочется разводить зоопарк утилит …
Могу ошибаться, но мне казалось там несколько независимых контроллеров и горутины :)
в кубе можно через apiVersion: v1 items: - apiVersion: .. kind: ... ... - ... Пачку ресурсов одним запросов создавать. Мб так быстрее тоже будет
Это не зоопарк, а уже вроде как одно из стандартных решений по сбору логов в k8s
там лучше задачу прочитать изначальную. Чтобы понятен был контекст
ну и из elk нужно будет тоже логи же вытаскивать. Хотя тут будет плюс, что ты можешь сделать это потом. Уже после апплая своих 18kk задач. Не знаю быстрее это будет или нет. Потести
Тут вопрос в скорости
имхо, основной смысл elk не в том чтобы их забирать оттуда, а для того чтобы эффективно с ними работать.
да, но по задаче, человеку нужно выташить логи результата выполнения 18 000 000 джоб, и положить локально в файлики.
Хм, ну тогда бы я взял условный S3, и тупо засылал бы в него логи в рамках каждой джобы постфактум 🤔
Обсуждают сегодня