GG
я сталкивался с проблемой, например, что к8с раннер, если падал и решедюлился - от него конфигмапы оставались для запущенных пайплайнов
Size: a a a
2021 July 04
GG
так что тебе при любом раскладе делать что-то типа гарбедж коллекшена ))))
GG
нет
GG
у пода нет понятия "максимальное время жизни". А раннер в теории обязан подчищать за собой хвосты, но вот незадача - у него стейта нет 😊 поэтому если раннер перезапустить - он ничего не знает о тех пайплайнах, которые были запущены на предыдущей итерации
GG
ты мог с этим не сталкиваться, потому что у тебя ресурсов в кластере много и сам гитлаб раннер, условно, не перезапускается ))) но вот мы говна поели с этим
GG
и с конфигмапами он серил вообще всегда :/ было нежданчиком найти 10000 конфигмапов в одном неймспейсе
GG
жрет )
GG
проц жрет, место в етсд жрет
GG
лимиты/реквесты жрет
GG
короче, я к чему - просто не питай иллюзий, что все хорошо ))))
GG
ну, я не спорю 😊 мы же обсуждаем недостатки метода, так ?
GG
а насчет докер машины - ты тоже зря думаешь, что она сильно медленнее будет - она умеет кэш виртуалок держать для быстрого запуска - разз
GG
два - понятно, что это возможно, если у тебя нормальный IaaS, а не "запуск виртуалки 20 минут"
GG
на спотах не будет дороже
GG
расскажи - у вас гарантии выделения ресурсов для раннеров какие? Наши разрабы, например, хотят на шаред раннерах запускать интеграционные тесты с кассандрой
GG
я к чему веду - есть задачи, которые требуют мало памяти и проца (например, простая сборка докер образа), а есть те, которые требуют как не в себя. Если ты их запихнешь без лимитов реквестов - у тебя пайплайны падать постоянно будут по ООМ. Если ставить лимиты - тебе придется ранжировать раннеры по размерам