k8s-rabbit-pod-autoscaler

This autoscaler watched a RabbitMQ queue and adjusted the number of Kubernetes worker replicas according to the waiting messages. It was useful when processing demand arrived as queued jobs rather than a steady web-request rate. More workers could help reduce a backlog, provided the application and broker could support them. The archived implementation had specific assumptions about virtual hosts and scaling calculations, which need translation when choosing a replacement.

Current guidance

This is onfido/k8s-rabbit-pod-autoscaler, an archived script-based controller. Its README describes polling RabbitMQ, parsing an AUTOSCALING environment variable and changing Deployment replicas. It explicitly assumes the root RabbitMQ virtual host. That identifies a narrower implementation than a generic RabbitMQ autoscaling capability.

KEDA’s documented RabbitMQ scaler is an alternative to evaluate, not the same project. It supports distinct queue-length and rate-based modes, virtual-host selection and configurable authentication. Translate the old messages-per-pod-per-interval assumption into an explicitly chosen target and test the calculation against observed worker throughput.

Queue depth alone does not capture slow or stuck messages. Exercise acknowledgements, retries, a worker terminating mid-message and a temporary metrics failure. Give the scaler only the broker and Kubernetes permissions it requires, keep credentials out of public manifests, and set a deliberate minimum and maximum replica count. During migration, ensure only one autoscaler owns the Deployment. Validate empty-queue and sudden-backlog behavior before relying on the replacement to protect processing latency.