A practical OpenShift egress QoS bridge while NetworkQoS is still upstream

OpenShift administrators do not yet have a native, generally available Kubernetes object for expressing egress traffic priority. A new Red Hat Developer walkthrough fills that gap with two useful views: a preview of the declarative NetworkQoS API being developed for OVN-Kubernetes, and a reproducible Linux traffic-control lab that operators can use today.

The immediate problem is familiar. Backups, log shipping and bulk transfers can compete with production traffic on a shared interface. A hard rate limit protects the foreground workload, but it also strands capacity whenever production is quiet. The walkthrough instead builds a hierarchy that gives production and background traffic guaranteed shares while allowing either class to borrow unused bandwidth.

What the lab builds

The example uses two OpenShift worker nodes, a localnet secondary ClusterUserDefinedNetwork, four pods and iperf3. On the sending node, Linux tc applies a hierarchical token bucket to a 25 Gbps bonded interface. Production receives a 90% guarantee; background traffic receives a 10% floor; both can burst toward the interface ceiling when the other is idle. A flower filter identifies the lower-priority destination IP and assigns that traffic to the background class.

Red Hat’s reported results illustrate why this is different from a flat cap. Each stream reached 20.4 Gbps when tested alone. Under simultaneous load, production sustained 19.5 Gbps while background traffic fell to 2.70 Gbps, slightly above its 2.16 Gbps guarantee. Combined throughput reached about 22.2 Gbps against a configured 23.75 Gbps ceiling. The link therefore remained well used while production retained most of the capacity.

Where the native API is headed

The upstream OVN-Kubernetes proposal, OKEP-4380, defines a namespaced NetworkQoS custom resource under k8s.ovn.org/v1alpha1. The example policy selects pods and classifies egress destinations, then applies priority, DSCP marking and bandwidth settings. Red Hat says the OpenShift work is tracked as OCPSTRAT-3266.

That declarative shape matters operationally: policy can eventually be managed like other Kubernetes resources rather than reconstructed with host commands. The post does not say the feature is available in OpenShift today, so operators should treat the CRD as a preview of direction rather than a deployable product capability.

What to try—and what not to assume

The lab is most useful as a controlled reproducer for teams that can identify background flows by destination IP or CIDR and want to validate the behavior of weighted egress classes. Its cleanup steps remove both the test project and the root queueing discipline.

The workaround is not durable by itself. Manually applied tc rules disappear after reboots or interface resets. Red Hat suggests that anyone operationalizing the approach would need to wrap the rules in a script and systemd service and deploy them declaratively, for example with a MachineConfig. That adds node-level lifecycle responsibility, so platform teams should test interface names, VLAN matching and recovery behavior before taking the pattern beyond a lab.