live wire
▸AI · vLLM Recipes maps Muse Spark Open to single-node Blackwell and AMD deployment (Oct. 16)vLLM▸PLATFORM · Clang 23 bytecode interpreter cuts allocations and expands constant-expression supportRed Hat Developer▸PLATFORM · RHEL becomes first-party on OCI; OpenShift subscriptions reach Oracle MarketplaceRed Hat▸AI · vLLM-Omni merges native MOSS-Image serving with parallelism and offloadvLLM▸AI · vLLM adds System One endpoint for Decision 3.0 multimodal routing models (Oct. 15)vLLM▸SECURITY · Red Hat rates OpenShift AI 3.4.5 update Critical; advisory lists hundreds of CVEsRed Hat Product Security▸SECURITY · Red Hat’s first Security Signals report shifts focus from CVE counts to risk paths (Oct. 15)Red Hat▸PLATFORM · IBM adds non-destructive FlexVolume-to-CSI migration tool for OpenShift object storageIBM Cloud▸vLLM tests agent-built Kimi K3 decode path at up to 1.9× speedup; PR remains openvLLM▸AI · LeaderWorkerSet 1.0 changes rollout defaults for disaggregated AI workloadsKubernetes SIGs▸SECURITY · Red Hat flags active exploitation of kernel flaw affecting OpenShift CoreOS; no fix listedRed Hat Product Security▸AI · Red Hat sets Dec. 9 showcase for AI 3.6 agent governance and model servicesRed Hat▸vLLM 0.32.0 drops Python 3.10, restricts CORS defaults and adds security fixesvLLM▸SECURITY · Red Hat tracks Moderate Hono auth bypass across OpenShift AI, Dev Spaces and AnsibleRed Hat Product Security▸AI · vLLM Recipes maps Muse Spark Open to single-node Blackwell and AMD deployment (Oct. 16)vLLM▸PLATFORM · Clang 23 bytecode interpreter cuts allocations and expands constant-expression supportRed Hat Developer▸PLATFORM · RHEL becomes first-party on OCI; OpenShift subscriptions reach Oracle MarketplaceRed Hat▸AI · vLLM-Omni merges native MOSS-Image serving with parallelism and offloadvLLM▸AI · vLLM adds System One endpoint for Decision 3.0 multimodal routing models (Oct. 15)vLLM▸SECURITY · Red Hat rates OpenShift AI 3.4.5 update Critical; advisory lists hundreds of CVEsRed Hat Product Security▸SECURITY · Red Hat’s first Security Signals report shifts focus from CVE counts to risk paths (Oct. 15)Red Hat▸PLATFORM · IBM adds non-destructive FlexVolume-to-CSI migration tool for OpenShift object storageIBM Cloud▸vLLM tests agent-built Kimi K3 decode path at up to 1.9× speedup; PR remains openvLLM▸AI · LeaderWorkerSet 1.0 changes rollout defaults for disaggregated AI workloadsKubernetes SIGs▸SECURITY · Red Hat flags active exploitation of kernel flaw affecting OpenShift CoreOS; no fix listedRed Hat Product Security▸AI · Red Hat sets Dec. 9 showcase for AI 3.6 agent governance and model servicesRed Hat▸vLLM 0.32.0 drops Python 3.10, restricts CORS defaults and adds security fixesvLLM▸SECURITY · Red Hat tracks Moderate Hono auth bypass across OpenShift AI, Dev Spaces and AnsibleRed Hat Product Security
upstreambeat.ai
guidePLATFORM

A practical OpenShift egress QoS bridge while NetworkQoS is still upstream

Red Hat’s lab shows how an HTB hierarchy can protect production traffic without wasting idle bandwidth, while a declarative OVN-Kubernetes API remains in development.

Egress QoS throughput chart for OpenShift traffic classes
Chart: figures from the story
By The News Desk· Oct 8, 2026the quick take — two AI hosts go live when you do

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.

sources

Filed by The News Desk. Corrections: desk@upstreambeat.ai · Our standards →

comments · 0

    Comments are moderated before they appear. Your email is used once to confirm it is you — never shown, never sold. Corrections and questions get an answer from the desk when we have one.

    more from the desk