Kubernetes revolutionized application orchestration, but infrastructure management? Still a mess of REST APIs and shell scripts that barely integrate with the ecosystem. Guvenc Gulce and IronCore Team saw datacenter operators wrestling with networking solutions that treated Kubernetes as an afterthought, bolted on rather than built in.
The vision was clean: pure IPv6 underlay networks, software-defined overlays, SmartNIC offloading, all controlled through native Kubernetes APIs. No NAT boxes. No firewall appliances. Just L3 routing with SDN on top. One of the important challenges of this endeavor ? Building a dataplane fast enough to hit line-rate while maintaining the flexibility to integrate deeply with Kubernetes.
That’s where dpservice comes in – and where DPDK became essential.
The Gap in Infrastructure Management
“We thought that there was a need for a good solution for Kubernetes based infrastructure management for real and virtualized resources in a datacenter environment with software components designed from the beginning to integrate nicely with the Kubernetes ecosystem,” Güvenç explains.
That motivation drove the creation of dpservice as a key component of the SDN layer for IronCore – an open source, EU-funded project under The Linux Foundation and NeoNephos Foundation.
The problems in the open source infrastructure space were clear. “A lot of the infrastructure resource management projects were using REST APIs and/or script based solutions lacking operational logic and they would integrate half-heartedly with Kubernetes and they were not really designed with Kubernetes in mind,” Güvenç notes. These solutions treated Kubernetes as just another API endpoint rather than embracing it as the foundation for infrastructure orchestration.
The architectural vision went further.
“We also think that datacenter underlay traffic can be simple and only using IPv6 is enough. This would ease network operations and reduce the amount of used appliances in the datacenter. (NAT / Firewall boxes),” says Güvenç.
The idea: dpservice sitting on top of a simple IPv6 underlay network would offer software defined networking functionality by making use of SmartNICs, while IPv4 and IPv6 could still be offered in the customer virtual network.
This wasn’t about recreating existing virtual switches. It was about rethinking datacenter networking from first principles with Kubernetes as the control plane.
Why DPDK Was Non-Negotiable
When you’re building high-performance SDN, your options narrow quickly.
“If you need fast / low latency / high throughput software defined networking in datacenters, you don’t have that many options. EBPF and DPDK are the first two dominant technologies that come to your mind,” Güvenç explains.
The team chose DPDK for specific reasons: “it offers a rich ecosystem of libraries to develop the dataplane/packet processing logic and offers a nice software abstraction to offload the traffic completely to the hardware.”
The performance target wasn’t ambitious – it was absolute.
“By using DPDK, we can reach line-rate in the software defined network functions we use which is actually the highest performance you can get.”
Line-rate means the theoretical maximum throughput of the hardware. There’s no performance left on the table.
This matters because dpservice isn’t handling toy workloads. It’s the SDN layer for production infrastructure supporting virtualized and bare metal resources. Packet forwarding, routing, NAT, firewalling – all happening in software at wire speed. DPDK’s library ecosystem made this achievable without writing everything from scratch.
The hardware offload abstraction proved equally critical. SmartNICs can take over packet processing tasks entirely, but only if the software can communicate with them effectively. DPDK provides that layer, letting dpservice treat hardware acceleration as a configuration choice rather than a complete architectural rewrite.
What dpservice Actually Is
At its core, dpservice is a DPDK-based dataplane designed for a specific architectural vision. Unlike OVS-DPDK or VPP, it’s built around assumptions that simplify datacenter operations.
“OVS-DPDK and VPP are two prominent examples when it comes to DPDK based virtual switches and routers but they both also have their pros and cons and would not fit to our use-case 100%,” Güvenç explains. “OVS is very L2 oriented for example but our solution aims for simplifying the underlay network where we keep the L2 networks very small (2 members) and run the communication purely L3 based.”
VPP presented different challenges.
“VPP’s code is also mostly not based on DPDK libraries and has a steep learning curve, if you want to adapt it to your needs. DPDK is doing a much better job here and the VPP’s graph based dataplane approach can be used also in the DPDK ecosystem where dpservice is also doing it.”
The distinctive features emerge from these design choices. “The unique features of dpservice are being very L3 oriented, supporting IPv6 from the beginning, Supporting SR-IOV and hardware flow offloading from the beginning,” says Güvenç. The project also ships with “a kubernetes controller and API which can be used to create Virtual Networks, Virtual Interfaces and Network Functions.”
That Kubernetes integration isn’t an afterthought. The metalnet controller (https://github.com/ironcore-dev/metalnet) bridges dpservice into the broader IronCore ecosystem, making network resources manageable through standard Kubernetes patterns.
Güvenç’s own summary captures it well:
“dpservice project delivers a high-performance DPDK based dataplane for SR-IOV virtual functions, seamlessly integrating into Kubernetes environments through its metalnet controller to provide scalable software defined networking services.”
Why Kubernetes Integration Matters
The push for Kubernetes-native infrastructure management isn’t about following trends. “Seamless Kubernetes integration is important as we think that Software Defined Networking should have all the positive effects of a Kubernetes based infrastructure management, like self-healing of managed systems and easier Day-2 operations with a better central insight to the managed systems underneath,” Güvenç explains.
For operators, the abstraction changes daily work. “For an operator, the managed virtual machines, metal machines and virtual networks are like abstract resources and he doesn’t need to deal with specific machines and customer networks in the infrastructure. These are declared as kubernetes specifications and they get materialized with Kubernetes controllers in place. Operator’s job can be simplified and automated.”
The benefits extend to AI-driven operations. “It would be even easier to inject AI based decisions into an IaaS system which uses Kubernetes as there are mature AI based decision helpers which nicely integrate with Kubernetes,” notes Güvenç.
Developers gain leverage too. “A developer can also rely on the battle-tested Kubernetes libraries / testing frameworks when he/she develops his/her resource management logic and this would make possible to concentrate on the real value delivered (like in our case an SDN layer) as the rest is already a mature technology which can be leveraged.”
The observability story integrates naturally. “We also use Prometheus and Grafana from CNCF project suite to give a better observability to dpservice internals. Prometheus exporters can nicely integrate with DPDK’s telemetry interface.” The entire cloud-native ecosystem becomes available once you’re Kubernetes-native.
The IronCore and European Sovereign Cloud Context
dpservice doesn’t exist in isolation. It’s the SDN layer for IronCore, which tackles infrastructure-as-a-service challenges in the NeoNephos Foundation context. “IronCore is the project in Neonephos context which concentrates on infrastructure management. It is a typical IaaS project/offering and it is one of the important building blocks to provide the high level services in the sovereign cloud context, like platform mesh and it integrates nicely with other Neonephos projects like Gardener and Garden Linux.”
The European sovereign cloud effort addresses real concerns about infrastructure independence and data sovereignty. dpservice provides the high-performance networking layer that makes this vision technically feasible. “dpservice is providing the SDN layer of the IronCore IaaS and making it an important piece in the overall context.”
The project is young in the open source world. “The project is not so widely known yet as it was donated to The Linux Foundation only 3 months ago by SAP,” Güvenç notes. The contributor base reflects this early stage: “We have on our github page 14 contributors at the moment. I am the single maintainer and technical lead of the dpservice project at the moment but we have 3 more key people contributing to dpservice. The initiator of the project is Malte Janduda and the other two key contributors are Jaromír Smrček and Tao Li .”
The organizational backing is visible. “The organisations which are involved are also the same organisations which are members of the Neonephos Foundation. This can be seen publicly on the Neonephos page: https://neonephos.org/members“
Engaging with the DPDK Community
The dpservice team is actively seeking connections with the broader DPDK community.
“We would be happy to get feedback about the dpservice project from the DPDK community,” says Güvenç.
“I am already in close contact with the maintainers and technical committee of the DPDK and presented dpservice to them. We also explore possibilities of what we can upstream from dpservice to the DPDK ecosystem. There are the first ideas emerging like re-usable DPDK Graph nodes which can be contributed to the DPDK community.”
This upstream engagement could benefit both projects. DPDK gains real-world validation of its graph-based dataplane approach and potentially reusable components. dpservice gains visibility and community feedback that can strengthen the project.
What’s Coming Next
The roadmap is public and actively maintained: https://github.com/orgs/ironcore-dev/projects/13
Two major features dominate the near-term plan. “The most important two things we plan to do in the near future is to give the ability to dpservice encrypt the traffic leaving from it to the wire and decrypt the traffic it receives from the wire,” Güvenç explains. Wire-level encryption adds another layer of security for sovereign cloud deployments where data protection is paramount.
“The second important thing on the roadmap is to integrate High Availability to dpservice so that dpservice can run with two instances and there is the possibility of seamless failover from one instance to the other one.” Production infrastructure demands resilience, and HA support moves dpservice from interesting technology to production-grade component.
Getting Started and Contributing
You don’t need a datacenter to experiment with dpservice. The team built ironcore-in-a-box specifically to lower the barrier to entry. “If someone wants to try dpservice or IronCore. You don’t need first a complex infrastructure for it. We have the ironcore-in-a-box project which uses the Kind cluster to demonstrate the usage of the IronCore project. TAP device based dpservice is included. Installation is very easy.” (https://github.com/ironcore-dev/ironcore-in-a-box)
For developers looking to contribute, Güvenç provides clear starting points. “For the potential contributors, I would recommend to start with the developer documentation of dpservice https://github.com/ironcore-dev/dpservice/tree/main/docs/development and for the overall understanding of IronCore, I would recommend to start with the IronCore documentation https://ironcore.dev/iaas/getting-started.html and especially networking part of it.”
A technical deep dive is available for those who want more detail: https://guvenc.github.io/software%20engineering/2024/10/18/dpservice.html
The project welcomes engagement. “We also welcome contributions / comments and more stars for the GitHub page of the dpservice.” (https://github.com/ironcore-dev/dpservice)
The Reward
Building infrastructure software can be thankless work – months of effort invisible to end users. But Güvenç finds motivation in real-world impact. “I think the most exciting and rewarding moment is to see other people use dpservice / IronCore and they can get an added value out of it.”
The development experience itself offered early wins. “During the build phase it was very exciting to make fast progress to implement the first features of dpservice as the DPDK has nice examples and a wide range of libraries which make the first success moments quickly possible.”
That’s DPDK’s strength showing through – not just raw performance, but an ecosystem that accelerates development. When your networking dataplane needs to hit line-rate while integrating with Kubernetes, talk to hardware SmartNICs, and support production workloads, you need a foundation that handles the complexity. DPDK provides that foundation.
dpservice shows what becomes possible when you build on it.
Try dpservice:
- ironcore-in-a-box: https://github.com/ironcore-dev/ironcore-in-a-box
- dpservice repository: https://github.com/ironcore-dev/dpservice
- IronCore documentation: https://ironcore.dev/iaas/getting-started.html
- Technical deep dive: https://guvenc.github.io/software%20engineering/2024/10/18/dpservice.html
- metalnet controller: https://github.com/ironcore-dev/metalnet
Connect with the team on Linkedin:
