The module lifecycle stage: Preview

Available in:  EE

Description

The sdn module is designed to consolidate network features within DKP. It currently supports the following features:

Node network interfaces configuration

The module provides a network interface configuration through a declarative API, allowing users to:

  • Aggregate ports.
  • Combine network interfaces into a bridge.
  • Configure VLAN interfaces.

Additional networks

This feature enables declarative management of additional networks for application workloads (Pods, Virtual Machines). This involves the following:

  • Each additional network implies a single L2 data exchange domain.
  • Within the Pod’s network namespace, an additional network is represented as a tap interface.
  • The following modes are currently available for L2 network implementation:
    • Tagged VLAN — communication between Pods on different Nodes uses VLAN-tagged packets and the infrastructure’s network equipment for switching. This method allows to create up to 4096 additional networks within a single cluster.
    • Direct access to a Node’s network interface — communication between Pods on different Nodes uses the local network interfaces of the Nodes.
  • From a network management perspective, there are two types of networks:
    • Cluster network — a network available in all projects, under administrator management. Example: a public WAN network or a shared network for cross-project traffic.
    • Project network — a network available within a Namespace, under user management.

Underlay networks for hardware device passthrough

The UnderlayNetwork resource enables direct attachment of physical network interfaces (Physical Functions and Virtual Functions) to pods via Kubernetes Dynamic Resource Allocation (DRA). This feature is designed for high-performance workloads that require direct hardware access, such as DPDK applications.

Key capabilities

  • Hardware device passthrough: Physical network interfaces (PF/VF) are directly exposed to pods, bypassing the kernel network stack for maximum performance.
  • SR-IOV configuration: Automatic configuration of SR-IOV on selected Physical Functions to create Virtual Functions, allowing multiple pods to share the same hardware.
  • DPDK support: Devices can be bound in different modes suitable for DPDK workloads:
    • VFIO-PCI: Explicitly connects a network device to the pod by binding it to the vfio-pci driver. The corresponding VFIO device files (e.g., /dev/vfio/vfio0) are mounted into the pod for userspace access.
    • DPDK: A universal mode that automatically selects the appropriate driver for the network adapter vendor. For Mellanox NICs, the device is bound to the mlx5_core driver with both the netdev interface and necessary device files mounted (InfiniBand verbs files, /dev/net/tun, and the corresponding sysfs directory). For other vendors, the device is bound via VFIO (same as VFIO-PCI mode).
    • NetDev: Only the Linux network interface is passed through to the pod as a standard kernel network device.

Operation modes

  • Shared mode: Creates Virtual Functions (VF) from Physical Functions (PF) using SR-IOV, allowing multiple pods to share the same hardware. Each pod receives one or more VFs.
  • Dedicated mode: Exposes each Physical Function as an exclusive device without SR-IOV. Each pod gets exclusive access to a complete PF, suitable for workloads requiring maximum performance.

Automatic interface grouping

When autoBonding is enabled, the controller groups interfaces from multiple matched PFs into a single DRA device. The interfaces are passed through to the pod as separate network interfaces, allowing applications (e.g., DPDK) to handle bonding/aggregation at the application level. Note that this does not create kernel-level bonding interfaces inside the pod.