Introducing Headlamp AI Assistant

https://kubernetes.io/blog/2025/08/07/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!

via Kubernetes Blog https://kubernetes.io/

August 07, 2025 at 03:00PM

Ep31 - Ask Me Anything About Anything with Scott Rosenberg

There are no restrictions in this AMA session. You can ask anything about DevOps, AI, Cloud, Kubernetes, Platform Engineering, containers, or anything else. Scott Rosenberg, regular guest, will be here to help us out.

▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬ Sponsor: Codefresh 🔗 GitOps Argo CD Certifications: https://learning.codefresh.io (use "viktor" for a 50% discount) ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬

▬▬▬▬▬▬ 👋 Contact me 👋 ▬▬▬▬▬▬ ➡ BlueSky: https://vfarcic.bsky.social ➡ LinkedIn: https://www.linkedin.com/in/viktorfarcic/

▬▬▬▬▬▬ 🚀 Other Channels 🚀 ▬▬▬▬▬▬ 🎤 Podcast: https://www.devopsparadox.com/ 💬 Live streams: https://www.youtube.com/c/DevOpsParadox

via YouTube https://www.youtube.com/watch?v=8TKvzwLIYSQ

MCP Servers Explained: Why Most Are Useless (And How to Fix It)

95% of MCP servers are essentially a waste of time. Many are slower and more complex than the terminal tools agents can already use effectively. But the remaining 5% are game-changers that unlock new, powerful AI capabilities. This video reveals exactly why most MCPs fail, how to identify and avoid redundant architectures, and the right way to build MCPs that truly matter.

Using clear analogies and real-world examples, you'll learn how to design MCP servers that directly reflect user intentions, provide access to otherwise inaccessible services, and combine deterministic code with intelligent agent-driven workflows. By the end, you'll understand the critical architecture and data flow patterns that separate revolutionary MCP servers from redundant ones, enabling you to create AI agents that accomplish complex tasks with ease.

▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬ Sponsor: Outskill 👉 Grab your free seat to the 2-Day AI Mastermind: https://link.outskill.com/AIDEVAG2 🔐 100% Discount for the first 1000 people 💥 Dive deep into AI and Learn Automations, Build AI Agents, Make videos & images – all for free! 🎁 Bonuses worth $5100+ if you join and attend ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬

AI #MCP #SoftwareArchitecture

Consider joining the channel: https://www.youtube.com/c/devopstoolkit/join

▬▬▬▬▬▬ 💰 Sponsorships 💰 ▬▬▬▬▬▬ If you are interested in sponsoring this channel, please visit https://devopstoolkit.live/sponsor for more information. Alternatively, feel free to contact me over Twitter or LinkedIn (see below).

▬▬▬▬▬▬ 👋 Contact me 👋 ▬▬▬▬▬▬ ➡ BlueSky: https://vfarcic.bsky.social ➡ LinkedIn: https://www.linkedin.com/in/viktorfarcic/

▬▬▬▬▬▬ 🚀 Other Channels 🚀 ▬▬▬▬▬▬ 🎤 Podcast: https://www.devopsparadox.com/ 💬 Live streams: https://www.youtube.com/c/DevOpsParadox

▬▬▬▬▬▬ ⏱ Timecodes ⏱ ▬▬▬▬▬▬ 00:00 Introduction to Model Context Protocol (MCP) 01:38 Outskill (sponsor) 03:09 What is the Model Context Protocol (MCP)? 07:06 Why Most MCPs Fail 13:24 MCP Architecture That Works 20:14 MCP Server Design Patterns 25:02 MCP Data Flow Patterns 37:24 Summary

via YouTube https://www.youtube.com/watch?v=7baGJ1bC9zE

Week Ending July 27, 2025

https://lwkd.info/2025/20250730

Developer News

Due to low attendance and frequent cancellations, SIG Release is seeking a better meeting time via a Doodle poll, open until August 3, 2025 (AOE). This applies only to the main SIG Release meeting, not Release Team meetings. Changes will begin the week of August 18, 2025.

A security vulnerability was found in Kubernetes where an unauthorized user may be able to SSH/RDP/WINRM to Windows VMs built with Kubernetes Image Builder. Clusters using Image Builder version v0.1.44 or earlier are affected, specifically when using Windows images built with Nutanix OVA. Images from other providers are not affected.

Release Schedule

Next Deadline: Docs freeze, August 6

Kubernetes v1.34 has entered Code Freeze as of July 25, 2025. Only release-blocking issues and PRs will be accepted into the v1.34 milestone. Enhancements that didn’t meet the criteria have been removed, but exceptions can be requested if necessary. Key deadlines include August 6 for the docs freeze. For concerns, contact the release team via email or the #sig-release Slack channel. Make sure to get your docs PRs reviewed and merged before the upcoming docs freeze deadline!

Featured PRs

133157: KEP 4033: Add metric for out of support CRI and bump feature to GA

This PR graduates the KubeletCgroupDriverFromCRI feature to GA in v1.34; It finalizes a multi-release effort that allows the kubelet to retrieve the cgroup driver configuration directly from the container runtime using the CRI API; This improves consistency between kubelet and container runtime settings and removes the need for manual configuration alignment; A new metric has been added to report when the runtime does not support the Status.cgroupDriver field in its CRI response, helping identify unsupported or outdated CRI implementations.

133136: feat: Add warnings for unrecognized formats in CRDs

This PR updates how Kubernetes handles custom resource definitions (CRDs) that include format values; When a CRD contains a format value that isn’t recognized, the API server now returns a warning during create or update; The CRD is still accepted, but the warning helps you identify issues such as typos or unsupported values.

133105: KEP-5229: Run Unschedulable scheduler_perf test case with SchedulerAsyncAPICalls feature gate enabled

This PR adds new test configurations that specifically toggle SchedulerAsyncAPICalls for the _QueueingHintsEnabled scenarios within the Unschedulable test; These tests measure how the scheduler performs when pods cannot be scheduled, and toggling this feature gate helps validate behavior under different configurations.

KEP of the Week

KEP-961: Implement maxUnavailable in StatefulSet

This KEP enhances StatefulSet rolling updates by introducing the maxUnavailable setting, allowing multiple pods to be updated simultaneously instead of the default one-by-one strategy. It aims to speed up rollouts for large applications while respecting minReadySeconds to maintain availability. The StatefulSet controller is improved to better track pod readiness, and metrics like statefulset_unavailability_violation along with event logs help diagnose rollout issues.

Other Merges

PSA added for blocking .host on pod probes

Aggregated API server discovery supports EndpointSlices

Kubelet monitors device health via DRA and reports it in pod.status.containerStatuses.allocatedResourcesStatus field

pkg/kubelet/winstats and pkg/kubelet/volumemanager migrated to contextual logging

PodLevelResources propagate Pod level hugepage cgroup to containers

Optional APIs in ResouceSlice.Basic and ResourceClaim.Status.AllocatedDeviceStatus added

pvc.spec.VolumeAttributesClassName goes from non-nil to nil

Pod availability checks at the correct time in ReplicaSets

Scheduler interfaces moved from pkg/scheduler/framework to staging repo

kube-apiserver allows white-spaced CABundle during webhook client creation and validation

APIVersion fields of the HPA are validated to ensure created API objects function properly

Allows setting any FQDN as the pod’s hostname

Useful endpoints added for kube-apiserver

Machine readable output options (JSON & YAML) added to kubectl api-resources

PodLevelResources updates Downward API defaulting for resource limits

RV check added on GC delete calls

Container restart policy rules implemented

DRA kubelet adds v1 gRPC

Removed deprecated gogo protocol definitions from k8s.io/kubelet/pkg/apis/pluginregistration in favor of protoc

Runtime cost estimation fix for IntOrString custom resource schemas with maximum length

Kubernetes to return an error if user namespaces are used with volumeDevices

API calls sent through dispatcher and cache

Kubelet: metrics for userns pod creations and failures

Pod rejected when attachment limit is exceeded

KYAML support added to kubectl

debug_redact added to cri api secrets

Metrics added for monitoring async API calls in the scheduler when the SchedulerAsyncAPICalls is enabled

Fix for handle corner cases in the async preemption

Bumped DRA API version to “v1” in “deviceattribute” package in k8s.io/dynamic-resource-allocation

BoundedFrequencyRunner dropped from pkg/util/async

Promotions

VolumeAttributesClass to GA

DRAPrioritizedList to Beta

DRA API to GA

PSI metrics to Beta

kubeletPodResources to Beta

Windows graceful shutdown to Beta

DRAAdminAccess to Beta

Version Updates

Bumped external snapshotter for vgs tests

Bumped etcd sdk to v3.6.4

kustomize to v5.7.0

Subprojects and Dependency Updates

containerd/containerd 1.7.28: The twenty-eighth patch release for containerd 1.7 contains various fixes and updates.

kustomize kyaml/v0.20.1: drop shlex dependency.

cluster-api v1.11.0-beta.0: releases beta version for testing

Shoutouts

Patrick Ohly: Shoutout to @alaypatel07 for tackling the problem of setting up scale tests for DRA. He identified and resolved several bottlenecks, both in the cluster configuration and the Kubernetes source code. He presented at the WG Device Management meeting today and we were happy enough with the preliminary results that graduation to GA is no longer blocked, thanks to @alaypatel07! Also thanks to everyone who has supported him: @jackfrancis, @nojnhuh, @wojtekt and probably others that I don’t know about

Maciej Szulik: Huge shoutout to @Edwin Hernandez and @Heba for their help pushing KEP 961 forward, especially that this is one of the oldest and longest running features

Benjamin Elder: Thanks to @danwinship for quickly looking into and fixing a conformance test flake in SIG Network

Benjamin Elder: Thanks @jasonbraganza for tirelessly handling new member requests

via Last Week in Kubernetes Development https://lwkd.info/

July 30, 2025 at 03:17PM

Ep30 - Ask Me Anything About Anything with Scott Rosenberg

There are no restrictions in this AMA session. You can ask anything about DevOps, AI, Cloud, Kubernetes, Platform Engineering, containers, or anything else. Scott Rosenberg, regular guest, will be here to help us out.

▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬ Sponsor: Codefresh 🔗 GitOps Argo CD Certifications: https://learning.codefresh.io (use "viktor" for a 50% discount) ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬

▬▬▬▬▬▬ 👋 Contact me 👋 ▬▬▬▬▬▬ ➡ BlueSky: https://vfarcic.bsky.social ➡ LinkedIn: https://www.linkedin.com/in/viktorfarcic/

▬▬▬▬▬▬ 🚀 Other Channels 🚀 ▬▬▬▬▬▬ 🎤 Podcast: https://www.devopsparadox.com/ 💬 Live streams: https://www.youtube.com/c/DevOpsParadox

via YouTube https://www.youtube.com/watch?v=Z_l6oj4OGzE

Can AI Replace Your Terraform Modules? Infrastructure's New Future?

Watch AI agents redefine infrastructure management by learning from their mistakes and building complex setups from scratch—no golden paths required. In this video, you'll witness an AI first deploy an application using a pre-built abstraction with ease, then tackle the daunting task of assembling a database entirely from raw cloud APIs. Through trial, error, and adaptive learning, the AI evolves from making basic mistakes to successfully provisioning intricate resources—all without pre-built templates or human-crafted abstractions.

Explore the implications for platform engineering as we ask crucial questions: Do we still need meticulously crafted golden paths, or can AI build better solutions on the fly? How can Kubernetes and API discovery empower AI to independently manage infrastructure? And most importantly, are we ready for a future where AI agents autonomously handle complex infrastructure challenges, learning and adapting in real-time?

▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬ Sponsor: TestSprite 🔗 https://testsprite.com ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬

PlatformEngineering #AIInfrastructure #kubernetes

Consider joining the channel: https://www.youtube.com/c/devopstoolkit/join

▬▬▬▬▬▬ 🔗 Additional Info 🔗 ▬▬▬▬▬▬ ➡ Transcript and commands: https://devopstoolkit.live/ai/can-ai-replace-your-terraform-modules-infrastructures-new-future 🔗 Claude Code: https://anthropic.com/claude-code 🎬 Forget CLIs and GUIs: AI is the New Interface for Developer Platforms: https://youtu.be/ApjnCa-a2xI

▬▬▬▬▬▬ 💰 Sponsorships 💰 ▬▬▬▬▬▬ If you are interested in sponsoring this channel, please visit https://devopstoolkit.live/sponsor for more information. Alternatively, feel free to contact me over Twitter or LinkedIn (see below).

▬▬▬▬▬▬ 👋 Contact me 👋 ▬▬▬▬▬▬ ➡ BlueSky: https://vfarcic.bsky.social ➡ LinkedIn: https://www.linkedin.com/in/viktorfarcic/

▬▬▬▬▬▬ 🚀 Other Channels 🚀 ▬▬▬▬▬▬ 🎤 Podcast: https://www.devopsparadox.com/ 💬 Live streams: https://www.youtube.com/c/DevOpsParadox

▬▬▬▬▬▬ ⏱ Timecodes ⏱ ▬▬▬▬▬▬ 00:00 Introduction 01:58 TestSprite (sponsor) 03:20 The Testing Ground 05:55 AI Deploys Apps 10:15 Database Without Safety Nets 14:48 The AI Prompts 16:07 Platform Engineering's Future

via YouTube https://www.youtube.com/watch?v=F2Qis5cmwT8

Kubernetes v1.34 Sneak Peek

https://kubernetes.io/blog/2025/07/28/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

Week Ending July 20, 2025

https://lwkd.info/2025/20250723

Developer News

Code Freeze and Test Freeze for the Kubernetes v1.34 release begins at 02:00 UTC on Friday, July 25, 2025 (7:00 PM PDT on Thursday, July 24, 2025). Developers should ensure that all pull requests for KEPs and major changes targeting v1.34 are merged by the deadline.

Release Schedule

Next Deadline: Code and Test Freeze, July 24/25

Code and Test Freeze starts this week at 0200 UTC on Friday, July 25. Your PRs should all be merged by then. If you think you may miss the deadline, file an exception request.

Featured PRs

51630: Add Hugo Segments for Faster Local Website Builds

This PR introduces support for Hugo segments, allowing users to render specific parts of the Kubernetes website locally; For example, the build can be limited to English (en) or Persian (fa) content instead of rendering the entire site; This significantly reduces build time and resource usage when previewing documentation changes.

The default method make container-serve continues to build the whole site.

To build a specific segment, users can use the following commands

make container-serve segments=en # To build individual segments make container-serve segments=en,fa # To build multiple segments

131700: Add Support for CEL Extended Lists Library

This PR adds the support for using CEL extended lists library in Kubernetes by integrating upstream support from cel-go. This adds new list functions that allow more advanced list operations in CEL expressions. These functions can improve how conditions are written in features that use CEL-based evaluation, such as admission control and CRD validations.

KEP of the Week

KEP-5080: Ordered Namespace Deletion

This KEP introduces a secure and deterministic mechanism for deleting Kubernetes namespaces. The motivation comes from security and operational concerns with the current semi-random deletion order — for example, pods might continue running after their protecting NetworkPolicy is removed. This KEP ensures that all pods are deleted first and only then are the remaining resources removed, reducing the risk of exposed workloads. It is implemented through a feature gate OrderedNamespaceDeletion that enforces this opinionated deletion order during namespace cleanup.

This KEP is tracked as stable in v1.34

Other Merges

DRA: fixes watch handling on apiserver restart when conversion is needed

CSR declarative validation enabled for /status and /approval

e2e test added for DRA Admin Access

LIST request estimation accounts for maximum object size and caching

APF max seats to 100 for LIST request

deviceplugin and podresources APIs in kubelet from gogo to protoc

InPlacePodVerticalScaling kubelet_container_resize_requests_total metric to include all resize-related updates

Jitter added to periodic storage processes to reduce synchronized execution

InPlacePodVerticalScaling to retry pending resizes only if aggregated requests decrease

kubeadm: generate default etcd command based on etcd version

Optional listMapKeys supported in server-side apply for associative lists

In kubectl describe pod, port names are now included alongside port numbers when specified in the pod spec

kubelet_credential_provider_config_info metric reports credential provider config hash

CSR.status.conditions in v1 and v1beta1 enforce approved/denied exclusivity with declarative validation tags

Support reducing memory limits via NotRequired restart policy, with safeguards against OOM kills

e2e test for batch pod deletion in kubelet

Union validation rule tags added and +k8s:item chaining enabled in validation-gen

PodCPUAndMemoryStats added to the stats.Provider interface for fetching the CPU & memory stats for a single pod

apiserver_storage_objects metric is deprecated and replaced by apiserver_resource_objects with consistent labels

claimsToAllocate is passed through Allocate instead of NewAllocator

Memory tracking functionality added to the scheduler performance tests

kubelet: Instrumentation for in-place pod resize

Test coverage increased for pkg/kubelet/types

Fix for CPUManager non-regression test to handle CPU quota edge cases

InPlacePodVerticalScaling adds an event for pod resize completion

Fix for incorrect label key used in PodTopologyLabelAdmission, blocking beta graduation

kubelet supports contextual logging, and components including apis, kubeletconfig, nodeshutdown, pod, preemption, and memory manager have been migrated to use it

kuberuntime migrated to contextual logging

Image pull credential verification enabled for service account–based credential providers

Mirror pods test for generation and observedGeneration

More complex e2e test created for deferred resizes

DRA filter plugin times out after 10s to avoid long scheduling delays, configurable via FilterTimeout

Pause version updated to registry.k8s.io/pause:3.10.1

kube-apiserver support for PodCertificateRequest and PodCertificate projected volumes enabled

Warnings added for headless service using loadBalancerIP, externalIPs, or sessionAffinity

last_config_info metric added for authn, authz and encryption config

Promotions

PodLifecycleSleepAction to GA

NodeSwap to GA

Recovery feature to GA

PodObservedGenerationTracking to beta

WatchList to beta

API Server Tracing to GA

KubeletServiceAccountTokenForCredentialProviders to beta

ListFromCacheSnapshot to beta

Version Updates

Bumped cel-go to v0.26.0

Subprojects and Dependency Updates

cluster-api v1.11.0-beta.0: releases beta version for testing

via Last Week in Kubernetes Development https://lwkd.info/

July 23, 2025 at 05:38AM