A node autoscaler project for Proxmox allowing a Kubernetes cluster to dynamically scale across a Proxmox cluster.

• Polls for unschedulable pods
• Assesses the resource requirements from the requests of the unschedulable pods
• Provisions VMs from a user defined template
• User configurable cpu, memory and ssh key for provisioned VMs
• Removes nodes when requested resources can be satisfied by few VMs

The operator is required to create a Proxmox template configured to join the kubernetes cluster automatically on it's first boot. All examples show how to do this with K3S, however other kubernetes cluster flavours theoretically could be used if you are prepared to put in the work to build an appropriate template.

While it is a pretty niche project, some possible use cases include:

• Providing overflow capacity for a raspberry Pi cluster
• Running multiple k8s clusters each with fluctuating loads on a single proxmox cluster
• Something someone else thinks of that I haven't
• Just because...

See here for example setup scripts and configuration.

Kproximate polls the kubernetes cluster by default every 10 seconds. If this value is set to below 10 seconds it will be ignored and the default will be used.

Important
Scaling is calculated based on pod requests. Resource requests must be set for all pods in the cluster which are not fixed to control plane nodes else the cluster may be left with continually pending pods.

Kproximate will scale upwards as fast as it can provision VMs in the cluster. As soon as an unschedulable pod is found kproximate will assess the resource requirements and provision Proxmox VMs in order to satisfy them.

Scaling events are asyncronous so if new resources requests are found on the cluster while a scaling event is in progress then an additional scaling event will be triggered if the initial scaling event will not be able to satisfy the new resource requests.

Scaling down is very agressive. When the cluster is not scaling and the cluster's load is calculated to be satisfiable by n-1 node while also being able to remain within the configured load headroom value, a negative scale event is triggered. The node with the least allocated resources is selected and all pods are evicted from it before it is removed from the cluster and deleted.