ENERGY AND CARBON METHODOLOGY
How GreenKube estimates Kubernetes energy and carbon.
GreenKube combines CPU telemetry and Kubernetes context with instance power profiles, grid-intensity data and facility PUE. It estimates node energy and operational CO₂e, allocates results to workloads and can include a separate embodied-impact estimate.
Method overview
From telemetry to workload estimates.
The methodology follows three steps: estimate node energy from CPU utilization and an instance power profile; apply grid intensity and PUE to calculate operational CO₂e; then allocate results across workloads. Optional Boavizta data supplies a separate embodied-impact component.
Prometheus provides CPU utilization, while Kubernetes node and pod metadata supply the context used for instance profiles and workload allocation.
Operational and embodied impacts are calculated separately. OpenCost supplies a distinct cost-allocation view alongside the energy and carbon estimates.
Data sources
Inputs that build the estimate.
Prometheus CPU telemetry and Kubernetes metadata anchor the operational model. Grid-intensity providers, instance profiles and PUE add geographic and facility context. Boavizta can provide lifecycle data, while OpenCost supports separate cost allocation. The table summarizes source roles and documented availability and fallback behavior.
| Source | Role in the methodology | Availability and fallback | Coverage and assumptions |
|---|---|---|---|
| Prometheus | CPU utilization is the activity input to the operational-energy model. Other metrics may be collected but do not enter that calculation. | Coverage depends on the configured scrape data and selected time window. Defaults used by the model are marked estimated with reasons. | Sampling gaps affect the input coverage; CPU utilization is used to estimate power from an instance profile. |
| Kubernetes API | Node metadata and pod specifications provide workload and instance context for estimates and allocation. | Missing or unsupported context can limit attribution; consult the documentation for supported fields. | Shared nodes and incomplete ownership affect how node-level results are allocated. |
| Electricity Maps | Default grid-intensity provider for location- and time-dependent carbon factors. | If provider data is unavailable, documented per-zone defaults are used; the global fallback is 500 gCO₂e/kWh when no zone default exists. | Results depend on zone mapping and data freshness; a regional factor can differ from the electricity used at a particular facility. |
| Wattnet | Optional alternative grid-intensity provider documented for 52 European zones at 15-minute resolution. | Provider selection and credentials are configuration-dependent; use the documented fallback behavior if data is unavailable. | Its documented geographic coverage, temporal resolution and method differ from other providers. |
| Built-in CCF profiles and PUE | Static instance power profiles inform the CPU model; provider PUE profiles represent facility overhead. | For an unknown instance, documented fallback values are PUE 1.3, 1 vCore, 1 W/vCore minimum and 10 W/vCore maximum. The result is marked estimated. | Profiles approximate instance power; PUE profiles are provider-specific inputs. |
| Boavizta API | Optional instance lifecycle/embodied-impact input; results are cached and kept separate from operational energy. | When instance data is unavailable, the documented fallback is 100 kg embodied impact with a 4-year hardware lifespan assumption. | Coverage and the lifespan and allocation assumptions shape the embodied-impact estimate. |
| OpenCost | Cost-allocation input for cost visibility, separate from the energy and carbon equations. | When OpenCost data is unavailable, the documented behavior can report a cost value of zero. | Shared costs and allocation rules differ from provider billing. |
Operational-energy model
Estimating node energy from CPU utilization.
For each node, the model linearly interpolates between idle and maximum power in its instance profile using CPU utilization. It multiplies estimated power by the observation window to calculate energy, then allocates the node estimate across workloads by CPU share.
| Step | Calculation | Interpretation |
|---|---|---|
| Idle and maximum power | P_idle = min_watts × vCPUs; P_max = max_watts × vCPUs | The profile values are per-vCPU estimates for the instance type or configured fallback. |
| Node power | P_node = P_idle + (P_max − P_idle) × U | U is the CPU utilization ratio from 0 to 1; linear interpolation is an approximation. |
| Node energy over time | E_node = P_node × duration_seconds | The result is energy in joules for the selected observation window. |
| Pod allocation | E_pod = (cpu_pod / cpu_total_node) × E_node | Distributes estimated node energy across workloads by CPU usage share. |
Grid intensity and facility PUE are applied to the energy estimate in the next step to calculate operational CO₂e.
Carbon calculation
Converting energy into operational CO₂e.
Operational CO₂e combines modeled energy with grid intensity and facility PUE. When Boavizta data is available, the optional embodied-impact estimate is calculated separately and included in the combined value.
| Component | Documented calculation | How to read it |
|---|---|---|
| Operational CO₂e | CO₂e_g = E_joules / 3,600,000 × intensity_gCO₂e_per_kWh × PUE | Uses estimated energy, the configured or documented fallback intensity factor, and the PUE profile. |
| Embodied impact | (GWP_kg × 1,000 / lifespan_hours) × (pod_duration_seconds / 3,600) × (pod_CPU_cores / node_CPU_cores) | Uses Boavizta instance data where available; the documented fallback is 100 kg GWP and a 4-year lifespan. |
| Combined total | Operational estimate plus embodied estimate where the latter is available | Adds the embodied-impact estimate when it is available. |
Provider PUE profiles supply the facility-overhead factor used in the operational calculation.
Aggregation
How the inputs become reported estimates.
Configured telemetry and provider inputs feed the node-energy model, carbon calculation and workload allocation. The cost-allocation path remains separate.
Prometheus telemetry + Kubernetes context
CCF instance profile + provider PUE
Electricity Maps / Wattnet grid intensity
Boavizta embodied data where available
↓
Normalize available inputs
↓
Estimate node energy / CO₂e
↓
Allocate to workloads
OpenCost → separate cost allocation
CPU utilization and instance profiles produce estimated energy. Grid intensity and PUE convert that result to operational CO₂e; optional Boavizta inputs add embodied impact. Kubernetes context and CPU share support workload allocation, while OpenCost supplies a separate cost view.
The source table lists documented availability and fallback behavior. The technical references below explain source configuration and implementation details.
Fallback behavior
How unavailable inputs are handled.
Each supported input has a documented fallback or missing-data behavior. The configured provider and estimation reasons identify which path contributed to a result.
- 01
Grid-intensity fallback
If the grid-intensity API is unavailable, GreenKube uses a built-in per-zone default; if no zone value exists, the documented global fallback is 500 gCO₂e/kWh.
- 02
Unknown instance profile
The documented defaults are PUE 1.3, 1 vCore, 1 W/vCore minimum and 10 W/vCore maximum. Metrics are flagged is_estimated with estimation_reasons.
- 03
Missing embodied-impact data
The documented Boavizta fallback is 100 kg embodied impact per instance with a 4-year hardware lifespan assumption; the result remains modelled.
- 04
Missing cost allocation
When OpenCost data is unavailable, the documented behavior can report a cost value of zero; check data availability before interpreting that value.
Example calculation
A worked calculation with documented fallback values.
This example combines the documented unknown-instance profile, PUE 1.3 and global intensity of 500 gCO₂e/kWh with 50% CPU utilization for one hour to show the calculation.
| Step | Inputs | Result |
|---|---|---|
| Estimated node power | 1 W + (10 W − 1 W) × 0.5 | 5.5 W |
| Energy for one hour | 5.5 W × 3,600 seconds | 19,800 J = 0.0055 kWh |
| Operational CO₂e estimate | 0.0055 kWh × 500 gCO₂e/kWh × 1.3 PUE | 3.575 gCO₂e for the modelled node window |
The operational result is 3.575 gCO₂e for the example node window. It excludes embodied impact; workload-level values are allocated from node energy by CPU share.
Technical references
Explore the implementation details.
The technical documentation describes the equations, supported sources, provider setup and fallback behavior behind the calculations on this page.
Use these references to inspect implementation behavior and configure the sources used by a deployment.
Limitations
What the estimates cover—and where they stop.
These boundaries describe the model inputs and how to interpret a reported value alongside its source coverage.
CPU-based energy model
Node energy is estimated by interpolating CPU utilization between an instance profile’s idle and maximum values. This is not a direct power reading from hardware, a node, container or pod; memory, network, disk and GPU do not enter the current energy calculation.
Workload allocation
Workload energy and CO₂e are allocated from node estimates using CPU share. Shared infrastructure, incomplete ownership, scrape gaps, profile assumptions, source freshness, location mapping and PUE affect the result.
Grid-intensity sources
Provider data and documented fallbacks do not represent the exact electricity mix at a facility. Wattnet documents 52 European zones at 15-minute resolution; other providers differ in coverage, freshness and method. A missing source does not mean zero energy or emissions.
Instance profiles and PUE
Instance profiles approximate power and provider PUE profiles supply facility overhead. The documentation currently lists conflicting OVH PUE values in separate sections, so this page does not assert one OVH-specific value.
Embodied-impact estimate
The optional component uses Boavizta instance data or its documented 100 kg / four-year fallback. It is not a complete inventory of every cloud service, lifecycle stage or organizational emission.
Costs and observed outcomes
OpenCost is a separate cost-allocation input; when its data is unavailable, a cost value may appear as zero. A projected reduction does not establish lower electricity use or realized savings: compare post-change signals and reconcile costs with provider billing.