Kubernetes Blog - TheNote.app

Kubernetes Blog
Follow

The official homepage of Kubernetes, a container orchestration system for automating deployment, scaling, and management of containerized applications. This platform offers comprehensive documentation on Kubernetes, a project maintained by Cloud Native Computing Foundation. It includes details about running stateless and stateful applications, batch jobs, and CI/CD workflows using Kubernetes. The site includes detailed guides, tutorials, reference material, API documentation, and community engagement initiatives to help users get started with Kubernetes and leverage its features effectively to manage cloud-based applications efficiently.

Kubernetes Blog kubernetes.io

RSS kubernetes.io

RSS Hunter • Aug 19, 2024

Thread Of Notes

How to Pretty-Print Your Kubernetes YAML as KYAML and Why You'd Want To

KYAML offers a stricter, more consistent way to write Kubernetes manifests, addressing issues found in standard YAML. Designed as a subset of YAML, KYAML maintains compatibility with existing parsers while narrowing stylistic choices. It aims to prevent common traps, such as whitespace sensitivity and silent type coercion, which can lead to unexpected behavior. Unlike standard YAML, KYAML explicitly defines structure and types, using braces for maps and brackets for lists. It mandates quoting string values to avoid silent type conversions, like the "Norway Bug" where "NO" is parsed as boolean false. KYAML also supports comments and trailing commas, improving the configuration writing experience compared to JSON. Kubernetes 1.34+ allows generating KYAML output via kubectl -o kyaml. Tools like sigs.k8s.io/yamlfmt and google/yamlfmt can convert existing YAML files to KYAML format. Adopting KYAML is a choice for greater consistency and fewer errors, especially in team environments, without requiring changes to existing Kubernetes tools or pipelines. It is a new habit for writing more robust configurations, not a mandatory migration.

https://kubernetes.io/blog/2026/08/11/how-to-pretty-print-kubernetes-yaml-as-kyaml/ kubernetes.io

RSS Hunter • Aug 11

Gateway API v1.6: TCPRoute and UDPRoute Graduate to Standard

The Kubernetes Gateway API has released version 1.6.0, enhancing its capabilities for service networking. This new release marks a significant advancement by standardizing layer 4 protocol routing. Previously, Gateway API's stable foundation was primarily for HTTP and TLS traffic. Version 1.6.0 now brings TCPRoute and UDPRoute resources to the stable, version 1 API. These resources allow routing for raw TCP and UDP traffic, addressing a gap for workloads like databases and IoT telemetry. Experimental innovation is also being streamlined with clearer API boundaries. New experimental resources now reside in a separate API group, gateway.networking.x-k8s.io, and use an 'X' prefix. This distinction makes experimental and standard resources easier to identify. The XBackend resource, for instance, is a new experimental addition enabling extended backend configurations. It allows for destinations like ExternalHostname, which were previously problematic for the stable Service resource. This experimental feature is designed for use cases like egress traffic to cloud APIs. The graduation of TCP and UDP routing to standard solidifies Gateway API as a universal networking solution. Users can now adopt version 1.6.0 with various compatible Gateway controller implementations. The Gateway API community encourages feedback and contributions from users and developers.

https://kubernetes.io/blog/2026/08/03/gateway-api-v1-6-release/ kubernetes.io

RSS Hunter • Aug 3

Kubernetes v1.37 Sneak Peek

Kubernetes v1.37 is nearing its release with several planned changes. The --filename/-f flag for kubectl run will be deprecated. Static Pods can no longer directly reference Secrets or ConfigMaps due to a bug fix. Kube-proxy's support for IPVS mode is being deprecated and will be removed by v1.43. Support for cgroup v1 is being phased out, and users should migrate to cgroup v2. SELinux volume relabeling, known as SELinuxMount, is graduating to General Availability. The metrics.k8s.io API is also graduating to GA after being in Beta for nearly nine years. Kubelet in User Namespace, or Rootless Mode, is expected to graduate to Beta. A volume health monitor feature is being reintroduced to Alpha with new CSI RPCs. These changes aim to improve the maintenance and health of Kubernetes environments.

https://kubernetes.io/blog/2026/07/31/kubernetes-v1-37-sneak-peek/ kubernetes.io

RSS Hunter • Jul 31

How the controller-runtime Cache Actually Works, and Why Your Controller Does Not Crash the API Server

Kubernetes controllers, commonly written in Go with kubebuilder and controller-runtime, offer efficient development for distributed workloads. However, as load increases, understanding controller-runtime's internal workings becomes crucial to avoid production issues. The core concept is that r.Get() and r.List() within a reconciler do not directly query the API server; instead, they access a local, in-memory cache. This cache is populated initially by a list operation and subsequently maintained through watches.This design makes local reads exceptionally fast, avoiding strain on the control plane. The trade-off, however, is that the local cache can consume significant memory and may return stale data. Writes, conversely, are always directed to the API server, bypassing the cache. The size of this local cache and the indexing strategies directly impact memory usage. An inefficient List() operation can inadvertently lead to slow linear scans of numerous objects.The reconciliation loop continuously compares desired states with actual states to bring them into alignment. Events are queued, leading to a reconcile function that reads the current state, determines necessary actions, and potentially generates new events. The cache's primary purpose is to provide a rapid, up-to-date view of object states for these reconciliation loops. This watch-based model, originating from client-go, prevents constant API polling by maintaining a single, long-lived connection for updates.controller-runtime abstracts the complexities of lower-level client-go components like Reflector, DeltaFIFO, and Indexer. The Manager orchestrates the shared cache, controllers, and other services. An Informer monitors a specific GVK, maintaining a local store (Indexer) and dispatching events to subscribers. ResourceEventHandlers process these events, updating the store, which is then reflected in the controller's view. A workqueue manages object keys for processing by workers, and Predicates filter events before enqueueing.The Reflector is the sole component directly interacting with the API server, performing an initial list and then establishing a watch. It leverages resourceVersion to resume watches and ensure no events are missed. If a watch connection is lost or the API server indicates an outdated resourceVersion, a relist is performed. DeltaFIFO acts as an ordered buffer for changes, grouping deltas by object key. It provides all accumulated changes for an object since the last Pop() call, ensuring ordered, batched processing. However, it does not collapse consecutive "Added" or "Updated" events, which could lead to multiple processing rounds for rapidly changing objects.

https://kubernetes.io/blog/2026/07/29/controller-runtime-cache-explained/ kubernetes.io

RSS Hunter • Jul 29

Building a Custom Metrics Exporter for Kubernetes

Kubernetes scales based on CPU and memory, but real-world demands often require custom metrics like queue depth or active connections. A Prometheus metrics exporter bridges this gap by exposing application state as plain text on an HTTP /metrics endpoint for Prometheus to scrape.Exporters can be standalone services or embedded directly within an application, depending on the data source and control over application code. Prometheus expects metrics in specific formats: counters for ever-increasing values, gauges for fluctuating values, and histograms for distributions. Metric names should follow a clear " __ " snake_case convention. Building an exporter in Go involves initializing a module, setting up the Prometheus client library, and registering metrics like counters, gauges, and histograms. These metrics are then updated by a polling loop that reads from your application's data sources. An HTTP server exposes the /metrics endpoint, along with a /healthz endpoint for liveness probes. The exporter is packaged into a minimal container image using a multi-stage Docker build, ensuring a small footprint. Deployment to a Kubernetes cluster involves a Deployment for pod management and a Service to provide a stable address for Prometheus. Prometheus discovers these metrics via a ServiceMonitor if using the Prometheus Operator, or through annotation-based discovery on the Pod template. Verification involves checking the Prometheus targets page to ensure the exporter is "UP" and querying the metrics in the expression browser. This foundation allows for autoscaling with the HorizontalPodAutoscaler, which uses a metrics adapter (like the Prometheus Adapter) to integrate custom metrics with the Kubernetes Custom Metrics API. This enables workloads to scale based on business-relevant signals, not just basic resource utilization.

https://kubernetes.io/blog/2026/07/14/custom-metrics-exporter-kubernetes/ kubernetes.io

RSS Hunter • Jul 14

Operating AI/ML Workloads on Kubernetes: A Headlamp Plugin for Kubeflow

Kubernetes is increasingly the default platform for AI and machine learning workloads. Kubeflow is a popular tool that leverages Kubernetes' Custom Resource Definitions (CRDs) for managing these ML tasks. While Kubeflow's specialized dashboards help data scientists, they often obscure the underlying Kubernetes layer, forcing operators to use kubectl for troubleshooting. The Headlamp Kubeflow plugin bridges this gap by displaying Kubeflow's custom resources directly within a general-purpose Kubernetes UI. This allows operators to observe and manage ML resources using the same primitives as other cluster components. Headlamp itself is an extensible Kubernetes web UI maintained under Kubernetes SIG UI. The plugin provides cluster-level insights by directly querying the Kubernetes API server, offering details on Pod conditions, failure reasons, and resource states across namespaces. It supports various Kubeflow components like Notebooks, Pipelines, Katib for hyperparameter tuning, Training, and Spark. The plugin allows inspection of notebook Pod details, Katib trial statuses, and pipeline states without relying on Kubeflow's backend database. It also maps ML resources as graph nodes within Headlamp, visualizing relationships between them. This approach demonstrates a pattern for any CRD-heavy platform to provide operators with essential cluster-level visibility directly within their familiar tools.

https://kubernetes.io/blog/2026/07/13/introducing-headlamp-plugin-for-kubeflow/ kubernetes.io

RSS Hunter • Jul 13

Kubernetes Dashboard to Headlamp: A Step-by-Step Guide

Kubernetes Dashboard and Headlamp offer cluster visibility but function differently. Headlamp is a desktop or in-cluster client that uses kubeconfig to connect to multiple clusters, respecting user identity. Kubernetes Dashboard is an in-cluster web app typically accessed via token authentication. To migrate, document current Dashboard usage, verify kubeconfig works, and choose a rollout plan like parallel rollout. Decide whether Headlamp will run on your desktop or within the cluster, with desktop being faster for individual use and in-cluster better for shared access. Desktop installation is straightforward via package managers, while in-cluster installation uses Helm or YAML manifests. Authentication for desktop Headlamp relies on kubeconfig, while in-cluster setups often use OpenID Connect (OIDC) or an external auth layer for sign-in. RBAC permissions are respected by Headlamp, meaning users only see and can perform actions they are authorized for. Headlamp excels at multi-cluster management, allowing users to switch between clusters directly within the UI using their kubeconfig. This provides a more integrated experience compared to the single-cluster focus of Kubernetes Dashboard.

https://kubernetes.io/blog/2026/07/13/kubernetes-dashboard-to-headlamp/ kubernetes.io

RSS Hunter • Jul 13

Announcing etcd v3.7.0

SIG etcd announces the release of etcd v3.7.0, a significant update to the distributed key-value store. This release introduces the much-anticipated RangeStream feature, enabling efficient streaming of large result sets. It also delivers various performance enhancements, including faster lease operations and optimized keys-only range requests. The legacy v2 store dependency has been fully eliminated, with etcd now booting exclusively from v3store, simplifying operations. A comprehensive protobuf overhaul replaces outdated libraries with supported versions, improving security and maintainability. The release also updates core dependencies, bbolt to v1.5.1 and raft to v3.7.0. Further improvements include support for Unix sockets for local development and testing. etcdutl commands now feature timeout arguments to prevent indefinite blocking. Client v3 offers more authentication flexibility with direct JWT setting and the ability to retrieve AuthStatus without prior authentication. New watch and request duration metrics have been added for enhanced observability. etcdctl commands have been reorganized for clarity, and deprecated experimental flags have been removed. Significant cleanup of legacy v2 API packages and code has also been performed.

https://kubernetes.io/blog/2026/07/08/announcing-etcd-3.7/ kubernetes.io

RSS Hunter • Jul 8

Open source maintainership in the age of AI

AI is transforming software development, enabling more contributors through code generation. However, this advancement outpaces improvements in code maintenance, posing a challenge. The Kubernetes community is proactively adapting to AI-assisted coding by establishing a comprehensive AI policy. This policy aims to balance innovation with accountability, ensuring code quality and human oversight. A core principle is transparency, requiring contributors to disclose AI usage in their pull requests.Crucially, human accountability remains paramount; AI cannot be listed as a co-author or co-signer. Contributors must also personally explain any AI-generated code, preventing knowledge gaps. The project enforces Contributor License Agreements for all co-authors, including AI-assisted ones, flagging incomplete PRs. Automated AI reviews are being explored to enhance code quality and provide initial feedback.Tools like GitHub Copilot and CodeRabbit are being evaluated and tested within specific Kubernetes projects. These tools can act as quality gates, offering quick spot checks before human review. The community is actively seeking help to tune review tools, evaluate emerging AI technologies, and explore AI's potential in reducing maintainer burnout and assisting with test triage.

https://kubernetes.io/blog/2026/06/26/open-source-maintainership-in-the-age-of-ai/ kubernetes.io

RSS Hunter • Jun 26

Introducing the Cluster API plugin for Headlamp

Headlamp is an open-source Kubernetes UI project for managing cluster resources from a browser. Cluster API (CAPI) provides declarative, Kubernetes-style APIs for cluster lifecycle management. The Headlamp Cluster API plugin simplifies managing CAPI resources, eliminating the need for raw kubectl commands. This plugin adds a dedicated CAPI section to Headlamp, offering full visibility into core CAPI resources through consistent list and detail views. Key features include a cluster overview, Machine visibility, and a centralized Cluster API dashboard for health monitoring. Users can track KubeadmControlPlane replicas, scale MachineDeployments and MachineSets, and visualize owned resource hierarchies. The plugin also allows inspection of KubeadmConfig without raw YAML and provides topology awareness. A map view visualizes Cluster, Control Plane, and Worker relationships, supporting both v1beta1 and v1beta2 Cluster API versions. Prometheus metrics are integrated for live performance data inline on detail pages. Developed during the CNCF LFX Mentorship program, the plugin aims to enhance the Cluster API management experience. This is an Alpha release, and community feedback is encouraged for future development.

https://kubernetes.io/blog/2026/06/25/headlamp-cluster-api-plugin/ kubernetes.io

RSS Hunter • Jun 25

Inspect Volcano workloads faster with Headlamp

Volcano is a cloud-native batch scheduler for Kubernetes, designed for high-performance computing, AI/ML, and other batch workloads. Kubernetes was originally built for long-running services, whereas batch workloads often require dynamic job arrival, resource competition, and co-starting multiple workers. Volcano extends Kubernetes with concepts like queues, priorities, quotas, and gang scheduling, treating workloads as a whole rather than independent Pods. The Volcano plugin for Headlamp, an extensible Kubernetes web UI, brings these scheduling details into a single interface.The plugin provides dedicated views for Volcano Jobs, Queues, and PodGroups, making it easier to operate and troubleshoot batch workloads. The Job view displays workload status, task details, Pod status, and allows direct actions like suspending/resuming and accessing logs. The Queue view offers insights into resource allocation, capacity, and reservation details. The PodGroup view clarifies gang scheduling states and potential blockers.A key feature is the map view, which visually represents how Jobs, Queues, PodGroups, and Pods are interconnected, helping to quickly identify issues in pending or non-progressing workloads. This plugin enhances the interactive troubleshooting experience by centralizing related resources, structured details, and runtime output, without replacing CLI tools for automation. Future enhancements may include Prometheus integration and richer scheduling insights. Users can install the plugin via Headlamp's Plugin Catalog and provide feedback to shape its development.

https://kubernetes.io/blog/2026/06/25/visual-context-volcano-headlamp-plugin/ kubernetes.io

RSS Hunter • Jun 25

See your serverless: introducing the Headlamp plugin for Knative

Headlamp is an open-source project designed to manage and debug Kubernetes resources. Knative enables serverless workloads on Kubernetes but can be complex to operate across multiple tools. To address this, a Headlamp plugin for Knative has been developed. This plugin allows users to manage Knative extensively from within Headlamp. It integrates Knative resources into Headlamp's resource mapping view, showing relationships between KServices, Revisions, and DomainMappings. The plugin offers a detailed view for KServices, enabling live edits of traffic splits and autoscaling configurations. Users can also restart pods and access logs directly from the KService header. The plugin facilitates granular traffic splitting across revisions for phased rollouts and A/B testing. It visually displays traffic distribution, readiness status, and tags for each revision. Autoscaling configurations are clearly presented, indicating whether settings are explicit or inherited from cluster defaults. When combined with the Prometheus plugin, it provides metrics like request rates and latency for KServices and Revisions. The plugin also offers list and detail views for other Knative CRDs, including Revisions, DomainMappings, and a networking overview. Installation involves searching for and installing the Knative plugin from Headlamp's Plugin Catalog. Feedback and bug reports can be submitted via GitHub issues or the Kubernetes Slack channel.

https://kubernetes.io/blog/2026/06/25/headlamp-knative-plugin/ kubernetes.io

RSS Hunter • Jun 25

Spotlight on WG Device Management

The Device Management Working Group addresses the increasing need for specialized hardware management in Kubernetes. Traditional resource allocation methods are insufficient for AI, Edge, and Telecommunications workloads requiring GPUs, TPUs, and specific network interfaces. The group's primary project, Dynamic Resource Allocation (DRA), has reached General Availability, signifying a major advancement. DRA provides a structured four-stage framework for device management: modeling, requesting, scheduling, and actuation. This new approach allows vendors to advertise granular hardware capabilities and users to specify precise hardware needs. The Kubernetes scheduler then intelligently matches these requirements to available hardware. DRA replaces the legacy Device Plugin API, which treated devices as simple integers, with a flexible and declarative API. The working group is a cross-SIG effort involving several SIGs to ensure comprehensive integration across Kubernetes components. Current initiatives focus on enhancing DRA's expressiveness, supporting operational visibility, and improving multi-node and complex hardware topology management. Future work includes device health monitoring and better support for grouped device usage. The working group aims to create a more programmable and hardware-aware future for Kubernetes.

https://kubernetes.io/blog/2026/06/24/wg-device-management-spotlight-2026/ kubernetes.io

RSS Hunter • Jun 24

Spotlight on SIG Storage

The article highlights SIG Storage, the Kubernetes Special Interest Group responsible for persistent data and volume management. Xing Yang, a co-chair of SIG Storage, discusses the group's evolution from handling basic persistent volumes to advancing complex storage features. Initially designed for stateless workloads, Kubernetes now supports stateful applications, necessitating dedicated storage solutions. SIG Storage formed to address these challenges, introducing primitives like PersistentVolumes and PersistentVolumeClaims.A significant advancement was the Container Storage Interface (CSI), which enables third-party storage providers to integrate their systems without core Kubernetes modifications. Current work includes Volume Group Snapshot for crash-consistent multi-volume snapshots and Changed Block Tracking for efficient backups, both recently graduated to stable versions. The Container Object Storage Interface (COSI) is also progressing to standardize object storage integration.Recent wins for users include the graduation of VolumeAttributesClass to General Availability, allowing dynamic tuning of storage properties like IOPS. Future roadmaps feature Volume Health for improved operational visibility and potential automated remediation. SIG Storage seeks community help with bug fixes, tests, reviews, and feedback on features like Mutable PV Affinity and volume replication.Challenges for stateful workloads include data gravity, day-2 operational complexity, and data mobility. As AI workloads grow, storage in Kubernetes is expected to become more intelligent, with object storage gaining prominence. High performance, low latency storage, and data-aware scheduling are also anticipated trends. SIG Storage invites community involvement to tackle these evolving storage demands.

https://kubernetes.io/blog/2026/06/15/sig-storage-spotlight-2026/ kubernetes.io

RSS Hunter • Jun 15

From Kubernetes Dashboard to Headlamp: Understanding the Transition

The Kubernetes Dashboard, once a primary visual interface for Kubernetes, has been archived. It served as an important onramp for many users, simplifying cluster visibility and resource inspection. Headlamp now carries this legacy forward, building on the Dashboard's foundation. It offers a clear visual interface while incorporating modern Kubernetes usage patterns. Headlamp provides multi-cluster visibility, application-centric views through Projects, and extensibility via plugins. The transition aims to honor the user-centered legacy of Dashboard and offer a growing UI solution. Many familiar workflows from Kubernetes Dashboard are retained in Headlamp, ensuring continuity and ease of use. Headlamp expands capabilities by allowing multi-cluster management from a single interface, reducing friction for distributed environments. Projects within Headlamp offer application-centered views, grouping related resources for better understanding and troubleshooting. The platform is also extensible through plugins, such as the Flux plugin for GitOps workflows or an AI Assistant for guidance. Headlamp offers flexible deployment options, usable as an in-cluster tool or a desktop application. Understanding current Dashboard usage, including clusters, namespaces, and authentication, aids a smooth transition to Headlamp.

https://kubernetes.io/blog/2026/06/01/dashboard-to-headlamp/ kubernetes.io

RSS Hunter • Jun 1

Reconciling the Past: Correcting Records for Unfixed Kubernetes CVEs

Kubernetes is improving transparency by refining its CVE records for better accuracy. They discovered discrepancies in older CVE records, with some incorrectly listing fixed versions. The Kubernetes Security Response Committee will correct these records on June 1, 2026. This might lead to vulnerability scanners identifying previously undetected issues. This post offers technical details about three unfixed vulnerabilities: CVE-2020-8561, CVE-2020-8562, and CVE-2021-25740. The updates ensure correct vulnerability scanning and clarify persistent administrative mitigation needs. CVE-2020-8554, also unfixed, will receive a standardized version number format. The identified vulnerabilities remain unfixed because fixing them would disrupt core Kubernetes functionality. Each vulnerability has specific mitigations that administrators should implement to secure their clusters. These actions are crucial given the vulnerabilities’ architectural nature. The project emphasizes a "secure by configuration" approach to manage these risks. Updating these records shows a maturing security ecosystem promoting transparency and accurate risk assessment.

https://kubernetes.io/blog/2026/05/26/reconciling-unfixed-kubernetes-cves/ kubernetes.io

RSS Hunter • May 26

Announcing etcd 3.7.0-beta.0

SIG-Etcd has released the first beta of etcd v3.7.0, a significant update for the distributed database. This version introduces RangeStream, a feature designed to improve handling of large result sets, enhancing latency and memory management. The release also includes refactoring and cleanup of legacy components and interfaces, improving overall performance. The developers encourage users to test the beta and report any issues found in the etcd repository. A key highlight is the removal of the last vestiges of etcd v2store, completing the transition to v3store. This transition may introduce breaking changes, particularly for users not on v3.6.11, so feedback is requested regarding any problems encountered. This beta release also incorporates updates to bbolt and raft libraries. Furthermore, the release timeline is linked to the End of Life (EOL) for etcd v3.4, which will cease updates after May. The community is prepared to release an additional security patch for v3.4 if required, before its ultimate deprecation. Users are urged to upgrade from v3.4. Future betas are planned, potentially with further protobuf refactoring leading to release candidates and the final version in June or early July. Feedback is actively solicited through GitHub issues, the Kubernetes Slack channel, and the etcd-dev mailing list.

https://kubernetes.io/blog/2026/05/20/etcd-370-beta/ kubernetes.io

RSS Hunter • May 20

Kubernetes v1.36: New Metric for Route Sync in the Cloud Controller Manager

This article, originally misdated, now reflects a May 15, 2026, publication date. Kubernetes v1.36 introduces a new alpha metric, route_controller_route_sync_total, for the Cloud Controller Manager's route controller. This metric tracks route sync operations with the cloud provider, aiding in monitoring the CloudControllerManagerWatchBasedRoutesReconciliation feature gate. This feature, introduced in v1.35, switches the route controller to a watch-based approach. This change reduces API calls by only reconciling routes when nodes change. To test the new feature, compare the metric's behavior with the feature gate disabled and enabled. With the feature gate disabled, the counter increments at a fixed interval. Conversely, with the feature enabled, the counter only increments upon node changes. This difference is most noticeable in stable clusters with infrequent node modifications. Feedback can be provided through Kubernetes Slack, a GitHub issue, and the SIG Cloud Provider community page. Further details are available in KEP-5237.

https://kubernetes.io/blog/2026/05/15/ccm-new-metric-route-sync-total/ kubernetes.io

RSS Hunter • May 15

Kubernetes v1.36: Mixed Version Proxy Graduates to Beta

The Mixed Version Proxy (MVP) enhances Kubernetes cluster upgrades by safely routing requests for unknown resources to newer API servers, preventing 404 errors. Initially introduced as an Alpha feature in Kubernetes 1.28, MVP is now moving to Beta in version 1.36 and will be enabled by default. MVP addresses the issue of API servers with differing versions during upgrades, where requests for new resources might fail on older servers. Instead of the incorrect 404, the request is proxied to a server capable of handling it. The Beta version of MVP uses aggregated discovery instead of the StorageVersion API for determining peer capabilities, improving functionality. This update also includes peer-aggregated discovery, providing clients with a unified view of all available APIs. To enable MVP, API servers require the --peer-ca-file flag, along with --peer-advertise-ip and --peer-advertise-port if needed. With kubeadm, you can include those flags in your ClusterConfiguration file to streamline the process. Users are encouraged to test MVP in staging environments and provide feedback to the SIG API Machinery as part of the 1.36 upgrade.

https://kubernetes.io/blog/2026/05/15/kubernetes-1-36-feature-mixed-version-proxy-beta/ kubernetes.io

RSS Hunter • May 15

Kubernetes v1.36: Deprecation and removal of Service ExternalIPs

The .spec.externalIPs field in Kubernetes Services, initially designed for non-cloud load-balancer functionality, is now deprecated due to security vulnerabilities identified in CVE-2020-8554. This field allows specifying additional IP addresses a Service responds to, but it has inherent security risks because it assumes trust among all users. Kubernetes 1.21 already recommended disabling .spec.externalIPs, and an admission controller was introduced to enforce this. Alternatives, like manually managed LoadBalancer services or non-cloud load balancer controllers such as MetalLB, offer better security and control. MetalLB allows administrators to control IP address assignments, mitigating security concerns. The Gateway API also provides a secure solution, giving administrators control over the IP through a Gateway resource. Kubernetes 1.36 officially deprecated .spec.externalIPs and started issuing warnings about its usage. Kube-proxy support for the feature will be disabled in a future release, with full removal planned in subsequent versions. Users are encouraged to migrate away from this insecure feature.

https://kubernetes.io/blog/2026/05/14/kubernetes-v1-36-deprecation-and-removal-of-service-externalips/ kubernetes.io

RSS Hunter • May 14

Kubernetes v1.36: Advancing Workload-Aware Scheduling

Kubernetes v1.35 introduced workload-aware scheduling improvements, including the Workload API and basic gang scheduling for identical Pods. Kubernetes v1.36 refines this architecture by separating the Workload API (static template) from the new PodGroup API (runtime state). This separation streamlines the kube-scheduler, enabling it to directly read PodGroup information for enhanced performance.A new PodGroup scheduling cycle allows atomic processing of workloads, evaluating entire groups as a unified operation to prevent deadlocks. If a valid placement is found and group constraints are met, Pods are bound together; otherwise, the entire group is considered unschedulable and retries later. This forms the foundation for gang scheduling, ensuring all-or-nothing placement for strict workload requirements.Topology-aware scheduling in v1.36 enables defining topology constraints on PodGroups, co-locating Pods within specific physical or logical domains to reduce network latency. This involves generating, evaluating, and scoring candidate placements based on scheduling constraints.Workload-aware preemption is introduced to support the PodGroup scheduling cycle, preempting Pods from multiple Nodes simultaneously to make space for an entire PodGroup. It treats the PodGroup as a single preemptor unit, with PodGroup priority and disruptionMode fields controlling preemption behavior.Finally, v1.36 integrates Dynamic Resource Allocation (DRA) with the Workload API, allowing PodGroups to request and share specialized hardware resources through ResourceClaims. These advancements lay a robust foundation for building advanced workload scheduling capabilities in future Kubernetes releases.

https://kubernetes.io/blog/2026/05/13/kubernetes-v1-36-advancing-workload-aware-scheduling/ kubernetes.io

RSS Hunter • May 13

Kubernetes v1.36: PSI Metrics for Kubernetes Graduates to GA

Pressure Stall Information (PSI) has been integrated into the Linux kernel since 2018, providing high-fidelity signals for identifying resource saturation before it leads to outages. Unlike traditional utilization metrics, PSI quantifies stalled tasks and lost time across CPU, memory, and I/O. With Kubernetes v1.36, a stable interface for observing resource contention at node, pod, and container levels is now available. PSI offers cumulative totals of stalled time and moving averages (10s, 60s, 300s) to distinguish between transient spikes and sustained resource tension.Extensive performance testing by SIG Node on high-density workloads (80+ pods) proved PSI's readiness for production. Kubelet overhead, measured by toggling the KubeletPSI feature gate, showed negligible impact on resource usage. The Kubelet's collection logic proved lightweight, blending seamlessly into standard housekeeping cycles, consuming less than 0.1 cores or 2.5% of total node capacity.Regarding kernel overhead, enabling PSI on the Linux kernel (psi=1 vs psi=0) resulted in a consistent delta of 0.037 to 0.125 cores (0.925% - 3.125% of node capacity) under heavy load. The kubelet process, as the primary collector, also maintained remarkably low CPU usage, with spikes not exceeding 0.25 cores (6.25%) for more than a second.Improvements in v1.36 include smarter metric emission; the Kubelet now detects OS-level PSI support via cgroup configurations before reporting, preventing misleading zero-valued metrics. To use PSI, nodes must run Linux kernel 4.20+, use cgroup v2, and have PSI enabled at the OS level (CONFIG_PSI=y, no psi=0 boot parameter).PSI metrics are generally available in v1.36 and require no feature gate opt-in. Users can scrape the /metrics/cadvisor endpoint or query the Summary API. PSI is a Linux-kernel feature and is not available on Windows nodes. Proxying to the Kubelet's HTTP API via the control plane's API server allows real-time pressure data from the Summary API but is a privileged operation.

https://kubernetes.io/blog/2026/05/12/kubernetes-v1-36-psi-metrics-ga/ kubernetes.io

RSS Hunter • May 12

Kubernetes v1.36: Moving Volume Group Snapshots to GA

Kubernetes v1.36 introduces General Availability (GA) for volume group snapshots, a feature that was previously an Alpha and then Beta enhancement. This functionality leverages extension APIs to enable crash-consistent snapshots of multiple volumes simultaneously. The system groups PersistentVolumeClaim objects using label selectors, allowing for the restoration of workloads to a consistent recovery point. This feature is exclusively supported for CSI volume drivers, offering a significant advantage for applications utilizing multiple volumes that require write order consistency.Previously, individual volume snapshots could lead to inconsistencies if taken at different times, particularly for multi-volume applications. Group snapshots eliminate the need for manual application quiescence, providing crash consistency across all volumes in the group without tedious, sequential individual snapshots. Kubernetes manages group snapshots through three custom API kinds: VolumeGroupSnapshot, VolumeGroupSnapshotContent, and VolumeGroupSnapshotClass. These CRDs, now promoted to v1 in the GA release, allow users to request group snapshots, track their provisioned resources, and define their creation policies, respectively.The GA release brings enhanced stability, bug fixes, and improved restoreSize reporting based on feedback from prior beta versions. To use this feature, users must label their PersistentVolumeClaims to be grouped and then define a VolumeGroupSnapshot object with a selector matching these labels, along with a VolumeGroupSnapshotClass. For restoration, new PersistentVolumeClaims are created from individual VolumeSnapshot objects that are part of a larger VolumeGroupSnapshot. Storage vendors can add support by implementing new group controller services and RPCs within their CSI drivers.

https://kubernetes.io/blog/2026/05/08/kubernetes-v1-36-volume-group-snapshot-ga/ kubernetes.io

RSS Hunter • May 8

Kubernetes v1.36: More Drivers, New Features, and the Next Era of DRA

Dynamic Resource Allocation (DRA) in Kubernetes v1.36 introduces significant advancements, extending its capabilities beyond specialized hardware to native resources like CPU and memory. Driver support for various hardware types, including networking, is expanding, making DRA a more hardware-agnostic solution. Several key features have graduated, enhancing scheduling flexibility and cluster utilization. The Prioritized list feature enables fallback preferences for device requests, improving resource allocation efficiency. Extended resource support allows a gradual transition to DRA by enabling resource requests via traditional extended resources. Partitionable devices provide native DRA support for dynamically carving physical hardware into smaller, logical instances. Device taints empower administrators to manage hardware more effectively by preventing faulty devices from being allocated or reserving specific hardware. Device binding conditions improve scheduling reliability by delaying Pod commitment until external resources are fully prepared. Resource health status exposes device health information directly in Pod status, aiding in quick identification and reaction to hardware failures. New alpha features include ResourceClaim support for workloads, optimizing large-scale AI/ML by managing shared resources across PodGroups. Node allocatable resources integrate CPU and memory allocation under the DRA umbrella, allowing for fine-grained performance tuning. DRA resource availability visibility provides administrators with real-time device capacity information for better planning. Deterministic device selection allows drivers to influence scheduling through lexicographical ordering. Discoverable device metadata in containers provides a standard protocol for drivers to expose device attributes to containers. The future roadmap focuses on maturing existing features, enhancing performance, scalability, and integration with workload-aware and topology-aware scheduling, with a strong emphasis on migrating users from Device Plugin to DRA.

https://kubernetes.io/blog/2026/05/07/kubernetes-v1-36-dra-136-updates/ kubernetes.io

RSS Hunter • May 7

Kubernetes v1.36: Server-Side Sharded List and Watch

Kubernetes controllers face scaling challenges as cluster sizes increase, particularly when watching high-cardinality resources. Client-side sharding, while functional, doesn't reduce the data volume from the API server, causing inefficiency. Server-side sharded list and watch, introduced in Kubernetes v1.36 as an alpha feature (KEP-5866), addresses this inefficiency. The API server filters events based on the controller's specified hash range, sending only relevant data to each replica. Controllers use informers to list and watch resources, incorporating the shardSelector through WithTweakListOptions. The shard selector is used to filter resources based on the object's metadata.uid or metadata.namespace. The API server returns a shardInfo field in the list response metadata to confirm if the shard selector was applied correctly. If absent, the client must handle the full, unfiltered collection, potentially resorting to client-side filtering. This feature requires enabling the ShardedListAndWatch feature gate. The Kubernetes community seeks feedback from controller authors and operators, especially those managing large clusters. This approach is designed to improve controller performance and scalability in demanding Kubernetes environments.

https://kubernetes.io/blog/2026/05/06/kubernetes-v1-36-server-side-sharded-list-and-watch/ kubernetes.io

RSS Hunter • May 6

Kubernetes v1.36: Declarative Validation Graduates to GA

Kubernetes v1.36 introduces Declarative Validation for native types, now generally available. This shifts from handwritten Go code to IDL tags for defining validation rules, enhancing API reliability and predictability. The previous reliance on handwritten code led to technical debt, inconsistencies, and opaque APIs. The solution utilizes validation-gen, a code generator that parses tags to automatically generate Go validation functions. This framework includes various marker tags for presence, constraints, collections, unions, and immutability. A key benefit is "ambient ratcheting", allowing immediate tightening or loosening of validation without breaking existing objects. Declarative validation makes API reviews easier and more consistent with tools like kube-api-linter. The project plans to migrate remaining legacy code and mandate declarative validation for new APIs. This also unlocks future ecosystem benefits, like client-side validation by tools such as kubectl and integration with tools such as Kubebuilder. The migration is ongoing, with opportunities to contribute to the Kubernetes codebase. The document concludes with acknowledgments to contributors, welcoming the declarative future of Kubernetes validation.

https://kubernetes.io/blog/2026/05/05/kubernetes-v1-36-declarative-validation-ga/ kubernetes.io

RSS Hunter • May 5

Kubernetes v1.36: Admission Policies That Can't Be Deleted

Kubernetes' manifest-based admission control, introduced in v1.36, addresses security policy enforcement gaps during cluster bootstrap. Existing API-based admission control has vulnerabilities: policies are API objects and can be removed, creating a security window. This new feature allows defining admission webhooks and CEL-based policies as files loaded by the API server at startup. This ensures policies are active before any requests are served, protecting against unauthorized modifications. It uses a staticManifestsDir field in the AdmissionConfiguration file to specify a directory containing policy YAML files. These files must have names ending in .static.k8s.io to distinguish them from API-based configurations. The feature can protect the admission configurations themselves from deletion or modification. Changes to the manifest files are automatically updated at runtime. The API server enforces strict validation during startup and handles runtime updates atomically. To implement it, you'll need to enable the ManifestBasedAdmissionControlConfig feature gate.

https://kubernetes.io/blog/2026/05/04/kubernetes-v1-36-manifest-based-admission-control/ kubernetes.io

RSS Hunter • May 4

Kubernetes v1.36: Pod-Level Resource Managers (Alpha)

Kubernetes v1.36 introduces Pod-Level Resource Managers as an alpha feature, enhancing resource management for performance-sensitive workloads. It extends kubelet's Topology, CPU, and Memory Managers to a pod-centric resource allocation model, moving beyond per-container specifications. This addresses the challenge of providing exclusive, NUMA-aligned resources for primary application containers while supporting lightweight sidecars efficiently. Previously, achieving predictable performance often meant allocating exclusive resources to all containers, which was wasteful for sidecars. Alternatively, not doing so sacrificed the pod's Guaranteed QoS. Pod-level resource managers enable hybrid allocation, allowing high-performance workloads to achieve NUMA alignment without wasting resources. For example, a latency-sensitive database pod can have its main container receive exclusive CPU and memory, while sidecars share a distinct pod shared pool, isolated from other node resources. Another use case involves ML workloads where the training container gets exclusive NUMA-aligned resources, and a service mesh sidecar runs in the general node-wide shared pool. CPU isolation is managed by disabling CFS quota enforcement for exclusive containers and enforcing it at the pod level for shared pool containers. Enabling requires specific kubelet feature gates, Topology Manager policies, and static CPU and Memory Manager configurations. New kubelet metrics provide observability into resource allocations and container assignments. This feature is currently in alpha, with known limitations and caveats, and user feedback is encouraged through Kubernetes community channels.

https://kubernetes.io/blog/2026/05/01/kubernetes-v1-36-feature-pod-level-resource-managers-alpha/ kubernetes.io

RSS Hunter • May 1

Kubernetes v1.36: In-Place Vertical Scaling for Pod-Level Resources Graduates to Beta

Kubernetes v1.36 introduces In-Place Pod-Level Resources Vertical Scaling, now in Beta and enabled by default. This feature allows users to dynamically adjust the aggregate resource limits of a running Pod. This is particularly useful for Pods with shared resources and no container-specific limits. The Kubelet determines the update method based on each container's resizePolicy, deciding between in-place updates or restarts. When a resize happens, the Kubelet first checks if the node has enough resources. It then sequences cgroup updates to prevent resource overshoot, expanding the pod-level cgroup before individual container cgroups are enlarged. Pod conditions, like PodResizeInProgress, track the resize's progress and status. The feature requires cgroup v2, CRI support, specific feature gates, and Linux-based nodes. The next step is integrating this with the Vertical Pod Autoscaler (VPA). Users are encouraged to test this feature and provide feedback through the community channels.

https://kubernetes.io/blog/2026/04/30/kubernetes-v1-36-inplace-pod-level-resources-beta/ kubernetes.io

RSS Hunter • Apr 30

Kubernetes v1.36: Tiered Memory Protection with Memory QoS

Kubernetes v1.36 introduces updates to the Memory QoS feature, which uses cgroup v2 for better container memory management. Key updates in v1.36 include opt-in memory reservation, providing tiered protection based on Pod QoS classes. Guaranteed Pods now receive hard memory protection (memory.min), while Burstable Pods get soft protection (memory.low). BestEffort Pods remain fully reclaimable with no special protection. The new memoryReservationPolicy allows separate control of throttling and reservation. Observability metrics are provided to monitor memory.min and memory.low usage across the node. A kernel version check warns users if the kernel is older than 5.9 due to potential livelock issues. The implementation leverages memory.max, memory.min, memory.low, and memory.high cgroup v2 interfaces. Node memory allocation is managed by the kubelet, ensuring proper protection for each pod and QoS class. The feature can be enabled via kubelet configuration, with TieredReservation being the key setting. The recommended prerequisite is Kubernetes v1.36 or later, Linux with cgroup v2 and Kernel 5.9 or higher. Users can engage with the SIG Node community for feedback and contributions.

https://kubernetes.io/blog/2026/04/29/kubernetes-v1-36-memory-qos-tiered-protection/ kubernetes.io

RSS Hunter • Apr 29

Kubernetes v1.36: Staleness Mitigation and Observability for Controllers

Kubernetes controllers can suffer from staleness, leading to incorrect or delayed actions due to outdated cached data. Staleness arises from the controller's local cache being out of sync with the cluster's actual state. Kubernetes v1.36 introduces features to mitigate staleness and improve controller behavior. These improvements include atomic FIFO processing in client-go, enhancing queue consistency. The kube-controller-manager has integrated these client-go improvements in several key controllers like DaemonSet and ReplicaSet. These controllers now check cache resource versions before acting, preventing actions on stale data. Informer authors can use a ConsistencyStore to track and manage resource versions, mitigating staleness in their controllers. The ConsistencyStore provides functions for recording writes, checking cache readiness, and clearing stale object entries. Kubernetes v1.36 also offers new metrics to monitor controller health, including the number of skipped syncs due to staleness. Client-go also now emits metrics exposing the latest resource versions of shared informers. The Kubernetes team plans to expand these staleness mitigation features to more controllers, and integrates it in controller-runtime. They encourage user feedback and future development.

https://kubernetes.io/blog/2026/04/28/kubernetes-v1-36-staleness-mitigation-for-controllers/ kubernetes.io

RSS Hunter • Apr 28

Kubernetes v1.36: Mutable Pod Resources for Suspended Jobs (beta)

Kubernetes v1.36 promotes the ability to modify container resource requests and limits in the pod template of a suspended Job to beta. This feature, introduced as alpha in v1.35, enables queue controllers and administrators to adjust resource specifications like CPU, memory, and GPUs for a Job while suspended, before it executes. Previously, resource requirements were immutable once set, forcing deletion and recreation of Jobs to change them, losing valuable metadata. This new capability addresses situations where resource needs are not precisely known at Job creation or when cluster capacity fluctuates. For example, a queue controller can now reduce a machine learning Job's GPU request from four to two if only two are available. The Kubernetes API server relaxes immutability constraints on specific resource fields for suspended Jobs, requiring the Job's spec.suspend to be true and all active Pods to be terminated if it was previously running. In the beta version, the MutablePodResourcesForSuspendedJobs feature gate is enabled by default in v1.36. Users can test this by creating a suspended Job, editing its resources, and then resuming it. It's crucial to ensure all active Pods terminate before modifying resources for a suspended running Job to prevent inconsistencies.

https://kubernetes.io/blog/2026/04/27/kubernetes-v1-36-mutable-pod-resources-for-suspended-jobs/ kubernetes.io

RSS Hunter • Apr 27

Kubernetes v1.36: Fine-Grained Kubelet API Authorization Graduates to GA

Fine-grained kubelet API authorization has reached General Availability in Kubernetes v1.36. This feature replaces the overly broad nodes/proxy permission for accessing the kubelet's HTTPS API, improving security. The initiative addresses the security risk of granting excessive permissions to monitoring tools. Prior to this, nodes/proxy was often used, which allowed command execution. Fine-grained authorization maps specific kubelet API paths to more dedicated subresources. The system performs a dual authorization check for backward compatibility. Existing workloads with nodes/proxy permissions will keep working as before. The built-in system:kubelet-api-admin ClusterRole is updated automatically. Monitoring tools can now utilize specific resources like nodes/metrics, enhancing least-privilege access. The upgrade requires no changes for most clusters. To verify the feature, you can run a pod verifying the feature flag using curl. The next steps involve more ecosystem adaption; also, deprecation of nodes/proxy may occur.

https://kubernetes.io/blog/2026/04/24/kubernetes-v1-36-fine-grained-kubelet-authorization-ga/ kubernetes.io

RSS Hunter • Apr 24

Kubernetes v1.36: User Namespaces in Kubernetes are finally GA

Kubernetes v1.36 introduced General Availability support for User Namespaces, a Linux-only feature enabling enhanced security isolation for containerized workloads. This long-awaited milestone allows "rootless" security isolation for Kubernetes applications. A critical capability is running workloads with privileges yet confined within the user namespace by setting hostUsers: false. This makes certain capabilities, like CAP_NET_ADMIN, namespaced, granting administrative power only over local container resources. Previously, a process root within a container was also root on the host, posing a significant security risk during breakouts. The key enabler for this feature is ID-mapped mounts, which transparently remap UIDs and GIDs at mount time without altering disk ownership. This resolves performance issues related to volume ownership updates that plagued earlier development stages. Implementing user namespaces is simple: set hostUsers: false in the Pod spec, requiring no changes to container images or complex configuration. The feature leverages the same interface introduced during the Alpha phase. This advancement represents years of cross-project collaboration between Kubernetes SIG Node, container runtimes, and the Linux kernel.

https://kubernetes.io/blog/2026/04/23/kubernetes-v1-36-userns-ga/ kubernetes.io

RSS Hunter • Apr 23

SELinux Volume Label Changes goes GA (and likely implications in v1.37)

Kubernetes v1.37 plans to enable the SELinuxMount feature gate by default, which improves volume setup speed. This change might break applications relying on the older recursive relabeling method, especially those sharing volumes between privileged and unprivileged pods. The article encourages auditing clusters in v1.36 to identify and address potential conflicts related to SELinux. When SELinux is enabled, the kubelet applies SELinux labels to volumes for access control, and the new approach uses mount options for faster relabeling. The SELinuxChangePolicy field and the Recursive option were created to allow opting out of this performance acceleration method. If the conditions are met, the kubelet can now mount volumes directly with the appropriate SELinux label, eliminating the need for recursive relabeling. The selinux-warning-controller identifies conflicting Pods that might break with the new configuration, emitting events and metrics. Using the provided metrics, cluster administrators can detect potential issues and make appropriate adjustments. The recommended upgrade path includes enabling the controller, addressing conflicts, and then upgrading to a version with SELinuxMount enabled while monitoring for errors. Administrators can use various methods to enforce the opt-out for specific Pods. The new behavior allows faster performance but modifies sharing volumes among different pods.

https://kubernetes.io/blog/2026/04/22/breaking-changes-in-selinux-volume-labeling/ kubernetes.io

RSS Hunter • Apr 22

Kubernetes v1.36: ハル (Haru)

Kubernetes v1.36 has been released, featuring 70 enhancements with 18 graduating to stable and 25 entering beta. The release theme, "Haru," symbolizes spring, clear skies, and distant horizons, with the logo inspired by Hokusai's "Red Fuji." This release emphasizes community collaboration, with many individuals and teams contributing to its success.Key stable features include fine-grained kubelet API authorization for improved least-privilege access control. Resource health status for allocated devices has entered beta, offering unified reporting for hardware failures. Alpha introduces Workload Aware Scheduling, treating related pods as a single logical entity for better resource management.Volume group snapshots are now stable, enabling crash-consistent snapshots across multiple PersistentVolumeClaims. Mutable CSI node allocatable limits also reach stability, allowing dynamic updates to node volume capacities. The external ServiceAccount token signer feature is now stable for offloading token signing to external systems.Dynamic Resource Allocation (DRA) admin access and prioritized lists are now stable, providing a secure framework for resource management. Declarative mutating admission policies are stable, offering a native alternative to webhooks for resource mutations. Declarative validation for Kubernetes native types with validation-gen has also graduated to stable, streamlining custom resource development. The removal of the gogo protobuf dependency for Kubernetes API types marks a significant step forward for security and maintainability.

https://kubernetes.io/blog/2026/04/22/kubernetes-v1-36-release/ kubernetes.io

RSS Hunter • Apr 22

Gateway API v1.5: Moving features to Stable

Gateway API v1.5, released March 14, 2026, marks their most significant release to date. This version focuses on promoting several formerly experimental features to the stable channel. Key promotions include ListenerSet, TLSRoute, HTTPRoute CORS Filter, Client Certificate Validation, Certificate Selection for Gateway TLS Origination, and ReferenceGrant. The project has adopted a release train model, synchronizing with Kubernetes SIG Release for more predictable updates. This new process includes dedicated Release Manager and Release Shadow roles. ListenerSet allows listeners to be defined independently and merged onto Gateways, enhancing scalability and multi-tenancy. TLSRoute enables routing based on SNI for TLS connections, supporting both Passthrough and Terminate modes. The HTTPRoute CORS filter provides granular control over cross-origin resource sharing settings. Client certificate validation, or mutual TLS (mTLS), allows Gateways to verify client identities by checking certificates against trusted CAs. This feature can be configured globally or per-port for enhanced security.

https://kubernetes.io/blog/2026/04/21/gateway-api-v1-5/ kubernetes.io

RSS Hunter • Apr 21

Kubernetes v1.36 Sneak Peek

Kubernetes v1.36, slated for late April 2026, will introduce significant removals, deprecations, and numerous enhancements. The project adheres to a strict deprecation policy, ensuring stable APIs are only removed after a newer stable version is available and have a minimum lifetime. A recent example of this policy is the retirement of the Ingress NGINX project as of March 24, 2026, with no further support or security updates. For v1.36, the .spec.externalIPs field in Service is being deprecated due to security concerns (CVE-2020-8554), with full removal planned in v1.43, urging migration to LoadBalancer, NodePort, or Gateway API. The gitRepo volume driver, deprecated since v1.11, will be permanently disabled in v1.36 due to a critical security vulnerability allowing root code execution. Workloads currently using gitRepo must migrate to alternatives like init containers or external git-sync tools.Key enhancements in v1.36 include the General Availability (GA) of faster SELinux labeling for volumes, which uses mount options for consistent performance and reduced Pod startup delays. This feature, introduced as beta in v1.28, now defaults to all volumes with Pods specifying spec.SELinuxMount. External signing of ServiceAccount tokens, a beta feature, is expected to graduate to stable in v1.36, allowing clusters to integrate with external key management systems for improved security. Dynamic Resource Allocation (DRA) also sees advancements, with Device taints and tolerations graduating to beta, enabling specialized hardware resources to be restricted to specific workloads. Additionally, DRA will support partitionable devices, allowing a single hardware accelerator to be split into multiple logical units, improving resource utilization for costly resources like GPUs. These changes highlight a continued focus on security, efficiency, and advanced resource management within Kubernetes.

https://kubernetes.io/blog/2026/03/30/kubernetes-v1-36-sneak-peek/ kubernetes.io

RSS Hunter • Mar 30

Announcing Ingress2Gateway 1.0: Your Path to Gateway API

Ingress-NGINX is scheduled for retirement in March 2026, creating a need for migration to Gateway API. Migrating from Ingress to Gateway API is a significant shift, moving from extended annotations to a modular, extensible API. The Ingress2Gateway tool assists teams in this transition by translating Ingress resources and their annotations. SIG Network has released Ingress2Gateway version 1.0, a stable migration assistant. This new release significantly improves Ingress-NGINX annotation support, now covering over 30 common annotations. Comprehensive integration tests ensure the behavioral equivalence of Ingress-NGINX configurations and generated Gateway API manifests. Ingress2Gateway also provides clear notifications for untranslatable configurations and offers suggestions for manual intervention. The tool aims to migrate supported configurations, identify unsupported ones, and prompt reevaluation of existing settings. Users install and run Ingress2Gateway by providing Ingress manifests or connecting to a cluster. Critically, users must review the generated output and warnings to ensure accurate translation and identify potential issues. While Ingress2Gateway automates much of the process, manual verification and adjustment of Gateway API manifests are essential.

https://kubernetes.io/blog/2026/03/20/ingress2gateway-1-0-release/ kubernetes.io

RSS Hunter • Mar 20

Running Agents on Kubernetes with Agent Sandbox

Generative AI is evolving from stateless function calls to a system of continuously running, coordinated AI agents. These agents require persistent context, tool usage, code execution, and inter-agent communication over extended periods. Kubernetes is the ideal infrastructure for these workloads, but traditional primitives don't perfectly fit the needs of these stateful, singleton agents. The new Kubernetes Agent Sandbox project, under development by SIG Apps, aims to bridge this gap. It introduces a custom resource definition (CRD) for managing AI agent runtimes. The Sandbox CRD provides strong isolation for untrusted code execution using runtimes like gVisor or Kata Containers. It also offers robust lifecycle management, allowing agents to scale down to zero when idle and resume instantly. Furthermore, each Sandbox is assigned a stable identity for seamless inter-agent communication. To accelerate development in the fast-moving AI space, an Extensions API layer is available. The SandboxWarmPool extension eliminates cold starts by maintaining a pool of pre-provisioned Sandbox pods ready for immediate use. Users can install the core and extension components into their Kubernetes clusters. The Agent Sandbox project is open source and invites community involvement for building the future of cloud-native AI agents.

https://kubernetes.io/blog/2026/03/20/running-agents-on-kubernetes-with-agent-sandbox/ kubernetes.io

RSS Hunter • Mar 20

Securing Production Debugging in Kubernetes

Production debugging often relies on broad access, which poses auditing and security risks. This post recommends implementing secure debugging practices in Kubernetes. Key strategies include leveraging least privilege with Role-Based Access Control (RBAC). Short-lived, identity-bound credentials are crucial for session security and accountability. An SSH-style gateway acts as a "front door," making access temporary. An access broker can enhance RBAC, controlling commands and requiring approval. Kubernetes RBAC defines allowed actions, typically granting access to groups, not individuals. Short-lived credentials, like OIDC tokens or client certificates, link sessions to users and expire. These credentials are ideally signed by a regularly rotated certificate authority. A just-in-time access gateway, often over SSH, provides a secure debugging session. The gateway uses the credentials to authenticate the user and then applies policies before interacting with the Kubernetes API. The session's scope can be limited to specific clusters and namespaces.

https://kubernetes.io/blog/2026/03/18/securing-production-debugging-in-kubernetes/ kubernetes.io

RSS Hunter • Mar 18

The Invisible Rewrite: Modernizing the Kubernetes Image Promoter

The Kubernetes image promoter, kpromo, was completely rewritten to improve performance and maintainability. Its core function is to copy container images from staging to production registries, sign them, replicate signatures, and generate attestations, essential for Kubernetes releases. The rewrite was prompted by the existing codebase's complexity, slow performance, and frequent rate limit errors. The project followed a phased approach, addressing rate limiting, interfaces, the pipeline engine, and security features. Key improvements included streamlining the pipeline engine, parallelizing registry reads, and implementing timeouts and connection reuse. The rewrite resulted in a 20% smaller codebase with enhanced performance, robustness, and new features like provenance. Despite the extensive changes, the rewriting team was committed to not breaking user workflows. The team identified and fixed minor regressions quickly during the phased release. Future plans include further streamlining by eliminating signature replication, potentially using archeio for routing or integrating signing closer to the registry infrastructure. The project was the result of a long community effort.

https://kubernetes.io/blog/2026/03/17/image-promoter-rewrite/ kubernetes.io

RSS Hunter • Mar 17

Announcing the AI Gateway Working Group

The Kubernetes community is expanding with the formation of the AI Gateway Working Group, focusing on AI workload networking. An AI Gateway is network infrastructure using the Gateway API, enhancing it for AI workloads. This includes features like token-based rate limiting, access controls, and payload inspection. The working group aims to create standards and best practices for AI infrastructure in Kubernetes. Their goals include creating APIs, fostering collaboration, and ensuring extensibility for AI-specific gateway extensions. Active proposals address payload processing for security and optimization, as well as defining egress gateways. These proposals enable secure external AI service integration and advanced traffic management. The group addresses needs of platform operators, developers, and compliance engineers. The working group will present its findings at KubeCon + CloudNativeCon Europe 2026. The AI Gateway Working Group welcomes contributions from various stakeholders to shape the future of AI-aware gateway capabilities within Kubernetes. Interested individuals can review proposals, join meetings, and participate in discussions. The group operates under an open contribution model to develop standards for AI workload networking.

https://kubernetes.io/blog/2026/03/09/announcing-ai-gateway-wg/ kubernetes.io

RSS Hunter • Mar 9

Before You Migrate: Five Surprising Ingress-NGINX Behaviors You Need to Know

Kubernetes will retire Ingress-NGINX in March 2026, and users need to migrate to other solutions like Gateway API. Ingress-NGINX has several surprising defaults and side effects that can cause outages if not considered during migration. The blog post highlights these behaviors to help users migrate safely and make conscious decisions about which behaviors to keep. One of the key issues is that Ingress-NGINX treats regex patterns as prefix and case-insensitive matches, which can lead to unexpected routing. Gateway API, on the other hand, uses implementation-specific regex matching, and users need to check with their implementation to verify the semantics of regex matching. The post also discusses how to preserve Ingress-NGINX behavior in Gateway API, including using HTTP path matches with a type of RegularExpression and configuring redirects using the HTTP request redirect filter. Additionally, the post notes that Ingress-NGINX and NGINX Ingress are two separate Ingress controllers, and the blog post only discusses Ingress-NGINX. The nginx.ingress.kubernetes.io/use-regex annotation applies to all paths of a host across all Ingress-NGINX Ingresses, and the nginx.ingress.kubernetes.io/rewrite-target annotation silently adds the nginx.ingress.kubernetes.io/use-regex annotation, along with all its side effects. Ingress-NGINX also redirects requests missing a trailing slash to the same path with a trailing slash, which can cause outages if not explicitly configured in Gateway API. Overall, the post aims to help users understand the quirks of Ingress-NGINX and migrate to Gateway API safely. Users need to be aware of these behaviors and take steps to preserve them in Gateway API to avoid outages.

https://kubernetes.io/blog/2026/02/27/ingress-nginx-before-you-migrate/ kubernetes.io

RSS Hunter • Feb 27

Kubernetes v1.36: New Metric for Route Sync in the Cloud Controller Manager

Kubernetes v1.36 introduces a new alpha counter metric called route_controller_route_sync_total. This metric is part of the Cloud Controller Manager's route controller implementation. It increments every time routes are synchronized with the cloud provider. The metric's purpose is to help operators test the watch-based route reconciliation feature. This feature, introduced in v1.35, changes the route controller's behavior from a fixed interval to a watch-based approach. It reconciles routes only when node changes occur. This optimization reduces unnecessary API calls to infrastructure providers. Consequently, it lowers pressure on rate-limited APIs and improves quota efficiency. Operators can A/B test this by comparing the metric with the feature gate enabled versus disabled. In stable clusters with infrequent node changes, enabling the feature should lead to a significant decrease in sync operations. Feedback can be provided on Kubernetes Slack or GitHub. Further details are available in KEP-5237.

https://kubernetes.io/blog/2026/02/26/ccm-new-metric-route-sync-total/ kubernetes.io

RSS Hunter • Feb 26

Spotlight on SIG Architecture: API Governance

Jordan Liggitt leads the Kubernetes API Governance subproject, aiming to balance API stability with innovation. This project oversees all Kubernetes APIs, including command-line flags and configuration files, not just the REST API. Ensuring consistency and quality involves guidelines, conventions, and automated tools like linters. API Governance provides input during both API design and implementation, especially through the KEP process. The introduction of Custom Resources was a turning point, expanding API possibilities and necessitating enhanced validation. API Governance collaborates with SIG Architecture and API Machinery to define conventions and ensure API Machinery's consistent use. Involvement in the project increases before enhancements and code freezes in the release cycle. New contributors should start by following API changes and observing the review process. The project prioritizes compatibility and stability for users, even if it requires extra effort. The goal of API Governance is to plan for future API evolution while minimizing compatibility breaks. They consider mistakes will be made, and prepare to improve while keeping compatibility promises.

https://kubernetes.io/blog/2026/02/12/sig-architecture-api-spotlight/ kubernetes.io

RSS Hunter • Feb 12

Introducing Node Readiness Controller

Kubernetes often faces complexities in node readiness beyond the standard "Ready" status. The Node Readiness Controller (NRC) addresses this by providing a declarative system for managing node taints. The NRC ensures workloads only schedule on nodes meeting specific infrastructure requirements using custom health signals. It fills a critical gap, allowing operators to define custom scheduling gates tailored to particular node groups. This offers custom readiness definitions, automated taint management, and declarative node bootstrapping capabilities. The controller uses the NodeReadinessRule (NRR) API to define these gates, supporting both continuous and bootstrap-only enforcement modes. It reacts to Node Conditions, seamlessly integrating with existing tools such as Node Problem Detector. Dry run mode allows operators to simulate impact before applying actual taints, enhancing safety. An example demonstrates how the NRC ensures CNI agent functionality with a custom condition and taint. The project is actively seeking community feedback and encourages contributions via its GitHub, Slack, and documentation channels. The NRC aims to refine the node readiness process and advance Kubernetes' scheduling capabilities. The upcoming KubeCon Europe 2026 will feature a maintainer track session focused on the topic.

https://kubernetes.io/blog/2026/02/03/introducing-node-readiness-controller/ kubernetes.io

RSS Hunter • Feb 3

New Conversion from cgroup v1 CPU Shares to v2 CPU Weight

The document announces an improved conversion formula for mapping CPU shares from cgroup v1 to CPU weight in cgroup v2. The original linear formula presented two main issues limiting the performance of Kubernetes workloads. The first problem led to reduced CPU priority for Kubernetes workloads compared to non-Kubernetes processes in cgroup v2. The second was a lack of granularity for distributing resources within containers.The new approach utilizes a more complex quadratic formula to address these problems. The new conversion formula aims to provide better priority alignment, especially for containers requesting one CPU. The new formula also provides improved granularity for distributing resources within containers, better supporting fine-grained CPU resource distribution.This enhancement is implemented at the OCI layer, meaning it depends on the OCI runtime. Runc version 1.3.2 and crun version 1.23 onwards support the new formula. Existing deployments using tools or monitoring systems relying on the old linear formula may require updates. The Kubernetes project recommends testing the updated formula in non-production environments to ensure compatibility. Users can find more details in the provided links. The Kubernetes Node Special Interest Group welcomes new contributors for related challenges.

https://kubernetes.io/blog/2026/01/30/new-cgroup-v1-to-v2-cpu-conversion-formula/ kubernetes.io

RSS Hunter • Jan 30

Ingress NGINX: Statement from the Kubernetes Steering and Security Response Committees

The Kubernetes Steering Committee and Security Response Committee have announced the retirement of Ingress NGINX, a critical infrastructure component used by about half of cloud native environments, effective March 2026. The project has been in dire need of contributors and maintainers for years, and despite public warnings, it has not received the necessary support. After the retirement, there will be no more releases for bug fixes, security patches, or updates, leaving users vulnerable to attack if they do not migrate to alternative solutions. The committee emphasizes the severity of the situation and the importance of beginning migration to alternatives like Gateway API or third-party Ingress controllers immediately. Choosing to remain with Ingress NGINX after its retirement will leave users vulnerable to attack, and none of the available alternatives are direct drop-in replacements, requiring planning and engineering time. Existing deployments will continue to work, but users may not know they are affected until they are compromised, and they can check their reliance on Ingress NGINX by running a specific command with cluster administrator permissions. The Ingress NGINX project has been maintained by only one or two people working in their free time, and despite its widespread use, it has not received the necessary contributors to maintain it securely. The committee did not make the decision to retire Ingress NGINX lightly, but it is necessary for the safety of all users and the ecosystem as a whole due to the technical debt and fundamental design decisions that exacerbate security flaws. The committee urges users to check their clusters now and begin planning for migration if they are reliant on Ingress NGINX to avoid serious risk. The retirement of Ingress NGINX is a significant change that affects a large percentage of Kubernetes users, and it is imperative that users take immediate action to address the issue.

https://kubernetes.io/blog/2026/01/29/ingress-nginx-statement/ kubernetes.io

RSS Hunter • Jan 29

Experimenting with Gateway API using kind

This document provides a guide for setting up a local experimental environment for learning Gateway API concepts using kind. It emphasizes that this setup is not for production use. The process involves creating a kind Kubernetes cluster and deploying cloud-provider-kind, which offers LoadBalancer Services and a Gateway API controller. Users will then create a Gateway, deploy a demo echo application, and configure an HTTPRoute to direct traffic to this application. The guide includes steps to test the Gateway API configuration and provides troubleshooting tips for common issues. Finally, it outlines the cleanup process to remove all created resources and suggests next steps for exploring production-ready implementations and advanced Gateway API features. This local setup is specifically designed for understanding Gateway API principles without production complexities. It requires Docker, kubectl, kind, and curl to be installed. The cloud-provider-kind component simulates a cloud-enabled environment by providing necessary controllers and CRDs. Creating a Gateway involves defining a GatewayClass and listener configurations that accept specific hostnames and protocols. Deploying the echo application involves creating a namespace, Service, and Deployment. Configuring the HTTPRoute links the Gateway to the echo application for a specific hostname. Testing involves using curl to send a request to the Gateway's IP address with the defined hostname. Checking resource statuses and controller logs are recommended for troubleshooting. Cleanup involves deleting namespaces, stopping the cloud-provider-kind container, and deleting the kind cluster.

https://kubernetes.io/blog/2026/01/28/experimenting-gateway-api-with-kind/ kubernetes.io

RSS Hunter • Jan 28