Etraveli Group

Etraveli Group Replaced Proprietary Load Balancers and Eliminated Production Downtime with Cilium

Challenge

Etraveli Group is a global flight technology provider that handles hundreds of millions of flight searches every day for 48 million customers across 75 markets. It operates consumer brands like FlightNetwork, GoToGate, Mytrip, and SuperSaver, and provides flight technology solutions to industry partners.

The company’s SRE team is responsible for the platform infrastructure that underpins the flight technology. The team runs a large private cloud on OpenStack, spanning multiple data centers, with 14 Kubernetes clusters across test, staging, and production environments.

Etraveli, a 25-year-old company, migrated to Kubernetes in 2019 to upgrade its legacy infrastructure and operates across both VM-based and bare metal clusters. After migrating, the team’s V1 load balancing was handled by two proprietary hardware boxes across three data centers. “It was never the packet processing that was the bottleneck for us,” said Mikael Johansson Länsberg, Platform Architect at Etraveli Group, in a talk during CiliumCon Europe 2026. “It was the architecture itself.” 

The original setup funneled all traffic into one data center at a time, so scaling meant upgrading the appliances or buying new hardware. The resource model was also locked into one vendor’s proprietary CRDs, plus automation was limited, and observability had to be bolted on. The clusters generated a huge volume of API calls, eventually causing the appliances to crash, leading to downtime in both production and test environments.

The team was clear in what they were looking for in their next solution: self-service for developers, BGP-based routing, load balancers that scale with the cluster, a GitOps operations model, no vendor lock-in, and integrated observability.

Solution

Etraveli had been using Cilium as their CNI since 2022, after finding that its previous BGP configuration was too complex and fragmented. Cilium offered native BGP, and the production rollout was smooth from the start. In 2024 the team began exploring what a V2 load balancing architecture could look like, and it turned out the solution was already in place. “The features we were looking for, LB-IPAM, BGP Control Plane, and Gateway API, were all already part of Cilium,” Länsberg said. “Everything fits like Lego bricks, you can just enable new features.”

Those three features together enabled a fundamentally different architecture. Rather than routing all traffic through centralized hardware appliances, Cilium’s BGP Control Plane peers directly with the data center routers, advertising LoadBalancer IP addresses from every node across all three data centers, while the BGP table enables distribution across the entire cluster. Every node added to the cluster contributes additional load balancing capacity automatically and the data and control plane scale with the infrastructure. At the application layer, Gateway API replaces the old vendor-specific resource model. External DNS and cert-manager complete the stack by reading routes and issuing TLS certificates.

The migration from V1 to V2 was designed to be incremental given the organizational dynamics involved. Both versions ran in parallel within the same clusters, with individual services migrated one at a time via a feature toggle. The full rollout from initial testing to production took approximately two months. The main coordination dependency was BGP peering configuration on the physical network infrastructure, which was handled by a separate network team. The primary friction point was DNS. Coexisting V1 and V2 FQDNs required careful management throughout. As the saying goes, “it’s always DNS,” Länsberg noted.

Impact

The most immediate and visible result was reliability. The crashes that had caused production downtime have thus far been eliminated. “It’s much more operationally stable and resilient since we’ve spread load balancing out across the clusters,” Länsberg said.

There were also improvements in traffic distribution for CPU-intensive, high-throughput services. The team observed that load was spread significantly more evenly across nodes, which came from replacing the old single-funnel model. Two services handling thousands of requests at peak are now running on V2 without interruption.

The observability change has been equally important. The old infrastructure was a black box at the load balancing layer, with limited metrics, and no way to instrument what was actually happening. Teams can now build complete traffic flow dashboards using Gateway API and Hubble, and reason directly about infrastructure behavior. “The load balancing moved down into the Kubernetes layer, closer to the applications,” Länsberg said. “It’s understandable now, everyone can see where load balancing is handled and how it works.”

Etraveli is continuing to migrate the remaining services to V2 and tracking Gateway API and Cilium feature development closely, exploring capabilities including service topology and BackendTLSPolicy as they mature. The team is waiting on Cilium v1.20 to unlock the next set of Gateway API features. “On-premises is not second-class,” Johansson Länsberg told the CiliumCon Europe 2026 audience. “It’s possible to build great solutions on-premises too.”

Disclaimer: This case study is for informational purposes only and reflects the technical experiences of the contributors. Etraveli Group AB provides no warranties, express or implied, regarding system performance or uptime, and guarantees no specific results for third parties.