Let’s Embrace Green Cloud-Native Engineering

Over the past decade, our society has become increasingly reliant on software. Companies across the globe are developing software not only to enhance value for their employees but also to serve their customers better. However, a significant portion of this software ultimately resides in data centers—either managed by the organization itself or by cloud providers. Unfortunately, this trend contributes to a staggering 3% of the global carbon footprint.
Recently, a critical shift has occurred: the proliferation of AI and ML workloads is driving enterprises to deploy larger and more resource-intensive applications in our data centers. As a result, the carbon footprint associated with data centers is growing by 2% annually due to AI-related demands. If we fail to transform our cloud-native culture, this trajectory could lead to data centers consuming a whopping 15% of the global carbon footprint, surpassing even the airline industry.
In this enlightening talk, we will explore solutions that allow us to optimize our environment and reduce unnecessary workloads. To enhance the energy efficiency of our Kubernetes (k8s) clusters, we must:
1. Measure and Understand Current Usage: Gain insights into how our environment consumes resources.
2. Use Energy Usage as a Global KPI: Prioritize energy efficiency across all our projects.
3. Dismantle Testing Environments When Not in Use: Avoid unnecessary resource consumption.
4. Continuously Optimize Resource Allocation for k8s Workloads: Fine-tune our cluster for efficiency.
During this session, we’ll also introduce several valuable CNCF projects, including Kepler, KubeGreen, and Vcluster. Let’s collectively shape a greener future for cloud-native engineering! 🌿🚀

This presentation will be structured into several parts:
- Introduction to data center consumption
- Measuring consumption with Kepler
- Validating your releases using Kepler in your quality gates
- Optimizing your clusters
- Shutting down your test environments: Kubegreen
- Demonstration

Here is a GitHub repository containing the workshop with some of the resources: https://github.com/henrikrexed/Sustainability-workshop

Talk/demo conducted during Sustainability Week: https://youtu.be/qthk0dbzFMk https://www.youtube.com/isitobservable

Talk at KubeCon Europe: https://www.youtube.com/watch?v=ykq1F_3PmJw

Return of the Mesh: Gateway API's Epic Quest for Unity

Service Mesh technology revolutionizes networking, security, and observability. Yet, the CNCF landscape reveals a crowded field with overlapping solutions. In the Service Mesh space, options abound—Istio, Kuma, Linkerd, Traefik Mesh, and the promising Ambient Mesh.
Each Service Mesh demands mastery of unique Custom Resource Definitions (CRDs), complicating transitions. Enter the Gateway API (GAMA) initiative, a beacon of hope promising standardized CRDs for Ingress, routing, and Service Mesh management. But does it truly deliver a unified configuration across diverse Service Meshes?
This talk offers a community feedback loop, evaluating how each solution supports the Gateway API. We'll configure meshes using HTTPRoute and GRPCRoute, spotlighting areas needing custom tweaks. Plus, we'll benchmark performance across solutions, providing actionable insights for your Service Mesh journey.

Observability in the Matrix: Choosing the Right AI Agent to Escape the Chaos

In a world flooded with metrics, logs, and traces does AI-driven observability help us escape the chaos, or does it simply build a more sophisticated illusion? You wake up in a Kubernetes cluster that seems fine until latency spikes, noisy logs, and missing traces reveal the truth: you're in the Observability Matrix. In this talk, we’ll guide you through five AI-powered agents: HolmesGPT, Kagent, Opni, K8sGPT, and Monte Carlo; each offering a different pill to help you escape the chaos. Like Neo choosing between red and blue, you’ll learn how these tools uncover root causes, enrich signals, reduce alert fatigue, and trace the behavior of autonomous agents. But beware: not all AI is your ally. We’ll explore the promises and pitfalls of AI-driven observability, and how to avoid being trapped in a false sense of insight. Join us for a journey through the Matrix of metrics, logs, and traces—and leave with the knowledge to choose your observability destiny.

Telemetry Showdown: Fluent Bit vs. OpenTelemetry Collector - A Comprehensive Benchmark Analysis

In a push to standardize observability practices, the cloud-native community has embraced OpenTelemetry, offering a unified framework for metrics, logs, and traces. Prior to this, log processing relied on agents like fluent, evolving into fluentbit. With fluentbit's recent expansion to support additional signals and the OpenTelemetry Collector's emergence, a pertinent question arises: Which is the superior choice for performance?

This session delves into:
- Unveiling the distinctions between Fluent Bit and the OpenTelemetry Collector.
- Sharing the findings derived from a series of benchmark tests.
- Providing valuable insights to empower the community in selecting the most fitting agent for their cloud-native environments.

Pimp My Traces

Starting an observability journey is exciting—those first traces and metrics unlock valuable insights. But scaling to production often brings cost challenges, especially with distributed tracing, where strategic sampling is key to balancing visibility and expense.

In this session, we’ll share techniques how to pimp your traces using the OpenTelemetry Collector:

- Tail-Based Sampling & Filters: Capture critical errors and behaviors without unnecessary data.
- Spanmetrics Connector: Gain precise response time metrics for sharper analysis.
- Structured Event Conversion: Transform span events into actionable analytics for targeted troubleshooting.
We’ll also explore the resource and cost implications of various sampling configurations, ensuring efficiency without overspending. By the end, you’ll have practical strategies to enhance your traces and maximize the value of your observability setup.

The Freedom of Kubernetes requires Chaos Engineering to shine in production

Like any other technology transformation, k8s adoption typically starts with small “pet projects”. One k8s cluster here, another one over there. If you don’t pay attention, you may end up like many organizations these days, something that spreads like wildfire: hundreds or thousands of k8s clusters, owned by different teams, spread across on-premises and in the cloud, some shared, some very isolated.
When we start building application for k8s, we often lose sight of the larger picture on where it would be deployed and more over what the technical constraints of our targeted environment are.
Sometimes, we even think that k8s is that magician that will make all our hardware constraints disappear.
In reality, Kubernetes requires you to define quotas on nodes, namespaces, resource limits on our pods to make sure that your workload will be reliable. In case of heavy pressure, k8s will evict pods to remove pressure on your nodes, but eviction could have a significant impact on your end-users.
How can we proactively test our settings and measure the impact of k8s events to our users? The simple answer to this question is chaos Engineering.
During this presentation we will use real production stories to explain:
- The various Kubernetes settings that we could implement to avoid major production outages.
- How to Define the Chaos experiments that will help us to validate our settings
- The importance of combining Load testing and Chaos engineering
- The Observability pillars that we will help us validating our experiments

Who You Gonna Call? Taming OpenClaw's Rogue AI Agents with OpenTelemetry and Tetragon

There's something strange in your infrastructure. Who you gonna call?
OpenClaw , the open source AI agent formerly known as Clawdbot, then Moltbot exploded past 150,000 GitHub stars in weeks. It connects LLMs to your messaging platforms, terminal, and file system, giving AI full autonomous control. But like a Ghostbusters ghost, it wreaks havoc: $20 in tokens burned overnight to check the time, a one-click RCE (CVE-2026-25253), 21,000 exposed instances, and 341 malicious skills in the marketplace.
I will straps on my proton pack to bust these ghosts with open source tools. First, the OpenClaw Observability Plugin :
- an OpenTelemetry-based plugin capturing full agent lifecycle traces: request → agent turn → tool calls, with per-tool timing, token breakdowns, and error tracking. Your PKE meter for rogue AI.
- Then, Tetragon , eBPF-powered kernel-level policies restricting file access, network connections, and process execution. The containment unit no prompt injection can escape. A live demo ties it all together: OpenClaw + observability plugin + Tetragon, with traces and security events flowing into one dashboard.
We came, we saw, we traced it.

🧙‍♂️ Abracadabra! OTTL Turns Profiling into Metrics

What if you could conjure real-time insights from profiling data—no storage spells required?
In this session, we’ll explore how the OpenTelemetry Transform Language (OTTL) works like a wizard’s spellbook, letting you transform raw profiling data into actionable metrics on the fly. Using the collector-ebpf-profiler as your Marauder’s Map, you’ll learn how to enable profiling in Kubernetes and channel that data through a second collector for real-time processing.
We’ll demonstrate how to cast powerful OTTL transformations, measure resource usage during live profiling, and unlock the magic of this emerging observability signal—without ever writing to disk.
No enchanted memory bowls—just pure, live telemetry sorcery.

The Legend of Config: Breath of the Cluster

Configuring Ingress, Gateway API, or service meshes in Kubernetes can feel like exploring an open world without a map : one wrong turn, and traffic vanishes. In this session, we’ll explore how to detect and prevent misconfigurations using OpenTelemetry, eBPF-based instrumentation (OBI), and enriched logs from service meshes and ingress controllers. Like a hero collecting tools to unlock new areas, we’ll show how to identify relevant data sources, parse and process their output, and apply common correlation rules to understand the impact of configuration changes. We’ll demonstrate how these techniques can be applied across observability platforms to reduce tool sprawl and improve operational efficiency. Attendees will leave with a practical, backend-agnostic approach to building a multi-source observability strategy for Kubernetes networking.

The Kubernetes Guardians: A Deep Dive Into Your Security Avengers

In the fight to secure Kubernetes, we’re assembling a team of "Security Avengers" to defend your clusters from modern threats. Among the CNCF’s eBPF-based tools—Falco, Tetragon, KubeArmor, and Kubescape—each brings unique strengths, much like the Avengers. Despite their shared mission, their distinct features, architectures, and resource impacts make selecting the right "hero" a strategic decision.

This session unveils benchmarking results to help you choose the best fit for your Kubernetes security needs. We’ll explore key questions:

- What specialized features does each tool offer?
- How complex are setup and maintenance?
- How effectively do they detect and defend against attacks?
- What performance impact do they have?
Join us to compare these Kubernetes guardians, evaluate their real-world pros and cons, and discover the "Security Avenger" that aligns with your cluster’s defense strategy.

What agent to trust with your k8s: Falco, Tetragon or KubeAmor?

In the CNCF landscape we have plenty of ebpf based security solutions that help us protect our k8s cluster from runtime vulnerabilities. On paper though Falco, Tetragon and KubeArmor look very similar. Eventually you have to make a choice on which one best fits your needs.
To give you additional insights to make your decision join this session.
We have run extensive benchmarks against those three solutions and will answer the following questions that came out of our testing:
- What are the different featuresets?
- What about the performance impact of each agent?
- Which privileges does each solution need?
- What are the pros and cons across the three options?

You Know I'm BMad: How Structured AI Development Beat Vibe Coding at Its Own Game

our vibe coding is really, really bad , you know it!
Vibe coding, prompting an LLM and shipping whatever comes out is all flash and no foundation. Context loss, hallucinated architectures, zero documentation, and apps that crumble in production faster than you can say .
Enter the BMad Method , a structured multi-agent framework deploying 21 specialized AI agents (analysts, architects, QA) that guide development through proper planning, architecture reviews, and quality gates. Documentation becomes the source of truth, not the code. Now that's bad in the Michael Jackson way.
I will presents the BMad Observability Agent, a custom agent that injects OpenTelemetry best practices into every BMad workflow stage. Traces, metrics, logs and collector pipeline are woven into the project plan before a single line of code is written. A live demo builds an observable microservice from scratch using BMad + the Observability Agent, showing how structured AI development and observability-first design eliminate the "Thriller" of technical debt. With BMAD, Just beat it