KubeCon + CloudNativeCon Europe 2025 Recap: Lessons From the Field

A look back at the talks, trends, and tech that defined this year’s CNCF anniversary summit — plus what we’re bringing back to Criteo.

Authors: Hamza Boudouche, Basha MOUGAMADOU, Jean-Francois Weber-Marx & Benjamin Arezki

KubeCon + CloudNativeCon Europe 2025 took place from April 1–4 at the ExCeL London convention center and brought together over 12,000 attendees from across the globe. This year’s event carried special significance as it marked the 10th anniversary of the Cloud Native Computing Foundation (CNCF), adding a celebratory tone to an already electric atmosphere.

From the start, the experience was thoughtfully designed. Attendees were greeted with a smooth self-service check-in system, complete with mood stickers ranging from “talk to me” green to “leave me alone” red — an appreciated detail that helped foster comfortable and organic social interactions.

The venue itself was impressively vast, with large talk rooms that made it easy to drop into sessions, even at the last minute. This flexibility allowed attendees to freely explore a wide variety of presentations and shift between rooms as interests evolved. However, some rooms suffered from poor sound isolation — an issue that occasionally made it hard to follow a speaker while applause erupted next door.

The two massive showcase areas were another highlight, offering ample opportunity to network with fellow engineers, open source contributors, and companies — many of whom are close collaborators with teams at Criteo. Hallway conversations often led to spontaneous deep dives into tools and technologies we actively use or are currently experimenting with in production environments.

A key takeaway from this year’s KubeCon was just how dynamic the Kubernetes ecosystem continues to be. The community is thriving, with growing interest in platform and software engineering practices, and a surge in AI-related tooling — especially those focused on GPU orchestration, performance optimization, and sustainability. Networking technologies built on eBPF remain particularly popular, underscoring an ongoing push for efficiency and visibility at scale.

Main Takeaways from the Team

With so many sessions, conversations, and technologies packed into just a few days, everyone on our team walked away with unique insights and fresh perspectives. Here are some of the key highlights and reflections that stood out most to us during KubeCon Europe 2025.

Taking Care of Your Control Plane With API Priority and Fairness and Resource Quotas

Speakers: Ayaz Badouraly, Senior Software Engineer & Matteo Ruina, Senior Software Engineer (Datadog)

The kube api-server is the cornerstone of every Kubernetes control plane, almost everything going on in the cluster relies on it to function. Anyone running workloads in Kubernetes at scale will be very familiar with that, especially when using multi-tenant Kubernetes clusters, which is the case for us in Criteo.

In this talk, Ayaz and Matteo explain the measures they’re taking at Datadog to ensure the smooth functioning of their Kubernetes clusters’ control planes, using built-in Kubernetes resources such as FlowSchemas, PriorityLevelConfigurations, ResourceQuotas, and also custom controllers and adaptive scaling mechanisms.

Protecting the api-servers of a multi-tenant Kubernetes cluster from abuse by a certain tenant is necessary to ensure a high degree of reliability and availability for the rest of the cluster’s tenants. FlowSchemas and PriorityLevelConfigurations can be used to rationalize access to the api-server using a queuing mechanism that effectively rate-limits the incoming requests depending on their origin (aka the service account or user that issues the requests). For example, one could use these two resource types to give more priority for requests coming from service accounts (so ones that come from components deployed within the cluster) compared to the requests made by human users (that can be easily retried when rejected or throttled). Moreover, admins can have a higher priority than the rest of the users so that they can still operate the cluster in case of a request surge.

The api-server is not the end-all and be-all of protecting a Kubernetes cluster and its control plane. In a multi-tenant Kubernetes cluster, ResourceQuotas should also be used in order to limit the amount of compute resources that certain users can reserve, and also the number of resources that they can create. This will not only guarantee a fair resource allocation for all users but also protect common control plane components, like etcd and resource controllers, from being overloaded.

This talk provided a comprehensive overview of measures that can be employed for managing multi-tenant Kubernetes clusters. These measures are currently in practice at Criteo, where we oversee a fleet of dozens of clusters that are shared by approximately 40 different teams. The implementation of a robust and reliable multi-tenancy model is fundamentally essential to the functioning and success of our Kubernetes platform. This model ensures that resources are efficiently allocated, and operational complexities are minimized, enabling seamless collaboration among the diverse teams that share these clusters.

Key takeaways:

FlowSchemas and PriorityLevelConfigurations: Rationalize access to the api-server using a queuing mechanism that rate-limits requests based on their origin.
ResourceQuotas: Limit the amount of compute resources and the number of resources users can create to ensure fair allocation and protect control plane components.
Multi-tenancy model: Essential for efficient resource allocation and minimizing operational complexities in Kubernetes clusters.

The Next Generation of DaemonSet Autoscaling

Speakers: Adam Bernot, Google Cloud & Bryan Boreham, Grafana Labs

Kubernetes DaemonSets are awesome; they offer a great solution to workloads that need to be deployed on all worker machines of a Kubernetes cluster to achieve certain tasks, like network management, logging, secret management, feature discovery, and much more. Configuring a DaemonSet is generally not that hard, until you start thinking about the resource allocations that the pods of that DaemonSet will require to run efficiently. This is especially true in clusters with a variety of sizes and flavors, where DaemonSet pods in larger workers will tend to consume more resources than those running on smaller workers. Consequently, the former will force you to allocate a large amount of compute resources to the DaemonSet, even if it won’t be used to the fullest on all nodes.

In this talk, Adam and Bryan introduced a feature they’re working on to add support for handling the resource allocations to DaemonSets using Vertical Pod Autoscalers (VPAs) scoped by node. This works by modifying the VPA recommender to issue a separate recommendation for each pod of the targeted DaemonSet, taking into account the varying compute resource needs.

This project might prove useful at Criteo, where we’re managing large Kubernetes clusters with bare metal workers that are often not of the same size. The new machine flavors are generally getting beefier with every generation, and the old ones are phased out progressively. We’ve always worked around the issue by setting a one-size-fits-all resource allocation that’s large enough to accommodate the DaemonSet’s most demanding pod, but that’s clearly not ideal from an efficiency point of view. We will keep a close eye on the developments of this feature as it hits Beta later this year, and we’re looking forward to testing and eventually rolling it out in production.

Key takeaways:

Vertical Pod Autoscalers (VPAs) scoped by node: Modify the VPA recommender to issue separate recommendations for each pod, considering varying compute resource needs.
Efficiency in resource allocation: Avoid one-size-fits-all resource allocations by tailoring recommendations to individual pod needs.
Potential application at Criteo: Useful for managing large Kubernetes clusters with bare metal workers of different sizes, improving efficiency.

Journey at the New York Times: Is Sidecar-Less Service Mesh Disappearing Into Infrastructure?

Speakers: Ahmed Bebars, Principal Engineer (The New York Times) & Lin Sun, Head of Open-Source (Solo.io)

In this presentation, a principal engineer from the NY Times shared insights on their transition to a sidecar-less service mesh using Istio Ambient. Instead of deploying a sidecar for each pod, they utilize a component called ztunnel that operates as a node agent on each server. This component is responsible for meshing different services via an HTTPS Connect Tunnel, leveraging its proprietary HBONE (HTTP-Based Overlay Network Environment) protocol.

For Layer 7 (L7) interconnectivity, Istio Ambient employs a proxy known as Waypoint Proxy, which runs on a separate node. This proxy is designed to be scalable, capable of handling L7 traffic efficiently. Layer 4 (L4) policies are applied directly on the ztunnel, while L7 policies are managed by the Waypoint Proxy.

Key takeaways:

Istio Ambient vs. Cilium: Istio Ambient offers a compelling alternative to Cilium for service mesh solutions. It uses proxies to achieve similar goals, proxies running as daemonset at node-level.
Scalability: Discussions at the Solo.io | Cloud-Native API Management & Service Connectivity booth suggest that Istio Ambient is highly scalable and could potentially outperform Cilium. For more details, refer to their comparison blog post (further study recommended).

How We Moved Spotify To a Proxyless gRPC Service Mesh

Speakers: Erik Lindblad, Staff Engineer & Erica Manno, Senior Software Engineer (Spotify)

Spotify engineers explained how they replaced their service discovery for their microservices from DNS to an in-house control plane based on Envoy xDS (here are Envoy’s golang and java versions). They implemented a bespoke xDS control plane to fit their use case and ecosystem. The migration was done gradually and transparently, without traffic disruption.

Using gRPC on the client side, the service mesh load balancing is done on the client side, with only the service discovery fed using their xDS Control Plane. Overall, they improved their service discovery performance, enhancing the end-user experience.

Key takeaways:

Envoy Control Plane: Offers the possibility to reuse xDS control plane libraries to implement custom components tailored to specific needs.
Spotify’s Implementation: Demonstrated that a proxyless service mesh is achievable and performance can be improved using xDS, which is becoming a standard.
Industry Insights: Datadog presented a similar talk at gRPConf 2024. Other users have implemented similar solutions in previous years, as detailed in this presentation from 2022.

Scalable DNS With CoreDNS Plugins: A Deep Dive

Speakers: Yong Tang, Senior Director of Engineering (Ivanti), John Belamaric, Senior Staff Software Engineer (Google)

The CoreDNS maintainers delved into the latest CoreDNS releases, with the latest being version 1.12.1. They highlighted several new features, including acl, dnstap, and rewrite, among others. The maintainers also discussed the potential for extending CoreDNS to enhance its flexibility, illustrating how straightforward it is to write a plugin. They provided a detailed explanation of a demo plugin, guiding the audience through its implementation process.

A significant portion of the talk was dedicated to addressing a long-standing scaling issue within CoreDNS. The maintainers showcased their innovative solution: the creation of a multisocket plugin. This plugin leverages the SO_REUSEPORT socket option, enabling multiple servers to listen on the same port, thereby improving scalability.

To conclude the session, the maintainers encouraged the community to contribute to the project, emphasizing the importance of collaborative development in advancing CoreDNS.

Key takeaways:

New features in CoreDNS 1.12.1: Includes acl, dnstap, and rewrite.
Plugin development: Demonstrated how straightforward it is to write and implement plugins.
Multisocket plugin: Addresses scaling issues by enabling multiple servers to listen on the same port using the SO_REUSEPORT socket option.
Community contribution: Emphasized the importance of collaborative development in advancing CoreDNS.

Wait! Can Your Pod Survive a Restart?

Speaker: Aya Ozawa, Member of Technical Staff (CloudNatix Inc)

Aya described the entire application restart mechanism in Kubernetes to ensure there is no downtime for end users targeting the application. She detailed the restart scenarios at various entity level (container, replicaset, workload) along with the different workflows involved.

Key takeaways:

Educative insights: Very educative about making pods restart-friendly.
Practical application: Insightful for teams migrating applications from Mesos to Kubernetes, as this is our case at Criteo right now, highlighting the great features of the Kubernetes ecosystem.

AI Enabled Observability Explainers — We Actually Did Something With AI!

Speaker: Vijay Samuel, Principal MTS (eBay)

This talk from eBay’s Observability platform team was a refreshing break from the usual vague AI discussions. Instead of simply feeding telemetry data into an LLM and calling it a day, the team shared how they’ve been building “Explainers” that combine traditional algorithms with LLMs to create more predictable and useful insights.

Their system focuses on explaining signals like traces, metrics, and logs. One highlight was how they improved trace analysis — not just letting the LLM interpret a waterfall view, but guiding it with algorithmic context to get consistent, accurate results. They also introduced the idea of compound explainers, which bring together multiple building blocks to explain entire dashboards. Techniques like critical path detection, combined with LLMs, proved far more effective than just handing over raw traces.

It was a great example of thoughtful engineering meeting AI in a practical, results-driven way.

Key takeaways:

Combining traditional algorithms with LLMs: Creates more predictable and useful insights.
Improved trace analysis: Uses algorithmic context to guide LLMs for consistent, accurate results.

Empowering Accessibility Through Kubernetes: The Future of Real-Time Sign Language Interpretation

Speaker: Rob Koch, Principal (Slalom Build)

This session highlighted how AI and Kubernetes can work together to improve communication access. The team presented a real-time application that translates sign language into spoken language, using generative AI (LxMs) to interpret visual input from video and convert it into natural-sounding speech.

The app is designed to support multiple users and is fully deployed on Kubernetes, which handles orchestration, resource scaling, and real-time processing of both video and language data. It addresses a major gap in accessibility for the deaf and hard-of-hearing community, where scalable, real-time sign language interpretation is still lacking.

The talk also demonstrated how Kubernetes is well-suited for AI workloads, especially those combining video analysis and language generation in live environments.

Key takeaways:

Real-time sign language translation: Uses generative AI to convert visual input from video into natural-sounding speech.
Kubernetes for AI workloads: Handles orchestration, resource scaling, and real-time processing of video and language data.

Simplifying the Networking and Security Stack With Cilium, Hubble, and Tetragon

Speakers: Bowei Du, Senior Staff Engineer (Google), Bill Mulligan, Community (Isovalent), Anna Kapuścińsk, Software Engineer (Isovalent at Cisco), and Amir Kheirkhahan, Platform Engineer (DB Schenker)

This session marked nearly ten years of Cilium, which was initially announced in August 2026 during LinuxCon as a project providing fast IPv6 container networking with eBPF and XDP. Now widely adopted as the default CNI in Kubernetes environments, the talk focused on what’s new in the latest release and how Cilium’s eBPF-based architecture is streamlining networking, observability, and security across clusters.

Key topics included multi-cluster networking, support for large-scale deployments (up to 65,000 nodes), and service mesh capabilities. The session also highlighted sub-projects like Hubble for network observability and Tetragon for runtime security and enforcement.

Contributors and adopters — like DB Schenker, Google, and Isovalent — shared how Cilium is helping reduce complexity and unify the cloud-native stack.

Key takeaways:

Cilium’s eBPF-based architecture: Streamlines networking, observability, and security across clusters.
Support for large-scale deployments: Up to 65,000 nodes and multi-cluster networking.
Sub-projects: Hubble for network observability and Tetragon for runtime security and enforcement.

Generative AI Model Data Pre-Training on Kubernetes: A Use Case Study

Speakers: Alexey Roytman, Software Architect (IBM) & Anish Asthana, Engineering Manager (Red Hat)

This session focused on how Kubeflow Pipelines (KFP) can simplify and scale the complex process of preparing massive datasets for large language models. At IBM Research, these pipelines are used daily to build enterprise-ready, indemnified LLMs.

The talk walked through how KFP, along with tools like KubeRay, is used to orchestrate tasks like deduplication, content classification, and tokenization. It also compared different data prep toolkits — built on Kubernetes, Rust, Slurm, and Spark — and offered guidance on how to choose the right one based on your needs.

The team shared practical takeaways and challenges from their own experience, showing how KFP supports a range of LLM workflows, including data preprocessing, retrieval-augmented generation (RAG), and fine-tuning.

Key takeaways:

Kubeflow Pipelines (KFP): Simplifies and scales the process of preparing massive datasets for large language models.
Tool comparison: Guidance on choosing the right data prep toolkit based on your needs.

From Hours to Minutes: The Evolution of Platform Engineering at Decathlon

Speakers: Adrien Gillard & Christophe Furmaniak

The talk began with a simple yet powerful question to the audience: “What’s your definition of platform engineering?” This opened the floor for reflection before diving into Decathlon’s own journey.

They then set the stage by explaining the IT context at Decathlon. Back in 2018, the digital team consisted of over 5,000 people. Each sub-team within the tech business unit — e-commerce, stores, membership, and more — had its own operations team, tooling, and custom scripts. This fragmented approach led to significant inefficiencies, such as dozens of monitoring tools and duplicated efforts across teams.

In response, two key initiatives emerged:

Introducing tech governance to reduce tooling sprawl.
Creating a golden path for infrastructure provisioning.

To support this, Decathlon launched a new Platform team whose first product was a platform orchestrator called Stack 3S. This toolset introduced clear contracts between developers and platform teams. Infrastructure was described via YAML files and provisioned through pull requests in a fully “Infrastructure as Code” approach. It was a success — adopted across all domains. A dedicated team of 15 people maintained it, with contributions from over 50 developers across the company.

Despite the success, some limitations remained:

No connectivity to the internal network.
Limited ability to perform functional tests.
A monolithic Terraform implementation that was hard to scale.

Three years later, to address these issues, they launched a new project with three main goals:

Enable internal network connectivity to onboard all domains.
Improve the developer experience (UX).
Enhance the delivery process.

This led to the splitting of Stack 3S into two products: Single Region Product and Multi Region Product, alongside the creation of a new Internal Developer Portal. They even developed their own Terraform provider to interface with internal APIs and offer custom services like firewall rules, security policies, certificates, DNS, VPN, VPC peering, and more.

However, this new version introduced new challenges. It was so different from Stack 3S that no easy or automated migration path existed. Existing users had to start from scratch, and the migration cost was high. Worse, new users struggled to see the value proposition.

Faced with these realities, they made a tough call: they shut down the new project and returned to Stack 3S.

The talk focused on the key lessons learned:

Thorough planning and delivery management are critical.
Stay flexible: learn and adapt constantly.
Keep close to your users and their real needs.
Avoid putting excessive complexity on users.
Resistance to change is multi-layered — and inevitable.

On our side at Criteo, we face similar challenges in user onboarding and are actively working with our platform teams to create a clear and efficient path from code to production. The migration from Mesos to Kubernetes has driven us to expand functionalities within our internal developer portal. We are developing a robust multi-cluster and multi-datacenter platform that simplifies Kubernetes interactions for our users. Our platform experience team maintains close collaboration with end-users to ensure the tools and interfaces we create directly address their needs and enhance usability.

Key takeaways:

Thorough planning and delivery management: Critical for successful platform engineering.
Flexibility and user focus: Stay adaptable and keep close to users’ real needs.

From Metal to Apps: LinkedIn’s Kubernetes-based Compute Platform

Speakers: Ahmet Alp Balkan & Ronak Nathani

They presented how they transformed their infrastructure from bare-metal servers to a fully automated, large-scale Kubernetes platform, serving over one billion users. LinkedIn operates more than 500,000 servers, manages over 1.5 million containers, and performs around 50,000 deployments daily across multiple data centers globally. This scale, entirely on bare metal infrastructure, introduces significant complexity in automation, management, and reliability.

Instead of using a ready-made Kubernetes distribution, LinkedIn built its own Kubernetes platform tailored precisely to internal needs. This environment includes several key internal systems and practices:

Datacenter and Machine Layer:

Inventory Manager: Tracks datacenter inventory and machine properties.
Compute Broker: Provides a declarative gRPC API for managing machine pools, capacity allocation, and is the authoritative source for maintenance operations.
Host Health Monitoring: Automatically detects and remediates unhealthy hardware without human intervention.
Maintenance Orchestrator: Gradually manages OS, kernel, and kubelet upgrades across 20 maintenance zones. Each maintenance process involves orchestrating planned disruptions, cordoning and draining Kubernetes nodes, performing upgrades or hardware replacements, and then safely returning nodes to service.

We have built similar components at Criteo with a custom orchestrator for maintenances called Tacamo, hardware monitoring with automated decommission, and a central inventory.

Cluster Organization and Scale:

LinkedIn manages large, multi-tenant clusters with around 5,000 nodes per cluster.
Clusters support diverse workloads, including stateless web services, stateful data systems, batch jobs, and machine learning workloads.
Each workload is assigned to a namespace routed dynamically to clusters based on available resources and specific hardware profiles.
Kubernetes clusters are managed centrally through specialized “hub” clusters, which handle workload routing, cluster policies, and infrastructure orchestration.

Scalability and Reliability Practices:

API server and etcd are proactively scaled and monitored, with etcd storage capacity expanded significantly (8GB to 16GB, planned 32GB on SSD).
RBAC (Role-Based Access Control) ensures secure, controlled access.
API fairness and priority mechanisms mitigate bottlenecks in the Kubernetes control plane.
A custom backup and restore system safeguards against disasters and data loss.

This quarter we start to study monitoring of API fairness and priority mechanisms before we scale.

Migration Principles and Progress:

LinkedIn’s migration to Kubernetes follows clear principles: zero downtime, fully automated migrations for stateless applications, and proactive tech debt management.
Stateless workloads are well underway, while stateful applications like Kafka and Pinot use a custom-built operator to coordinate complex lifecycle tasks and data placement on local SSDs.

Developer and User Experience:

Custom Kubernetes resources (LiDeployment, LiStatefulSet) significantly simplify workload management.
A specialized internal kubectl plugin and an internal UI aid troubleshooting and workload management.
Strong safeguards, such as preventing accidental deletions and risky operations (e.g., excessive scaling), protect the infrastructure from human error.
Centralized namespace orchestration, policy enforcement, and workload management practices are employed through GitOps.

Technical Challenges Encountered:

Scaling Kubernetes components, such as etcd, beyond their current limits presents significant challenges.
Migrating thousands of microservices without causing interruptions necessitated comprehensive automation and meticulous planning.
Debugging tools and practices required a substantial redesign to cater to users who are not familiar with Kubernetes internals.
Managing ArgoCD internally at scale proved to be difficult.

LinkedIn’s journey with Kubernetes has provided several key insights:

Begin migrations early and adopt an incremental approach to effectively manage complexity.
Clearly identify and prioritize technical debt to streamline processes.
Avoid exposing raw Kubernetes details to end-users; instead, offer abstractions and automated safety measures for a smoother experience.
Invest in thorough documentation and self-service troubleshooting capabilities to empower users.

In conclusion, LinkedIn’s custom Kubernetes platform serves as a prime example of how intentional engineering and well-considered abstractions can adeptly manage infrastructure at an impressive scale, thereby simplifying operational complexity and boosting developer productivity.

This presentation was particularly pertinent as we are in the process of migrating from Mesos to Kubernetes. We have already tackled similar challenges, including node maintenance management, stateful workload handling through a custom node-disruption-controller, zero-downtime migration strategies, enhanced debugging tools, and namespace orchestration. Our current emphasis is on refining control plane and system tooling to effectively manage increased scalability. Additionally, Hamza has begun working on the kubeception subject on our end, and we are also striving to improve resource isolation.

Key takeaways:

Custom Kubernetes platform: Tailored to LinkedIn’s internal needs, managing large-scale infrastructure efficiently.
Scalability and reliability practices: Proactive scaling, monitoring, and robust backup systems ensure high availability and performance.
Developer and user experience: Simplified workload management, strong safeguards, and centralized orchestration enhance usability.

From high-level vision talks to deep technical sessions — especially those focused on self-managed, bare-metal infrastructures like Criteo’s — there was something inspiring for everyone. Overall, KubeCon Europe 2025 was a vibrant convergence of ideas, people, and innovation, showcasing just how far cloud-native has come — and where it’s heading next.

Check all the videos & the pictures.

Join our team and be part of our tech community 👇

Engineering

We are creators! From designing ground-breaking products to finding unique ways to solve technical challenges at an…

bit.ly