CNCF-hosted Co-located Events Europe 2025

In G-Research’s ML environment of over 10,000 nodes, we leverage Cilium as the core network for on-premise, bare-metal clusters scaling to 1,000 nodes each. In this talk, we’ll discuss several Cilium features used in detail:
● Network policy to enforce strict security controls for segmenting and protecting market-sensitive information
● Host firewall to remove the need for external firewall appliances
● High-performance eBPF dataplane that directly improves ML job performance

We’ll also cover the implications of limiting Cilium’s identity labels to reduce policy map pressure, tuning conntrack garbage collection, and the performance implications of different policies at scale. Attendees will learn how to use Cilium’s built-in tools to observe and measure large deployments, and what to look out for in large Kubernetes clusters.

I see you want to hire a developer to work on platform engineering, internal developer tooling, developer experience, and the overall generally intangible but admirable goal of "making life better for devs". That’s awesome; you've got one hell of a challenge ahead of you. This role is extremely difficult to hire for. In my opinion, and in my experience, it’s been the most difficult role in the company outside of senior leadership, and the most likely to fail; if there ever was a role that burns people out, it’s this one.

Come with Hazel as we draw on her experiences building platform teams and organizations in order to talk about making this platform engineering thing a reality. In doing so, we'll end up discussing topics such as

- The hiring pipeline and interview loop
- Timing, politics, and the meta strategies
- Getting to zero from negative
- Avoiding pitfalls

In this session attendees will get an in depth overview of how Envoy manages memory allocations with the help of Google tcmalloc allocator. We will also go over on demand memory releasing techniques in Envoy and shed light on why they don't operate in a fully predictable way. Lastly we will reveal the future plans of supporting more allocator types that can be leveraged for better memory management for certain deployment types.

While many users interact with Kubernetes using abstractions like YAML files, the intricate interactions between Kubernetes components often remain hidden. This technical session takes you on a live journey through the "hard way" of setting up Kubernetes, peeling back the layers of abstraction to reveal how its core components—such as the API Server, etcd, Controller Manager, Scheduler, and kubelet—interact to orchestrate workloads. By tracing the lifecycle of a Pod from kubectl create to running container, we'll explore how often-overlooked components like the cloud controller manager and kube-proxy play critical roles in cluster operations. Through this live demonstration, attendees will gain a deep understanding of Kubernetes' internal mechanics, empowering them to troubleshoot more effectively, make informed architectural decisions, and unlock the true potential of Kubernetes in production environments.

OpenTelemetry automatic instrumentations greatly help with achieving a high baseline of observability for applications. But applying them in containerised environments still requires manual, error-prone intervention by users. LD_PRELOAD-based injection is an advanced technique that has been used by commercial vendors for a decade or more, is by now very well understood, and does not require access to the Kernel like eBPF does (which is a huge challenge in managed compute environments), or any increase in permissions other than what the host runtime has.

In this talk, we go in depth into how this magic works across various runtimes, and how it could benefit the OpenTelemetry community at large.

As feature flags move from simple toggles to core infrastructure, engineers face complex technical challenges that aren't covered in basic tutorials. This technical session dives deep into 3 critical problems in feature flag architecture at scale: maintaining consistency across regional deployments, handling circular dependencies between flags, and managing flag evaluation performance under heavy load.

The presentation walks through specific architectural patterns, including:

* Implementing consistent hashing for user targeting across distributed services
* Using dependency graphs to detect and prevent circular feature flag references
* Building efficient caching layers that handle rapid flag updates without sacrificing evaluation performance
* Managing flag cleanup through automated detection of stale references

Each pattern will be demonstrated with code examples showing both naive implementations and production-ready solutions.

As we deploy, operate and manage an ever growing amount of clusters, and extend our cloud native applications to (far) edge locations, across regions, data centers, and environments, the current multi-cluster architecture of Argo CD is hitting its limits. To face this challenge we need to be ambitious: let’s revolutionize the multi-cluster story of Argo CD and enable it to scale out to the edge, all while keeping a central control plane.

In this talk, we will discover the new community-driven Argoproj-Labs project argocd-agent, that inverts the paradigm of the current Argo CD multi-cluster architecture; instead of having Argo CD connect to the clusters it manages, it lets those clusters connect to Argo CD through an agent.

Looking at some of the challenges and caveats that you face with the current multi-cluster architecture in Argo CD, we’ll explore how the agent model can improve scalability, reliability and security for large-scale Argo CD multi-cluster setups.

In containerized environments, one key challenge of pushing observability data is to identify the sender, to allow data enrichment, i.e. attaching attributes, tags, metadata based on container or Pod metadata.
This problem has been commonly solved by asking the sender to provide its own container id, easily available through /proc/self/cgroup.

When Datadog started evaluating cgroupv2, it quickly became apparent that this approach was not usable anymore, prompting us to find new solutions as the most common workaround (using mountinfo) is actually not reliable.
In this talk we'll explain why the container id is not available anymore (due private cgroup namespace) and present two solutions that we worked on.

We will go through the benefits of each one and will share how these solutions could be used in other observability projects, like OpenTelemetry.

All you need to run your application on a supercomputer is to target a specific node on your local kubernetes cluster. If you are really an expert and want to play with MPI capabilities of a SLURM batch system at a remote HPC center, you just have to pass your job parameters in the pod annotations.

This is possible today, and at INFN we are proposing a community ecosystem to streamline the adoption of the Virtual Kubelet technology. From beefy machines in your basement to batch systems and PaaS/CaaS services, interLink provides a common and cloud-native interface to make kubernetes pods running where kubernetes is not an option.

We'll be presenting how this is possible and how the first real scientific use cases are already running their payloads at EuroHPC centers. We'll be demoing ML training and GenAI frameworks running seamlessly on Leonardo and Vega supercomputers, everything on a single kubernetes cluster.