GreenOps

Carbon-aware scaling is easy for batch and stateless workloads, which is where most tooling points. Stream processors are the awkward case: stop one carelessly and you throw away in-flight windowed state and break exactly-once processing. GreenOps handles that case. It watches grid carbon intensity, and when the grid turns dirty it suspends the Flink job, but only after its state has been safely captured to a savepoint.

The rule the whole system is built around: a job is never suspended unless its state is safely captured first. A failed or timed-out savepoint aborts the suspension and leaves the cluster running. Suspension goes through the FlinkDeployment rather than scaling the Deployment directly, because the Flink operator owns that Deployment and will undo any replica change made behind its back.

• Custom CRD and operator reconciling every 60 seconds: patches FlinkDeployment state to suspended, lets the Flink operator take a savepoint, then resumes from that savepoint path on a clean grid.
• Three scheduling policies: threshold, forecast (declines dirty windows too short to pay for the savepoint and restart), and optimising (prefers the jobs avoiding most carbon per second of disruption under a concurrency cap).
• Replayed over fourteen days of a simulated grid curve, the forecast policy kept 92% of the carbon saving for one-seventh of the suspensions and zero wasted ones.
• Self-calibrating cost prediction: the operator times its own suspends and restarts and keeps a rolling history, moving from static constants to observed percentiles to ridge regression on state size and parallelism as evidence accumulates.
• Ships as a Helm chart with a one-command local environment: Minikube, MinIO, the Flink operator, a sample job and the full monitoring stack.