Flux The Cloud Kubernetes Cost Optimization
Powered by inovative features

Workloads not serving traffic consume no compute. Pods are removed from nodes entirely, which also reduces node count when the cluster autoscaler consolidates freed capacity. Savings compound.

When a request arrives for a scaled-down workload, the scaler detects the signal and scales back up before the request times out. Most services are ready in under 30 seconds.

For latency-sensitive services that cannot tolerate cold-start delay, Scale-to-One keeps a single replica running at all times — saving 50–80% while eliminating cold-start entirely.

Monitoring agents, production workloads, and service meshes must remain running. Exclusion lists at both namespace and service level ensure nothing critical is touched.

30 minutes for interactive dev environments, 2–4 hours for batch pipelines. The timer resets on any detected activity, so workloads with rare but real usage are never prematurely scaled.

Every scale event is recorded: workload, direction, timestamp, and idle duration. Available in the UI and via API for cost reporting workflows.

Scale up before demand arrives. Your workloads never experience scheduling latency from waiting for a new node to join the cluster during a planned traffic ramp.

At the end of the working day, scale to minimum footprint immediately — no cooldown hesitation. A 10-node to 2-node reduction overnight saves 80% of nightly compute cost.

Each schedule specifies the instance type and capacity type. Run on-demand during business hours for reliability; switch to spot overnight to stack two savings mechanisms simultaneously.

A weekday business-hours schedule, a Saturday maintenance schedule, a Sunday zero-capacity schedule, and holiday overrides — all composing together without conflict.

Target specific days of the week, a calendar date range, or a 24/7 baseline — covering sprint cycles, reporting periods, planned maintenance, and seasonal patterns without manual intervention.

Every scheduled scaling action is logged with name, timing, target configuration, and outcome. Queryable from the UI and API.

Without automated scaling, clusters are sized for peak load permanently. The autoscaler matches node count to actual workload at every point — the cloud bill curves with usage rather than sitting flat at peak provisioning.

Four parameters let you tune the tradeoff between aggressive cost savings and protection against premature removal: unneeded time, post-add delay, scan interval, and utilisation threshold.

Distinguishes between pods waiting for genuine capacity and pods temporarily unscheduled due to normal scheduling lag. Only genuine shortages trigger scale-up — preventing unnecessary node additions.

Every node addition and removal is recorded with reason, count before/after, and timestamp. Available as a chart and event table in the UI, and via API for incident analysis.

Scale-down events produce quantified savings; scale-up events record their cost. The financial effect of autoscaler behaviour is transparent and measurable, not just an assumed benefit.

The scheduler handles predictable patterns; the autoscaler handles variance within those windows. Together they are more efficient than either feature alone.

Monitors actual CPU and memory consumption and computes P50/P95/P99 distributions. Recommendations account for both normal operation and peak periods without over-provisioning for absolute outliers.

Analyses historical replica counts alongside request rates to find the minimum replica count that keeps latency within bounds, and a maximum that represents a realistic ceiling — not a feared upper limit.

For every workload, a forecast of future resource needs is surfaced in the UI before any change is applied. You review the model's projection and validate it against upcoming traffic before approving.

Before any recommendation is applied, run a full dry-run that shows exactly what would change: every workload's current config, the recommended replacement, and the projected impact.

Changes are applied progressively. If the workload shows resource pressure — OOMKill events, throttling, error rate increase — the change is automatically rolled back. No manual monitoring required per workload.

Workloads with intentionally conservative resource requests — for compliance, SLA, or contractual reasons — can be protected while the rest of the cluster benefits from continuous optimisation.

Two lines: actual spend and what spend would have been without optimisation. The widening gap is your saving. As the divergence grows over time, you see the compounding effect of continuous optimisation.

1 day, 7 days, 15 days, 30 days, since start of month, or since start of year. Matches the reporting cadence of engineering standups, monthly cost reviews, and quarterly business reviews.

Day-by-day breakdown: baseline cost, actual cost, saving. Identify specific days where cost spiked unexpectedly, validate scheduled scale-downs, produce raw data for chargeback conversations.

Every optimisation action logged with: which feature triggered it, which resource was affected, what action was taken, when, cost impact, and duration. Complete record for compliance, change management, or internal audit.

Full savings dataset and audit log exported to CSV at any time. Imports directly into Excel, Google Sheets, or your BI tool. Use for board reporting, finance reconciliation, or external cost platform integration.

What the Workload Scaler contributed, what Node Scheduler windows saved, what HPA right-sizing freed up. Each component's saving is attributed separately so you know where the value is coming from.

PDBs are created, updated, and deleted automatically as workloads are deployed, scaled, and removed. No manual PDB management. No PDBs left behind when workloads are deleted.

When a workload has an HPA, the operator uses effective replica count — the worst-case minimum the HPA could scale to — rather than the current count. A deployment at 5 replicas with an HPA minimum of 1 is treated as a single-replica workload for PDB purposes.

Automatically detects database StatefulSets (PostgreSQL, MySQL, MongoDB, Redis, Kafka, etcd, and more) by inspecting labels and workload names. Database workloads receive quorum-based PDBs: minAvailable = (n/2) + 1.

Single-replica workloads with preScale policy are automatically scaled 1→2 before a drain, held until the new pod is Ready on a different node, then scaled back 2→1 after the drain completes. Zero downtime, fully automatic.

Workloads in critical namespaces or flagged as critical receive stricter PDB values automatically — higher minAvailable floors and lower maxUnavailable ceilings — without any manual annotation.

PDBs whose corresponding workload no longer exists are automatically removed each reconciliation cycle, keeping the cluster clean and preventing stale PDBs from blocking future drain operations.

Evaluates the full AWS and Azure instance catalogs to find the combination of sizes and families that best matches your actual workload profile. Larger, more expensive types are replaced where smaller ones are sufficient.

Calculates the right mix — enough on-demand nodes to keep critical workloads running, enough spot to maximise savings — and maintains that balance automatically, including recovery after spot interruptions.

When a spot node is reclaimed by the cloud provider, the engine responds without human intervention: it temporarily scales up on-demand capacity to absorb displaced workloads, finds new spot capacity, then restores the original mixed setup and releases the temporary nodes.

Distinguishes between pods waiting due to genuine capacity shortage and those experiencing normal scheduling lag. Only true shortages trigger a scale-up, preventing unnecessary node additions from transient states.

Every recommendation surfaces as a side-by-side view: current cluster composition and cost vs. recommended composition and projected cost. Nothing is applied until you review and approve — or until auto-apply triggers after passing all safety gates.

Recommendations below 70% model confidence are never auto-applied. Recommendations projecting less than your configured savings threshold are surfaced for review but not executed automatically.

Builds a P50/P95/P99 consumption model per workload from 30 days of real telemetry. Provisioning decisions are based on actual behaviour, not YAML declarations written months ago.

Selects instance types that minimise wasted capacity across the node pool — fitting more workloads onto fewer nodes without increasing scheduling failure rate or application latency.

Places workloads across availability zones and failure domains to satisfy topology spread constraints without requiring manual affinity rules on every deployment.

Maintains a configurable headroom of warm capacity that absorbs burst traffic without waiting for a node to spin up — keeping P99 latency stable during sudden load increases.

When the cluster becomes fragmented over time — a natural result of rolling deployments and partial scale-downs — the provisioner gradually rebalances workloads without evictions or downtime.

Tracks pending-pod root causes and resolves them before they become incidents. Fragmentation, incorrect resource requests, and topology mismatches are all surfaced and corrected automatically.

Continuously compares each node's CPU, memory, and network I/O against its historical baseline and against peer nodes in the same node group. Nodes with abnormal consumption patterns are flagged immediately.

Tracks cpu_throttled_seconds_total per container. Workloads that are consistently throttled receive a recommendation to increase CPU limits — resolving silent performance degradation that never appears in standard dashboards.

Detects nodes approaching the OOM threshold before the kubelet starts evicting pods. Alerts fire with enough lead time to either migrate workloads or add capacity before any pod is killed.

Identifies workloads whose resource consumption negatively affects co-located pods. Provides actionable recommendations: move the workload to a dedicated node pool, adjust limits, or apply CPU pinning.

Ranks namespaces by their resource pressure score — a composite of CPU/memory utilisation relative to limits, throttle rate, and eviction history. High-pressure namespaces are surfaced for review before they cause incidents.

Distinguishes between a sudden anomalous spike (likely a runaway process or a traffic incident) and a gradual upward trend (likely organic growth that needs capacity planning). Each gets a different response playbook.