Как и зачем в Lyft улучшали Kubernetes CronJobs

[gecube]

Крутая статья! Спасибо!

В случае Unix cron'а stat-and-log будет выполняться ровно один раз для каждого вызова cron'а — независимо от $exitcode.

Только это не совсем так. Если случится авария и скрипт не успеет дойти до stat-and-log, то мы лог не получим. Так что особую аккуратность надо и с классическими cron job'ами применять. Не говоря уже о том, что что-то может притормозить работу джоба и случится оверлап. У нас такая история была с фактором загрузок с внешнего фтп. Сеть моргнула, скрипт ушел в себя. Поэтому корректнее говорить, что stat-and-log будет вызван НЕ БОЛЕЕ одного раза за один запуск cron job. Ну, и вообще удивительно, что такая технологическая компания вроде Lyft не осилила systemd timers — там очень много возможностей, как по отладке, так и по настройке — включая рандомные задержки запуска джобов, чтобы не было "горячих точек" именно в ::00 и прочие интервалы.

Дополнительно я бы заметил, что базовый крон так же гарантирует вызов джобы по расписанию не более одного раза — опять же может быть выключен сервер или что-то еще. Если требуется соблюдение количества запусков, то нужно какое-то другое решение. Или, что бывает проще, переписать саму джобу так, чтобы она учитывала особенности окружающего мира

Насколько отличается производительность Kubernetes CronJob'ов (выполняющихся в режиме multi-tenant) от single-tenant cron'а Unix?

Да-да-да, очень "актуальный" вопрос. Потому что на сервере, где крутится cron, может быть еще стопицот программ и демонов в фоне, но действительно контроль выше, чем в полностью динамической среде кубернетесе. Мы "тяжелые" задачи cron выносили по времени, чтобы они не пересекались и держали пальчики скрещенными, чтобы оно не бабахнуло (всякие бекапы и все такое). Но это по сути ручная и кустарная работа — каждый раз под конкретный сервер. И опять же как только меняется окружение — приходится опять играть в тетрис с кронджобами на отдельно взятом сервере. Действительно хочется какого-то универсального решения, которое будет четко все мониторить и, скажем, попросту скажет, что кронджоба не сможет выполниться, потому что не хватило ресурсов, а не будет насиловать планировщик — тут уже какие-то элементы "decision making" прослеживаются.