JuanJo Ciarlante
Platform Engineer at Grafana Labs, Assistant Professor at University of Mendoza, Argentina.
Mendoza, Argentina
Actions
JuanJo Ciarlante is a Principal Engineer at GrafanaLabs and Assistant Professor at Mendoza Uni. His industry experience includes working for Google as SRE TL, as well as other SRE roles at Canonical Ltd, and Bitnami.
His OSS journey started in 1998 when he contributed IP Aliasing support to Linux, and since then to several other OSS projects. He's particularly passionate about Cloud-y OSS projects like Kubernetes, Prometheus, Grafana, etc which made cloud computing accessible for the rest of us.
Area of Expertise
Three Blind Spots, One Bill: The Kubernetes Cost Gap Nobody Owns
Your cloud bill is everyone's problem, but nobody's fault. Sound familiar? You’re stuck in a structural paradox where your teams stare at completely different slices of reality.
You watch developers tune pod usage. The catch? You know Kubernetes schedules based on requests, not usage. You see ops optimizing node utilization. Makes sense, but they lack the financial context to see what those nodes actually cost.
Then the Finance team knocks on your door. They see the CSP invoice. What they don’t see? Namespaces. Workloads. Teams. Unless you deploy granular, in-cluster attribution, FinOps physically cannot give feedback to the engineers causing the waste.
Three isolated roles. Three blind spots. And you're answering for an ever-growing bill.
In this talk, you’ll learn how to fix this. You'll walk away knowing how to build a Prometheus-based framework that translates tangled Kubernetes resources into the one language everyone finally understands: USD per minute.
Shaving the PromQL Yak: 6 PromQL Functions to Escape from Analytical Workarounds
Prometheus is great at storing metrics and answering the questions we already know how to ask. We all love that.
But when we need deeper analysis — “are these signals related?”, “is this trend unusual?”, “how long until we hit a threshold?” — things get awkward. We end up with huge PromQL queries, recording rules, external tools, or staring at two dashboards hoping the answer jumps out.
This talk explores six experimental PromQL functions designed to bring more analytical capabilities into Prometheus itself: correlation_over_time & regression_over_time, ewma_over_time, zscore & robust_zscore, time_to_threshold, and timeseries_gen.
We’ll explore where they help, where they don’t, and why timeseries_gen might be the moment I need a tomato shield ;).
All of these were vibecoded behind --enable-feature=promql-experimental-functions. Whether this is a practical exploration or a subtle attempt to get these functions accepted upstream… you’ll decide.
No Metal, No Problem: Cluster API + Tinkerbell Against Imaginary Machines
Hardware procurement runs on its own calendar, and it is not yours. Ours took months. The cluster did not wait: we pointed the whole provisioning pipeline at a pile of VMs and started making real mistakes early.
Not a simulation — the same path. Cluster API declares the cluster, CAPT claims a machine from the Tinkerbell inventory, Tinkerbell netboots it, images the disk and power-cycles it through a small BMC shim, and the Talos providers bootstrap the control plane. Nine nodes, three control-plane. From CAPI CR to ready cluster: 6-8 minutes, nobody touching a terminal. A bare-metal pipeline is testable long before it has anything to stand on.
We will cover why the Tinkerbell stack cannot be remote (L2 is L2), reaching an on-site API server from a cloud controller, Service LoadBalancer via Cilium BGP with no cloud LB, which parts of the state machine a VM cannot fake — and the CAPT Hardware-claim race we debugged, fixed and got merged upstream.
Game Over en la factura: jugando al Tetris de costos en Kubernetes
Este Pod está quemando CPU como un demonio, a aquel otro le explotó la memoria, y este de acá está durmiendo la siesta.
Mientras tanto, la factura de la nube se va... a las nubes 💸.
Medir y controlar costos en Kubernetes es un Tetris multi-dimensional donde las piezas no siempre encajan.
En esta charla vas a aprender de la experiencia de GrafanaLabs construyendo métricas con insights accionables que nos han permitieron controlar costos sin sacrificar rendimiento, y qué trampas evitar en el camino.
The Trials and Tribulations of Energy/Carbon Monitoring at Scale for Diverse Clusters and Workloads
From your own green soul, to reducing greenhouse gas emissions and contributing to organizational sustainability targets, crystal-ball says you will have to measure your clusters’ energy and carbon emissions sooner rather than later. Spoiler alert: it’s a journey and we’re starting it all together. Perhaps you've heard of Kepler, the eBPF/ML-based CNCF Project to monitor energy utilization in Kubernetes, promoted by the CNCF Environmental Sustainability TAG. There are several aspects you need to consider: How is energy utilization measured? What do the available metrics mean and how can they be used to produce useful real-world Prometheus queries and Grafana dashboards? And then… how can you map them to carbon emissions? What the heck is the Software Carbon Intensity specification? We’ve been staging Kepler in clusters with hundreds of workloads with diverse usage patterns, running in many node types and CSPs. We may be able to help you with these questions!
Building On-Prem Virtual Kubernetes Clusters as Cattle for Edu Environments on Top of Common Hardwar
It's relatively easy to provide a Cloud stack when you have a credit-card that can be used to pay monthly cloud provider bills. Not the case for many LATAM Universities with limited resources, where you may get a one-off allowance to purchase a bunch of mainstream PCs.
What started as a "what-if (these bunch of machines can be turned into ...)?" ended up being an on-prem solution to provide a Cloud Native computing platform for students to learn and experiment with Cloud-related topics in self-served, safe, isolated environments.
By stacking *K*ubernetes on metal, R*ook as storage layer, *O*pen*S*tack for virtualization, to then build virtual *K*ubernetes clusters on top, you can provide a Cloud computing infrastructure that can be used by students and teachers. We affectionately call it KROS*K ;-)
In this talk, you'll learn how these pieces can be plugged together: the good, the bad, and the ugly you may find along the way that, while you DIY. Lots of inception and fun ahead!
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top