4 ms·
Show HN: SpotVortex helps SRE teams push more Kubernetes capacity onto Spot
I built SpotVortex for a simple reason: most teams want more Spot savings, but they do not want to compromise service safety to get them.
SpotVortex runs inside the cluster and controls Spot at the node-pool level. It watches market risk and pool health, then decides when a pool should grow, spot, hold, freeze, or move back toward On-Demand.
A few concrete details about the shipped runtime:
* The deterministic mode is the active path
* The control cadence is 10 minutes
* Decisions stay at the node-pool level, not the pod level
* Workload data stays in-cluster.
The controller also looks at pool blast radius, not just price. It tracks things like:
* PDB Slack under node loss
* How much critical workload is sitting on the Spot restart and recovery time
* Stateful workload mix
* zone spread
* evictability
* available On-Demand headroom
* Current AWS support is explicit. The shipped model scope covers 60 instance families across:
compute: c5, c6, c7
general purpose: m5, m6, m7
memory optimized: r5, r6, r7
burstable: t2, t3, t4g
Happy to answer hard questions.
- softcane 7mo agoWe kept decisions at the node-pool level and focused on operational safety signals like PDB slack, critical workload concentration, restart time, evictability, zone spread, and On-Demand headroom. If you want to push on safety, failure modes, rollout, or supported AWS scope, those are the right questions.
- softcane 7mo agohttps://github.com/softcane/spot-vortex-agent https://github.com/softcane/spot-vortex-agent