Кубертатный период

Ваши разрабы не хотят разгребать легаси и рефакторить кронтаски в отдельный scheduler с очередью?
У вас есть сотни кронтасок в проде, которые вы хотите таки контролировать в контейнерах?
У вас айсикью выше 70, раз вы все еще не описали каждую строку crontab в отдельном Kubernetes ресурсе (Job/Cronjob)?

тут уже говорили про недостатки крона
Supercronic пытается решить некоторые из них: кронтаски наследуют переменные окружения, выводит логи в stderr, логирует запуски результат выполнения и ошибки, посылает SIGTERM/SIGINT и что-то там еще.

Supercronic is a crontab-compatible job runner, designed specifically to run in containers.

Legacy не убить!

Еще один пример XY Problem

В аппку летит кривой реквест (не тот хост, заголовок или еще что-то — неважно).

И вместо того чтобы задаться вопросом

почему

начинается

а давайте перепишем код, чтобы он переписывал реквест на правильный

И это барахло вроде даже работает.

Но проблема никуда не делась. Потом это всплывёт в самом тупорылом месте: на втором домене, в другом окружении, за CDN, после смены балансира, при переезде в другой ingress/controller/платформу.

Не говоря уже о том что часто такое решение сопровождается кривым нечитаемым и неинтуитивным кодом. Не надо так делать — пытайтесь лечить причины, а не симптомы

Кстати пост написан с применением ЕИ

полгода назад ко мне пришли с вопросом, мол, есть какой-то сервис что-то про «ембеддинги», я особо не разбирался: ну еще какой-то микросервис где-то, хотим масштабирование «scale to 0». вводная при этом звучала конкретно: скейлиться нужно на основе кастомной метрики очереди — в очереди есть сообщения, значит поднимаем сервис, нет сообщений — 0. ну и я в общем-то почти не думая сразу вкинул про Keda, обрисовал что такое как работает и зачем.

я еще пару раз слышал, что с этим вопросом еще разбираются, попутно удивляясь, почему так долго: ведь очередь есть, сообщения там есть, сервис есть.. осталось лишь воткнуть ScaledObject и все.. но не так то просто! как я тогда это понял: есть queue-driven workload, которому просто не хватает autoscaler’а.

Проходит 8 месяцев, в репо Helm чарт (там большой umbrella chart с одной зависимостью в виде default chart) вижу MR, в котором добавлена возможность описать «сайдкар» для того самого сервиса «ебмеддинг». я слегка охуев от такой задумки, пошел разбираться че за хуйня.

Выяснилось: сервис «ембеддинг» не работает с Amqp, а идея была скейлиться на основе очереди, а значит был написан сервис адаптер на пайтоне, который читает очередь и отправляет запросы в ембеддинг. а работают они в одном поде, чтобы таким образом балансировать нагрузку.
Я в очередной раз ахуев, пошел смотреть что это за сервис такой у них, и тут оказалось что это модель с hugging face которая сервится через тулкит на Rust, который называется text embedding inference, в который просто посылают http запросы и который по сути обычный прикол из интернета third-party (по сути готовый inference server, а не наш бизнес-сервис), а его воткнули в в релизный цикл со всеми другими разрабатываеми сервисами.

Как же важно легкая осведомленность! Я взял Knative Serving, выкинул тот MR, добавил включение/выключение knative на описанном сервисе, перевел этот инференс на knative service, настроив масштабирование от нуля и все заработало. и внезапно задача, которая 8 месяцев обрастала адаптерами и сайдкарами, схлопнулась до нормального serverless HTTP-serving паттерна менее чем за сутки, а то и несколько часов.