Install

Mon, 01 Jan 0001 00:00:00 +0000

workload-resizer ships as two manifests on each GitHub Release:

install.yaml — controller Deployment, RBAC, and the workload-resizer-system namespace, with the image pinned to the release tag.
config.yaml — a sample ConfigMap with the schema and example GKE node-type performance units.

Both are needed. Apply config.yaml first — it carries the workload-resizer-system namespace and the required ConfigMap, so the controller pod (created by install.yaml) finds what it needs already in place. Reverse the order and the controller pod fails fast on startup (manager exits with initial config load: configmaps ... not found, kubelet drops it into CrashLoopBackOff); it’ll recover once the ConfigMap is applied, but only after the kubelet’s restart backoff. Once the ConfigMap exists at runtime and is later deleted, the controller keeps using the last-known config and logs the refresh failure every 30s (--config-refresh-interval).

How it works

Mon, 01 Jan 0001 00:00:00 +0000

The problem

Deployment authors set CPU / memory requests calibrated for a specific machine family. When the cluster has a heterogeneous node pool — say n2d alongside the newer, ~25% more powerful n4 — pods that land on the more powerful nodes over-provision their requests for the actual work being done. The classic fix is the Vertical Pod Autoscaler, but VPA recreates pods and reasons about utilization over time. workload-resizer does something narrower: when a pod is scheduled, look at where it landed and patch its requests right there, with a known performance-unit ratio, no restart.