kubernetes-webhook-autoscaler

A team with its own machine-provisioning system may need Kubernetes to request more capacity without directly controlling the infrastructure. Kubernetes Webhook Autoscaler provided that connection: it detected a need to scale and sent an HTTP callback to a service responsible for adding or removing nodes. The receiving service performed the infrastructure work. It concerned the number of worker machines, rather than the number of application copies running on them.

Current guidance

The wbuchwalter/kubernetes-webhook-autoscaler project separates a Kubernetes-side decision component from an external webhook receiver that provisions or removes nodes. Its documented payload includes current and desired counts and, for scale-down, selected node names. It is node-capacity automation, not a pod Horizontal Pod Autoscaler.

Identify who owns the receiver and how it authenticates requests before adoption. A successful HTTP response is not proof that usable capacity appeared. Make provisioning idempotent, bound minimum and maximum capacity, and handle duplicate, delayed or out-of-order requests without repeatedly buying or deleting nodes.

Review node-pool selection and exclusions so control-plane or unrelated nodes cannot be selected. Check how draining completes, how failed infrastructure operations are reconciled and how desired state is observed after controller restart. Exercise pending workloads and a webhook outage in an isolated pool. The original source documents the interface, but this review did not establish a current release/support matrix or a verified official successor. Treat legacy examples as a contract to inspect rather than an endorsed modern cloud integration.