Представляем autofission: автоматические пределы масштабирования Fission.

Fission позволяет запускать в Kubernetes небольшие программы по запросу — функции. Когда нагрузка растёт, Fission создаёт дополнительные копии функции, но их максимальное число задаётся заранее, даже если свободные ресурсы кластера меняются. Слишком низкий предел оставляет машины без работы, а слишком высокий просит Kubernetes запустить больше копий, чем может поместиться.

HPA и KEDA выбирают число копий в пределах фиксированного максимума. Cluster Autoscaler и Karpenter добавляют машины в кластер. Ни один из них не вычисляет, насколько можно масштабировать менее приоритетные задачи Fission на уже имеющихся ресурсах.

autofission — открытый контроллер, написанный на Python. Контроллер — это программа, которая следит за кластером и поддерживает его настройки в актуальном состоянии. Autofission вычисляет для каждой подключённой функции предел MaxScale по доступным процессорным ресурсам, памяти и числу копий приложений, которые сейчас помещаются в кластере. В проект входят интерфейс командной строки, контейнер и Helm-описания для непрерывной работы. Релиз доступен на GitHub.

Как работает динамический предел🔗

Исполнитель Fission newdeploy создаёт для каждой функции стандартные объекты Kubernetes: Deployment, Service и HPA. HPA определяет, сколько копий требует текущая нагрузка, а Autofission оценивает, сколько из них поместится, и записывает это число в MaxScale.

Autofission считает процессорные ресурсы, память и места для запуска приложений отдельно на каждой машине кластера. Он не складывает свободный процессор одной машины с памятью другой. Расчёт также учитывает накладные расходы Fission и уже работающие копии функции.

Autofission обновляет сам объект функции Fission, а не созданный для него HPA. Одновременное редактирование завершается явным конфликтом вместо незаметной перезаписи, а вычисленный максимум не опускается ниже MinScale или одной копии.

Подключение, приоритет и ограничения🔗

Управление включается явно и только для функций с исполнителем newdeploy. Их запускаемые копии могут иметь низкий приоритет без вытеснения: такая работа уступает ресурсы более важным задачам, но не прерывает их.

Подключение функции — явная операция Kubernetes:

kubectl label function hello \
  --namespace fission-function \
  autoscaling.fission.io/cluster-capacity=true

После удаления метки Autofission перестаёт обновлять эту функцию.

Расчёт использует ресурсы, заранее запрошенные приложениями, а не их текущую загрузку процессора и памяти. Поэтому «свободная ёмкость» здесь означает ресурсы, ещё не обещанные другим приложениям.

Расчёт учитывает процессор, память и число запускаемых копий, но не все правила планировщика Kubernetes. Каждая функция также оценивается независимо, поэтому одновременные всплески могут перегрузить кластер. Результат — оценка, а не резервирование ресурсов или гарантия размещения.

Связанные механизмы Kubernetes🔗

Kueue, Volcano и Koordinator предлагают гораздо более развитые очереди, справедливое распределение и правила допуска задач. Они лучше подходят, когда кластеру нужен новый слой планирования. Autofission работает через API Fission и меняет только одну верхнюю границу.

Ближайший аналог из экосистемы Kubernetes — cluster-capacity, который оценивает, сколько копий заданного приложения можно разместить. Autofission выполняет такой расчёт постоянно для функций и окружений Fission и записывает результат в MaxScale.

Это подходит для независимых одноразовых задач, которые должны использовать оставшуюся ёмкость общего кластера. Распределённый анализ — один из возможных сценариев, но сам контроллер остаётся общей инфраструктурой Fission.