The WhiteFriday Engine is a reference environment for exploring application autoscaling, node provisioning and disruption. Its configuration and scripts provide a useful design to inspect. They do not establish that a cluster scaled to 10,000 ready pods in two minutes.
Separate the two scaling loops
The Horizontal Pod Autoscaler adjusts workload replicas from observed metrics. Node provisioning supplies capacity for pods that cannot be scheduled. Metric collection, controller decisions, cloud capacity, image pulls and readiness all contribute to the time before requests can be served.
A zero scale-up stabilization window does not make the entire chain instantaneous.
Choose the signal from the workload. CPU utilization may be useful for one service while queue age or another application signal better represents demand elsewhere.
Read the actual NodePool configuration
The repository's Spot NodePool uses an older v1beta1 API and eu-west-1 availability-zone names. It allows several ARM64 and AMD64 instance types and limits the pool's resources.
Before applying it to a current cluster, reconcile it with the installed CRDs and current Karpenter NodePool documentation. Validate the node-class reference, disruption fields, image architecture and regional availability.
Allowing more instance types can broaden capacity choices; it does not eliminate Spot shortages. Resource limits and cloud quotas also constrain growth.
Virtual users are not requests per second
The k6 script uses stages with virtual-user targets. k6's ramping-VU documentation explains that model.
Actual request rate depends on response time, requests per iteration and sleeps. A target of 100,000 virtual users is not evidence of 100,000 RPS, and a threshold in source is a desired condition rather than a passed result.
The reviewed script also contains an iterations_per_second threshold without defining that custom metric. Validate metric names and endpoint contracts before a trial. Begin with a small, authorized test environment and verify that the load generator is not the bottleneck.
Test user-visible recovery
Measure pending duration, time to ready replicas, error rate and successful business operations. A demo service using in-memory state cannot establish durable order handling across replica replacement.
PodDisruptionBudgets constrain supported voluntary evictions; they do not prevent every instance interruption or guarantee zero dropped requests. Test interruption, draining and retry behavior explicitly.
A spare-capacity buffer may reduce initial scheduling delay, but it has a cost and must fit the workload's placement requirements.
Report the experiment honestly
Record cluster versions, region, quotas, workload resources, image sizes, test duration and errors. Separate configured targets from achieved results.
That turns the blueprint into a reproducible scaling experiment while keeping its current status clear: inspectable source, with production-scale performance and resilience still requiring validation.
Sardar Mukhshaf
Full-Stack & DevOps Engineer
I build scalable web applications, secure backend systems, and production-ready cloud infrastructure. My engineering focus spans interface design, API architecture, deployment pipelines, and observability. Follow for more deep dives into system architecture, performance engineering, and emerging technologies.
More from the practice
Keep the useful ideas close.
Follow new articles with your preferred RSS reader.
Open the RSS feed ↗
