A key enhancement in Kubernetes 1.34 provides network operators with fine-grained control over traffic routing decisions within clusters.
Kubernetes 1.34 made its debut this week, bringing with it a host of updates that will help to improve cloud-native operations. Among the enhancements are several significant networking upgrades that directly address operational pain points in large-scale deployments. As is tradition with each Kubernetes release, there is a theme (and a logo, pictured below). For Kubernetes 1.34 the theme is Of Wind & Will (O’ WaW).
“What keeps Kubernetes moving isn’t the perfect winds, but the will of our sailors who adjust the sails, man the helm, chart the courses and keep the ship steady,” the release announcement states. “The release happens not because conditions are always ideal, but because of the people who build it, the people who release it, and the bears ^, cats, dogs, wizards, and curious minds who keep Kubernetes sailing strong — no matter which way the wind blows.”
CNCF
Enhanced traffic distribution with locality aware routing
The open-source Kubernetes container orchestration platform is used by all the major cloud providers, with Microsoft, Google and Amazon each offering their own services. There are also multiple distributions for on-premises and private cloud deployments, including offerings from Red Hat, SUSE, Canonical and VMware. At the core of all the commercial offerings is the foundational open source project which has three releases a year, each introducing new capabilities.
Kubernetes releases include three classes of updates that are referred to as “enhancements,” including alpha, beta and graduated, with each level indicating the level of maturing and production readiness of the specific feature. Kubernetes 1.34 has 58 enhancements in total, 23 stable, 22 beta and 13 in alpha.
Each enhancement in a release is tracked through the Kubernetes Enhancement Proposal (KEP) process, which defines the problem that a given feature is intended to help solve.
One of the most persistent networking performance issues in Kubernetes since the platform was created a decade ago is non-optimized traffic routing. Kubernetes consists of nodes and clusters, and there can be a lot of east-west intra-cluster networking traffic that can impact latency and performance.
That’s one of the core challenges that KEP #3015 aims to help solve. Titled as ‘PreferSameZone and PreferSameNode Traffic Distribution’ the enhancement provides network operators with fine-grained control over traffic routing decisions within clusters. According to the KEP, the goals of the enhancement are to make traffic distribution less ambiguous. How it does that is also reasonably straightforward.
“Add a new value to allow configuring a service so that connections will be delivered to a local endpoint when possible, and a remote endpoint if not,” the KEP states.
From a technical standpoint, that goal manifests as the PreferSameNode traffic distribution feature. The spec.trafficDistribution field within a Kubernetes Service allows users to express preferences for how traffic should be routed to Service endpoints. KEP-3015 deprecates PreferClose and introduces two additional values: PreferSameZone and PreferSameNode. PreferSameZone is an alias for the existing PreferClose to clarify its semantics. PreferSameNode allows connections to be delivered to a local endpoint when possible, falling back to a remote endpoint when not possible.
This functionality addresses a critical performance optimization need in distributed systems. By enabling traffic to remain on the same node when possible, operators can reduce network latency and bandwidth consumption while maintaining service availability through intelligent fallback mechanisms.
The technical implementation works through kube-proxy, which now understands these traffic distribution preferences and makes routing decisions accordingly. When a service specifies PreferSameNode, the proxy first attempts to route traffic to endpoints running on the local node before considering remote alternatives.
DNS search path validation becomes more flexible
Network administrators operating in complex enterprise environments often struggle with DNS resolution challenges, particularly when integrating Kubernetes clusters with existing corporate DNS infrastructure. Kubernetes 1.34 addresses this through KEP #4427, which relaxes DNS search path validation.
“Previously, the strict validation of a Pod’s DNS search path in Kubernetes often created integration challenges in complex or legacy network environments,” the release announcement explains. “This restrictiveness could block configurations that were necessary for an organization’s infrastructure, forcing administrators to implement difficult workarounds.”
The technical solution provides network administrators with enhanced DNS configuration control through a specific resolver behavior modification. This configuration change prevents the Kubernetes DNS system from unnecessarily forwarding external domain queries to the cluster’s internal DNS infrastructure. The result is reduced query load on internal DNS services and eliminating potential resolution conflicts that can occur when internal and external domain namespaces overlap.
Authorization evolution enables network-aware security
Network security receives a significant upgrade through KEP #4601, which enhances authorization capabilities. The new system can now consider network selectors when making access control decisions. This advancement addresses growing security needs in multi-tenant environments.
Kubernetes authorizers are components within the Kubernetes API server that determine whether a user or entity is authorized to execute a particular action on a specific resource. With the new feature, the authorizers can now make authorization decisions based on field and label selectors in incoming requests.
The practical implications are substantial for network security architectures. Organizations can now create policies that restrict access based on network topology.
“For example, you can write an authorization policy that only allows listing Pods bound to a specific .spec.nodeName,” the release notes state. “The client (perhaps the kubelet on a particular node) must specify the field selector that the policy requires, otherwise the request is forbidden.”
This enhancement enables more sophisticated network-based access controls. It’s particularly valuable for per-node isolation scenarios. Custom multi-tenant setups also benefit where network topology plays a critical role in security boundaries.
Broader platform maturity supports network operations
Beyond specific networking enhancements, the release demonstrates the platform’s continued overall maturation. One of the biggest core improvements is the graduation of a feature known as Dynamic Resource Allocation (DRA).
“Originally, Kubernetes and its scheduler only tracked CPU and RAM as resources for containers,” KEP-4381 states. “Later, support for storage and discrete, countable per-node extended resources was added.But for many newer devices, this approach and the Kubernetes API for requesting these custom resources is too limited.”
DRA enables more sophisticated device management for networking hardware like NICs, and enhanced streaming capabilities for large-scale API operations that reduce memory pressure during network-intensive workloads.
“Dynamic Resource Allocation (DRA) enables more powerful ways to select, allocate, share, and configure GPUs, TPUs, NICs and other devices,” the release notes state.
