23 Aug 2025
Hacker News
Waitgroups: What they are, how to use them and what changed with Go 1.25
23 Aug 2025 3:21pm GMT
Using game theory to explain how institutions arise to manage limited resources
23 Aug 2025 3:15pm GMT
Show HN: I Made the Hardest Focus App
23 Aug 2025 2:01pm GMT
Linuxiac
NetBeans 27 Improves JDK 25 Compatibility, Adds Gradle 9 Fixes
Apache NetBeans 27 cross-platform IDE improves JDK 25 compatibility, adds Gradle 9 fixes, Maven 3.9.11 updates, and more.
23 Aug 2025 7:37am GMT
OMG! Ubuntu
Aviator is a Fast, User-Friendly App for AV1 Video Encoding on Linux
Heard of the AV1 (AOMedia Video 1) codec? Chances are you have, as this open source, royalty-free video compression standard is championed by the likes of Google, Netflix, Amazon, and even Apple. All for a very good reason (beyond the anyone-is-free-to-use-it-no-catches aspect). AV1 produces fantastic quality video at often significantly. smaller file sizes. For major video streaming services you can see the appeal: bandwidth means money, and a video codec that delivers decent quality but is data efficient is a no-brainer, costs-wise. But you might be interested in using it too. If you upload content to video sharing sites, AV1 […]
You're reading Aviator is a Fast, User-Friendly App for AV1 Video Encoding on Linux, a blog post from OMG! Ubuntu. Do not reproduce elsewhere without permission.
23 Aug 2025 3:20am GMT
22 Aug 2025
OMG! Ubuntu
High Tide (Linux Tidal Client) Adds Gapless Playback, Replay Gain
High Tide, a GTK4/libadawaita app for music streaming service Tidal, has been updated with a bunch of fixes and minor new features. It's also seen a major version bump, jumping from v0.1.8 to v1.0.0. Given the amount of churn between those two versions, such a leap seems fitting. App responsiveness has been improved in High Tide v1.0 through a variety of cache tweaks, reworked page loading, and assorted code cleanups, unused function removals, improvements to some of the widget APIs that are used to fetch content. The net result of all of that work isn't obvious at a glance, but […]
You're reading High Tide (Linux Tidal Client) Adds Gapless Playback, Replay Gain, a blog post from OMG! Ubuntu. Do not reproduce elsewhere without permission.
22 Aug 2025 4:20pm GMT
Linuxiac
Ahoy, This Is openSUSE
openSUSE introduces a phased plan to replace its legacy Qt5-based welcome window with a new launcher managing desktop-specific greeters.
22 Aug 2025 3:15pm GMT
FFmpeg 8.0 Arrives With Whisper Filter, Vulkan Encoders
FFmpeg 8.0 video and audio converter adds Whisper filter, Vulkan AV1 encoder, ProRes RAW support, and expanded codec handling.
22 Aug 2025 2:05pm GMT
Ubuntu blog
A complete security view for every Ubuntu LTS VM on Azure
Azure's Update Manager now shows missing Ubuntu Pro updates for all Ubuntu Long-Term Support (LTS) releases: 18.04, 20.04, 22.04 and 24.04. The feature was first introduced for only 18.04 during its move to Expanded Security Maintenance. With this addition, Azure highlights where Ubuntu LTS instances would benefit from Expanded Security Maintenance updates if the administrator […]
22 Aug 2025 12:59pm GMT
JavaScript Weekly
We still love jQuery
|
22 Aug 2025 12:00am GMT
21 Aug 2025
OMG! Ubuntu
Kdenlive 25.08 Enhances Audio Mixer, Adds 10-bit H.265 Support
Kdenlive 25.08 brings improved audio mixing, enhanced Titler, 10-bit H.265 encoding for NVIDIA GPUs, and plenty of bug fixes to this FOSS video editor.
You're reading Kdenlive 25.08 Enhances Audio Mixer, Adds 10-bit H.265 Support, a blog post from OMG! Ubuntu. Do not reproduce elsewhere without permission.
21 Aug 2025 7:26pm GMT
20 Aug 2025
Ubuntu blog
Canonical is now a platinum member in the Open Source Robotics Alliance
Ubuntu is the home of ROS. The very first ROS distribution, Box Turtle, launched on Ubuntu 8.04 LTS, Hardy Heron, and since then, Ubuntu and ROS have grown hand in hand. With every Ubuntu LTS release, a new ROS distribution follows, an intentional alignment that ensures ROS works out of the box on Ubuntu Desktop, […]
20 Aug 2025 1:48am GMT
19 Aug 2025
Kubernetes Blog
Tuning Linux Swap for Kubernetes: A Deep Dive
The Kubernetes NodeSwap feature, likely to graduate to stable in the upcoming Kubernetes v1.34 release, allows swap usage: a significant shift from the conventional practice of disabling swap for performance predictability. This article focuses exclusively on tuning swap on Linux nodes, where this feature is available. By allowing Linux nodes to use secondary storage for additional virtual memory when physical RAM is exhausted, node swap support aims to improve resource utilization and reduce out-of-memory (OOM) kills.
However, enabling swap is not a "turn-key" solution. The performance and stability of your nodes under memory pressure are critically dependent on a set of Linux kernel parameters. Misconfiguration can lead to performance degradation and interfere with Kubelet's eviction logic.
In this blogpost, I'll dive into critical Linux kernel parameters that govern swap behavior. I will explore how these parameters influence Kubernetes workload performance, swap utilization, and crucial eviction mechanisms. I will present various test results showcasing the impact of different configurations, and share my findings on achieving optimal settings for stable and high-performing Kubernetes clusters.
Introduction to Linux swap
At a high level, the Linux kernel manages memory through pages, typically 4KiB in size. When physical memory becomes constrained, the kernel's page replacement algorithm decides which pages to move to swap space. While the exact logic is a sophisticated optimization, this decision-making process is influenced by certain key factors:
- Page access patterns (how recently pages are accessed)
- Page dirtyness (whether pages have been modified)
- Memory pressure (how urgently the system needs free memory)
Anonymous vs File-backed memory
It is important to understand that not all memory pages are the same. The kernel distinguishes between anonymous and file-backed memory.
Anonymous memory: This is memory that is not backed by a specific file on the disk, such as a program's heap and stack. From the application's perspective this is private memory, and when the kernel needs to reclaim these pages, it must write them to a dedicated swap device.
File-backed memory: This memory is backed by a file on a filesystem. This includes a program's executable code, shared libraries, and filesystem caches. When the kernel needs to reclaim these pages, it can simply discard them if they have not been modified ("clean"). If a page has been modified ("dirty"), the kernel must first write the changes back to the file before it can be discarded.
While a system without swap can still reclaim clean file-backed pages memory under pressure by dropping them, it has no way to offload anonymous memory. Enabling swap provides this capability, allowing the kernel to move less-frequently accessed memory pages to disk to conserve memory to avoid system OOM kills.
Key kernel parameters for swap tuning
To effectively tune swap behavior, Linux provides several kernel parameters that can be managed via sysctl
.
vm.swappiness
: This is the most well-known parameter. It is a value from 0 to 200 (100 in older kernels) that controls the kernel's preference for swapping anonymous memory pages versus reclaiming file-backed memory pages (page cache).- High value (eg: 90+): The kernel will be aggressive in swapping out less-used anonymous memory to make room for file-cache.
- Low value (eg: < 10): The kernel will strongly prefer dropping file cache pages over swapping anonymous memory.
vm.min_free_kbytes
: This parameter tells the kernel to keep a minimum amount of memory free as a buffer. When the amount of free memory drops below the this safety buffer, the kernel starts more aggressively reclaiming pages (swapping, and eventually handling OOM kills).- Function: It acts as a safety lever to ensure the kernel has enough memory for critical allocation requests that cannot be deferred.
- Impact on swap: Setting a higher
min_free_kbytes
effectively raises the floor for for free memory, causing the kernel to initiate swap earlier under memory pressure.
vm.watermark_scale_factor
: This setting controls the gap between different watermarks:min
,low
andhigh
, which are calculated based onmin_free_kbytes
.- Watermarks explained:
low
: When free memory is below this mark, thekswapd
kernel process wakes up to reclaim pages in the background. This is when a swapping cycle begins.min
: When free memory hits this minimum level, then aggressive page reclamation will block process allocation. Failing to reclaim pages will cause OOM kills.high
: Memory reclamation stops once the free memory reaches this level.
- Impact: A higher
watermark_scale_factor
careates a larger buffer between thelow
andmin
watermarks. This giveskswapd
more time to reclaim memory gradually before the system hits a critical state.
- Watermarks explained:
In a typical server workload, you might have a long-running process with some memory that becomes 'cold'. A higher swappiness
value can free up RAM by swapping out the cold memory, for other active processes that can benefit from keeping their file-cache.
Tuning the min_free_kbytes
and watermark_scale_factor
parameters to move the swapping window early will give more room for kswapd
to offload memory to disk and prevent OOM kills during sudden memory spikes.
Swap tests and results
To understand the real-impact of these parameters, I designed a series of stress tests.
Test setup
- Environment: GKE on Google Cloud
- Kubernetes version: 1.33.2
- Node configuration:
n2-standard-2
(8GiB RAM, 50GB swap on apd-balanced
disk, without encryption), Ubuntu 22.04 - Workload: A custom Go application designed to allocate memory at a configurable rate, generate file-cache pressure, and simulate different memory access patterns (random vs sequential).
- Monitoring: A sidecar container capturing system metrics every second.
- Protection: Critical system components (kubelet, container runtime, sshd) were prevented from swapping by setting
memory.swap.max=0
in their respective cgroups.
Test methodology
I ran a stress-test pod on nodes with different swappiness settings (0, 60, and 90) and varied the min_free_kbytes
and watermark_scale_factor
parameters to observe the outcomes under heavy memory allocation and I/O pressure.
Visualizing swap in action
The graph below, from a 100MBps stress test, shows swap in action. As free memory (in the "Memory Usage" plot) decreases, swap usage (Swap Used (GiB)
) and swap-out activity (Swap Out (MiB/s)
) increase. Critically, as the system relies more on swap, the I/O activity and corresponding wait time (IO Wait %
in the "CPU Usage" plot) also rises, indicating CPU stress.
Findings
My initial tests with default kernel parameters (swappiness=60
, min_free_kbytes=68MB
, watermark_scale_factor=10
) quickly led to OOM kills and even unexpected node restarts under high memory pressure. With selecting appropriate kernel parameters a good balance in node stability and performance can be achieved.
The impact of swappiness
The swappiness parameter directly influences the kernel's choice between reclaiming anonymous memory (swapping) and dropping page cache. To observe this, I ran a test where one pod generated and held file-cache pressure, followed by a second pod allocating anonymous memory at 100MB/s, to observe the kernel preference on reclaim:
My findings reveal a clear trade-off:
swappiness=90
: The kernel proactively swapped out the inactive anonymous memory to keep the file cache. This resulted in high and sustained swap usage and significant I/O activity ("Blocks Out"), which in turn caused spikes in I/O wait on the CPU.swappiness=0
: The kernel favored dropping file-cache pages delaying swap consumption. However, it's critical to understand that this does not disable swapping. When memory pressure was high, the kernel still swapped anonymous memory to disk.
The choice is workload-dependent. For workloads sensitive to I/O latency, a lower swappiness is preferable. For workloads that rely on a large and frequently accessed file cache, a higher swappiness may be beneficial, provided the underlying disk is fast enough to handle the load.
Tuning watermarks to prevent eviction and OOM kills
The most critical challenge I encountered was the interaction between rapid memory allocation and Kubelet's eviction mechanism. When my test pod, which was deliberately configured to overcommit memory, allocated it at a high rate (e.g., 300-500 MBps), the system quickly ran out of free memory.
With default watermarks, the buffer for reclamation was too small. Before kswapd
could free up enough memory by swapping, the node would hit a critical state, leading to two potential outcomes:
- Kubelet eviction If kubelet's eviction manager detected
memory.available
was below its threshold, it would evict the pod. - OOM killer In some high-rate scenarios, the OOM Killer would activate before eviction could complete, sometimes killing higher priority pods that were not the source of the pressure.
To mitigate this I tuned the watermarks:
- Increased
min_free_kbytes
to 512MiB: This forces the kernel to start reclaiming memory much earlier, providing a larger safety buffer. - Increased
watermark_scale_factor
to 2000: This widened the gap between thelow
andhigh
watermarks (from ≈337MB to ≈591MB in my test node's/proc/zoneinfo
), effectively increasing the swapping window.
This combination gave kswapd
a larger operational zone and more time to swap pages to disk during memory spikes, successfully preventing both premature evictions and OOM kills in my test runs.
Table compares watermark levels from /proc/zoneinfo
(Non-NUMA node):
min_free_kbytes=67584KiB and watermark_scale_factor=10 |
min_free_kbytes=524288KiB and watermark_scale_factor=2000 |
---|---|
Node 0, zone Normal pages free 583273 boost 0 min 10504 low 13130 high 15756 spanned 1310720 present 1310720 managed 1265603 |
Node 0, zone Normal pages free 470539 min 82109 low 337017 high 591925 spanned 1310720 present 1310720 managed 1274542 |
The graph below reveals that the kernel buffer size and scaling factor play a crucial role in determining how the system responds to memory load. With the right combination of these parameters, the system can effectively use swap space to avoid eviction and maintain stability.
Risks and recommendations
Enabling swap in Kubernetes is a powerful tool, but it comes with risks that must be managed through careful tuning.
-
Risk of performance degradation Swapping is orders of magnitude slower than accessing RAM. If an application's active working set is swapped out, its performance will suffer dramatically due to high I/O wait times (thrashing). Swap could preferably be provisioned with a SSD backed storage to improve performance.
-
Risk of masking memory leaks Swap can hide memory leaks in applications, which might otherwise lead to a quick OOM kill. With swap, a leaky application might slowly degrade node performance over time, making the root cause harder to diagnose.
-
Risk of disabling evictions Kubelet proactively monitors the node for memory-pressure and terminates pods to reclaim the resources. Improper tuning can lead to OOM kills before kubelet has a chance to evict pods gracefully. A properly configured
min_free_kbytes
is essential to ensure kubelet's eviction mechanism remains effective.
Kubernetes context
Together, the kernel watermarks and kubelet eviction threshold create a series of memory pressure zones on a node. The eviction-threshold parameters need to be adjusted to configure Kubernetes managed evictions occur before the OOM kills.
As the diagram shows, an ideal configuration will be to create a large enough 'swapping zone' (between high
and min
watermarks) so that the kernel can handle memory pressure by swapping before available memory drops into the Eviction/Direct Reclaim zone.
Recommended starting point
Based on these findings, I recommend the following as a starting point for Linux nodes with swap enabled. You should benchmark this with your own workloads.
vm.swappiness=60
: Linux default is a good starting point for general-purpose workloads. However, the ideal value is workload-dependent, and swap-sensitive applications may need more careful tuning.vm.min_free_kbytes=500000
(500MB): Set this to a reasonably high value (e.g., 2-3% of total node memory) to give the node a reasonable safety buffer.vm.watermark_scale_factor=2000
: Create a larger window forkswapd
to work with, preventing OOM kills during sudden memory allocation spikes.
I encourage running benchmark tests with your own workloads in test-environments, when setting up swap for the first time in your Kubernetes cluster. Swap performance can be sensitive to different environment differences such as CPU load, disk type (SSD vs HDD) and I/O patterns.
19 Aug 2025 6:30pm GMT
Ubuntu blog
AMD SEV-SNP host support available on Ubuntu 25.04
Ubuntu 25.04 introduces full AMD SEV-SNP host support, making Ubuntu the first production-grade Linux distribution to deliver end-to-end confidential computing , from host to guest , without out-of-tree patches or experimental builds. With this release, enterprises can deploy confidential virtual machines on fully Ubuntu-based stacks in both private and public clouds. SEV-SNP enforces hardware-level isolation by encrypting guest memory with per-VM keys and protecting integrity through secure nest
19 Aug 2025 12:36pm GMT
08 Aug 2025
JavaScript Weekly
How JavaScript really evolves, the inside story
|
08 Aug 2025 12:00am GMT
07 Aug 2025
Kubernetes Blog
Introducing Headlamp AI Assistant
This announcement originally appeared on the Headlamp blog.
To simplify Kubernetes management and troubleshooting, we're thrilled to introduce Headlamp AI Assistant: a powerful new plugin for Headlamp that helps you understand and operate your Kubernetes clusters and applications with greater clarity and ease.
Whether you're a seasoned engineer or just getting started, the AI Assistant offers:
- Fast time to value: Ask questions like "Is my application healthy?" or "How can I fix this?" without needing deep Kubernetes knowledge.
- Deep insights: Start with high-level queries and dig deeper with prompts like "List all the problematic pods" or "How can I fix this pod?"
- Focused & relevant: Ask questions in the context of what you're viewing in the UI, such as "What's wrong here?"
- Action-oriented: Let the AI take action for you, like "Restart that deployment", with your permission.
Here is a demo of the AI Assistant in action as it helps troubleshoot an application running with issues in a Kubernetes cluster:
Hopping on the AI train
Large Language Models (LLMs) have transformed not just how we access data but also how we interact with it. The rise of tools like ChatGPT opened a world of possibilities, inspiring a wave of new applications. Asking questions or giving commands in natural language is intuitive, especially for users who aren't deeply technical. Now everyone can quickly ask how to do X or Y, without feeling awkward or having to traverse pages and pages of documentation like before.
Therefore, Headlamp AI Assistant brings a conversational UI to Headlamp, powered by LLMs that Headlamp users can configure with their own API keys. It is available as a Headlamp plugin, making it easy to integrate into your existing setup. Users can enable it by installing the plugin and configuring it with their own LLM API keys, giving them control over which model powers the assistant. Once enabled, the assistant becomes part of the Headlamp UI, ready to respond to contextual queries and perform actions directly from the interface.
Context is everything
As expected, the AI Assistant is focused on helping users with Kubernetes concepts. Yet, while there is a lot of value in responding to Kubernetes related questions from Headlamp's UI, we believe that the great benefit of such an integration is when it can use the context of what the user is experiencing in an application. So, the Headlamp AI Assistant knows what you're currently viewing in Headlamp, and this makes the interaction feel more like working with a human assistant.
For example, if a pod is failing, users can simply ask "What's wrong here?" and the AI Assistant will respond with the root cause, like a missing environment variable or a typo in the image name. Follow-up prompts like "How can I fix this?" allow the AI Assistant to suggest a fix, streamlining what used to take multiple steps into a quick, conversational flow.
Sharing the context from Headlamp is not a trivial task though, so it's something we will keep working on perfecting.
Tools
Context from the UI is helpful, but sometimes additional capabilities are needed. If the user is viewing the pod list and wants to identify problematic deployments, switching views should not be necessary. To address this, the AI Assistant includes support for a Kubernetes tool. This allows asking questions like "Get me all deployments with problems" prompting the assistant to fetch and display relevant data from the current cluster. Likewise, if the user requests an action like "Restart that deployment" after the AI points out what deployment needs restarting, it can also do that. In case of "write" operations, the AI Assistant does check with the user for permission to run them.
AI Plugins
Although the initial version of the AI Assistant is already useful for Kubernetes users, future iterations will expand its capabilities. Currently, the assistant supports only the Kubernetes tool, but further integration with Headlamp plugins is underway. Similarly, we could get richer insights for GitOps via the Flux plugin, monitoring through Prometheus, package management with Helm, and more.
And of course, as the popularity of MCP grows, we are looking into how to integrate it as well, for a more plug-and-play fashion.
Try it out!
We hope this first version of the AI Assistant helps users manage Kubernetes clusters more effectively and assist newcomers in navigating the learning curve. We invite you to try out this early version and give us your feedback. The AI Assistant plugin can be installed from Headlamp's Plugin Catalog in the desktop version, or by using the container image when deploying Headlamp. Stay tuned for the future versions of the Headlamp AI Assistant!
07 Aug 2025 7:00pm GMT
01 Aug 2025
JavaScript Weekly
Jumbo-sized JavaScript for issue 747
|
01 Aug 2025 12:00am GMT
28 Jul 2025
Kubernetes Blog
Kubernetes v1.34 Sneak Peek
Kubernetes v1.34 is coming at the end of August 2025. This release will not include any removal or deprecation, but it is packed with an impressive number of enhancements. Here are some of the features we are most excited about in this cycle!
Please note that this information reflects the current state of v1.34 development and may change before release.
Featured enhancements of Kubernetes v1.34
The following list highlights some of the notable enhancements likely to be included in the v1.34 release, but is not an exhaustive list of all planned changes. This is not a commitment and the release content is subject to change.
The core of DRA targets stable
Dynamic Resource Allocation (DRA) provides a flexible way to categorize, request, and use devices like GPUs or custom hardware in your Kubernetes cluster.
Since the v1.30 release, DRA has been based around claiming devices using structured parameters that are opaque to the core of Kubernetes. The relevant enhancement proposal, KEP-4381, took inspiration from dynamic provisioning for storage volumes. DRA with structured parameters relies on a set of supporting API kinds: ResourceClaim, DeviceClass, ResourceClaimTemplate, and ResourceSlice API types under resource.k8s.io
, while extending the .spec
for Pods with a new resourceClaims
field. The core of DRA is targeting graduation to stable in Kubernetes v1.34.
With DRA, device drivers and cluster admins define device classes that are available for use. Workloads can claim devices from a device class within device requests. Kubernetes allocates matching devices to specific claims and places the corresponding Pods on nodes that can access the allocated devices. This framework provides flexible device filtering using CEL, centralized device categorization, and simplified Pod requests, among other benefits.
Once this feature has graduated, the resource.k8s.io/v1
APIs will be available by default.
ServiceAccount tokens for image pull authentication
The ServiceAccount token integration for kubelet
credential providers is likely to reach beta and be enabled by default in Kubernetes v1.34. This allows the kubelet
to use these tokens when pulling container images from registries that require authentication.
That support already exists as alpha, and is tracked as part of KEP-4412.
The existing alpha integration allows the kubelet
to use short-lived, automatically rotated ServiceAccount tokens (that follow OIDC-compliant semantics) to authenticate to a container image registry. Each token is scoped to one associated Pod; the overall mechanism replaces the need for long-lived image pull Secrets.
Adopting this new approach reduces security risks, supports workload-level identity, and helps cut operational overhead. It brings image pull authentication closer to modern, identity-aware good practice.
Pod replacement policy for Deployments
After a change to a Deployment, terminating pods may stay up for a considerable amount of time and may consume additional resources. As part of KEP-3973, the .spec.podReplacementPolicy
field will be introduced (as alpha) for Deployments.
If your cluster has the feature enabled, you'll be able to select one of two policies:
TerminationStarted
- Creates new pods as soon as old ones start terminating, resulting in faster rollouts at the cost of potentially higher resource consumption.
TerminationComplete
- Waits until old pods fully terminate before creating new ones, resulting in slower rollouts but ensuring controlled resource consumption.
This feature makes Deployment behavior more predictable by letting you choose when new pods should be created during updates or scaling. It's beneficial when working in clusters with tight resource constraints or with workloads with long termination periods.
It's expected to be available as an alpha feature and can be enabled using the DeploymentPodReplacementPolicy
and DeploymentReplicaSetTerminatingReplicas
feature gates in the API server and kube-controller-manager.
Production-ready tracing for kubelet
and API Server
To address the longstanding challenge of debugging node-level issues by correlating disconnected logs, KEP-2831 provides deep, contextual insights into the kubelet
.
This feature instruments critical kubelet
operations, particularly its gRPC calls to the Container Runtime Interface (CRI), using the vendor-agnostic OpenTelemetry standard. It allows operators to visualize the entire lifecycle of events (for example: a Pod startup) to pinpoint sources of latency and errors. Its most powerful aspect is the propagation of trace context; the kubelet
passes a trace ID with its requests to the container runtime, enabling runtimes to link their own spans.
This effort is complemented by a parallel enhancement, KEP-647, which brings the same tracing capabilities to the Kubernetes API server. Together, these enhancements provide a more unified, end-to-end view of events, simplifying the process of pinpointing latency and errors from the control plane down to the node. These features have matured through the official Kubernetes release process. KEP-2831 was introduced as an alpha feature in v1.25, while KEP-647 debuted as alpha in v1.22. Both enhancements were promoted to beta together in the v1.27 release. Looking forward, Kubelet Tracing (KEP-2831) and API Server Tracing (KEP-647) are now targeting graduation to stable in the upcoming v1.34 release.
PreferSameZone
and PreferSameNode
traffic distribution for Services
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 equivalent to the current PreferClose
. PreferSameNode
prioritizes sending traffic to endpoints on the same node as the client.
This feature was introduced in v1.33 behind the PreferSameTrafficDistribution
feature gate. It is targeting graduation to beta in v1.34 with its feature gate enabled by default.
Support for KYAML: a Kubernetes dialect of YAML
KYAML aims to be a safer and less ambiguous YAML subset, and was designed specifically for Kubernetes. Whatever version of Kubernetes you use, you'll be able use KYAML for writing manifests and/or Helm charts. You can write KYAML and pass it as an input to any version of kubectl
, because all KYAML files are also valid as YAML. With kubectl v1.34, we expect you'll also be able to request KYAML output from kubectl
(as in kubectl get -o kyaml …
). If you prefer, you can still request the output in JSON or YAML format.
KYAML addresses specific challenges with both YAML and JSON. YAML's significant whitespace requires careful attention to indentation and nesting, while its optional string-quoting can lead to unexpected type coercion (for example: "The Norway Bug"). Meanwhile, JSON lacks comment support and has strict requirements for trailing commas and quoted keys.
KEP-5295 introduces KYAML, which tries to address the most significant problems by:
-
Always double-quoting value strings
-
Leaving keys unquoted unless they are potentially ambiguous
-
Always using
{}
for mappings (associative arrays) -
Always using
[]
for lists
This might sound a lot like JSON, because it is! But unlike JSON, KYAML supports comments, allows trailing commas, and doesn't require quoted keys.
We're hoping to see KYAML introduced as a new output format for kubectl
v1.34. As with all these features, none of these changes are 100% confirmed; watch this space!
As a format, KYAML is and will remain a strict subset of YAML, ensuring that any compliant YAML parser can parse KYAML documents. Kubernetes does not require you to provide input specifically formatted as KYAML, and we have no plans to change that.
Fine-grained autoscaling control with HPA configurable tolerance
KEP-4951 introduces a new feature that allows users to configure autoscaling tolerance on a per-HPA basis, overriding the default cluster-wide 10% tolerance setting that often proves too coarse-grained for diverse workloads. The enhancement adds an optional tolerance
field to the HPA's spec.behavior.scaleUp
and spec.behavior.scaleDown
sections, enabling different tolerance values for scale-up and scale-down operations, which is particularly valuable since scale-up responsiveness is typically more critical than scale-down speed for handling traffic surges.
Released as alpha in Kubernetes v1.33 behind the HPAConfigurableTolerance
feature gate, this feature is expected to graduate to beta in v1.34. This improvement helps to address scaling challenges with large deployments, where for scaling in, a 10% tolerance might mean leaving hundreds of unnecessary Pods running. Using the new, more flexible approach would enable workload-specific optimization for both responsive and conservative scaling behaviors.
Want to know more?
New features and deprecations are also announced in the Kubernetes release notes. We will formally announce what's new in Kubernetes v1.34 as part of the CHANGELOG for that release.
The Kubernetes v1.34 release is planned for Wednesday 27th August 2025. Stay tuned for updates!
Get involved
The simplest way to get involved with Kubernetes is to join one of the many Special Interest Groups (SIGs) that align with your interests. Have something you'd like to broadcast to the Kubernetes community? Share your voice at our weekly community meeting, and through the channels below. Thank you for your continued feedback and support.
- Follow us on Bluesky @kubernetes.io for the latest updates
- Join the community discussion on Discuss
- Join the community on Slack
- Post questions (or answer questions) on Server Fault or Stack Overflow
- Share your Kubernetes story
- Read more about what's happening with Kubernetes on the blog
- Learn more about the Kubernetes Release Team
28 Jul 2025 12:00am GMT