energy, by 2040, we are supposed to hit the world’s energy production capacity.The increase in compute energy and demand has been increasing at a much faster rate than the world energy production capacity increase” https://climate.mit.edu/posts/how-can-we-reduce-carbon-footprint-global-computing - Bilge Yildiz Breene M. Kerr Professor in the MIT departments of Nuclear Science and Engineering and Materials Science and Engineering
a way to estimate power consumption at the process, container, and Kubernetes pod levels. • Kepler provides granular power consumption data for Kubernetes Pods and Nodes. • It uses eBPF to collect energy-related system stats and export them. • RAPL and ACPI when available or trained models for specific hardware otherwise. • Kepler was accepted to CNCF on May 17, 2023 and is at the Sandbox project maturity level. Kepler
1 connection • Alternating CronJobs every ½ hours • 20 mins each • KNative max scale: 6 Results • E(serverless) > E(serverfull) • Knative adds idle power consumption • Serverless overhead comes from knative-serving namespace • E(knative-serving) ~ E(serverless-ns) • Mesh negligible idle power consumption • Contributions (CORE, UNCORE, PKG…) to total energy are similar in both cases • Results constant over time
E(plain) • Istio sidecar adds a 2.5x factor in consumption to the mock • Added “plain” setup • HTTP/2, 2000 RPS over 1 connection • Alternating CronJobs every 20 mins • 20 mins each
the load? ◦ Updating containerConcurrency: 8 to prevent errors ◦ 4000 RPS • What if we tune stuff? Maybe it’s the burst capacity! ◦ Burst-capacity default ◦ Go back to HTTP/2, 2000 RPS over 1 connection and concurrency 8
> E(serverfull) > E(plain) • Similar ratios apply • Tuning burst capacity does not seem to affect • What if we double the load? ◦ Updating containerConcurrency: 8 to prevent errors ◦ 4000 RPS • What if we tune stuff? ◦ Burst-capacity default ◦ Go back to HTTP/2, 2000 RPS over 1 connection and concurrency 8
E(plain) • Knative-serving contribution is negligible when processing work at low rates • In this type of situations, serverless can be very powerful! • Added actual work • HTTP/2, 6 RPS over 1 connection
Knative or others) • There’s a ~constant overhead in power consumption when deploying background systems like knative ◦ Energy vs traffic rate is not linear: E(6 RPS) <<< E(4000 RPS) ◦ That’s why it’s important to measure! • What your application is doing matters → both idle and under load • One size does not fit all: You can now measure your best setup to ◦ Save power, money or both ◦ Provision accordingly
kdubois
lycorp_recruit_jp
lycorptech_jp
hakubishin3
.png){kind=icon}
pharma_x_tech
oniak3ibm
bitkey
twada
mochizuki875
rokuosan
muziyoshiz
aiandrox
michaelherold
marcelosomers
mraible
aarron
eileencodes
andyhume
chriscoyier
sergeychernyshev
swwweet
bkeepers
garrettdimon
![@kevindubois Thanks! youtube.com/@thekevindubois linkedin.com/in/kevindubois github.com/kdubois @kevindubois.com @[email protected]](https://files.speakerdeck.com/presentations/8445c3e50b79486292deef0a4c130591/slide_43.jpg){kind=link}