Introducing autofission: automatic scaling limits for Fission.

Fission lets teams run small, on-demand programs called functions in a Kubernetes cluster. It can start more copies of a function when demand grows, but its upper limit is fixed in advance—even when the cluster has gained or lost available computing capacity. A low limit leaves machines idle; a high one may ask Kubernetes to start copies for which there is no room.

HPA and KEDA choose a replica count within a fixed maximum. Cluster Autoscaler and Karpenter add nodes. None calculates how far lower-priority Fission workloads may scale using capacity that already exists.

autofission is an open-source controller written in Python. A controller is a program that watches the cluster and keeps settings up to date. Autofission calculates each opted-in function’s MaxScale limit from the CPU, memory, and number of application copies that the cluster can currently accommodate. It includes a command-line interface, a container image, and Helm definitions for running continuously. The release is available on GitHub.

How the dynamic limit works🔗

Fission’s newdeploy executor creates a Deployment, Service, and HPA for each Function. The HPA decides how many replicas demand requires; Autofission estimates how many fit and writes that number to MaxScale.

Autofission evaluates CPU, memory, and Pod slots separately on every node. It does not combine spare CPU on one machine with spare memory on another. The calculation also includes Fission’s own overhead and replicas of the Function that are already running.

Autofission updates the Fission Function rather than its generated HPA. Concurrent edits fail instead of being overwritten, and the calculated maximum never falls below MinScale or one replica.

Opt-in behavior, priority, and limitations🔗

Only explicitly labelled newdeploy Functions are managed. Their Pods can use a low, non-preempting priority class, so lower-priority work gives way to more important workloads instead of evicting them.

Opting a Function in is an explicit Kubernetes operation:

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

Removing the label stops future updates to that Function.

The calculation uses declared resource requests, not current CPU or memory utilization. “Spare capacity” therefore means uncommitted scheduler capacity, not borrowed resources inside another workload’s reservation.

The calculation models CPU, memory, and Pod count—not every scheduler rule. Each Function is also evaluated independently, so simultaneous bursts may still overbook the cluster. The result is an estimate, not a reservation or proof of placement.

Related Kubernetes controls🔗

Kueue, Volcano, and Koordinator provide much richer queueing, fairness, and admission control. They are stronger when a cluster needs a new scheduling control plane. Autofission works through the Fission API and changes one upper bound.

The closest upstream analogue is cluster-capacity, which simulates how many copies of a Pod specification could be scheduled. Autofission adds continuous reconciliation for Fission Functions and Environments and writes the result to MaxScale.

This is useful for independent, lower-priority jobs that should use the remaining capacity of a shared cluster. Distributed analysis is one possible use case, but the controller remains general Fission infrastructure.