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

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

Cluster API v1.12: Introducing In-place Updates and Chained Upgrades

Cluster API provides declarative management for Kubernetes cluster lifecycles. It utilizes controllers to reconcile cluster states, similar to how Kubernetes manages Pods with Deployments. The v1.12.0 release introduces significant enhancements, namely in-place updates and chained upgrades, to streamline common operations. In-place updates allow modifications to machines without full recreation, adopting an immutable infrastructure principle for simplicity and predictability. This new feature enables Cluster API to intelligently choose between immutable rollouts and in-place updates based on the nature of the change. Cluster API considers in-place updates most beneficial for changes not requiring node drains, like credential updates. Chained upgrades, on the other hand, allow users to jump multiple Kubernetes minor versions in a single operation. This feature computes and executes an upgrade plan, orchestrating control plane and worker machine updates sequentially. Worker machines intelligently skip intermediate versions when Kubernetes version skew policies permit. Extensibility through update extensions and upgrade plan runtime extensions ensures flexibility. Cluster API continues to evolve, focusing on safer upgrades and reduced disruption for managing Kubernetes at scale.

https://kubernetes.io/blog/2026/01/27/cluster-api-v1-12-release/ kubernetes.io

RSS Hunter • Jan 27

Headlamp in 2025: Project Highlights

Headlamp has significantly evolved throughout the year 2025, experiencing growth in community involvement, platform reach, and plugin integrations. The project is now officially part of Kubernetes SIG UI, strengthening its role within the core Kubernetes community. A crucial aspect of Headlamp's development involved collaboration with Linux Foundation mentorship program participants, leading to the creation of several valuable plugins. New features like multi-cluster views and projects have been added to streamline resource management and improve troubleshooting efficiency. Enhanced navigation with an activity model, and improved search and map functionalities have also been implemented. OIDC and authentication are now more robust, especially for in-cluster deployments. The app catalog and Helm support have been expanded. Performance, accessibility, and user experience have been prioritized, resulting in faster loading times and refinements. Headlamp also introduced an AI Assistant to simplify Kubernetes management. The plugin ecosystem has been broadened, with improved plugin development tools and better security upgrades. A plugins page was also created allowing for smoother plugin discovery.

https://kubernetes.io/blog/2026/01/22/headlamp-in-2025-project-highlights/ kubernetes.io

RSS Hunter • Jan 22

Announcing the Checkpoint/Restore Working Group

A new Kubernetes Working Group (WG) has been formed to focus on integrating Checkpoint/Restore functionality into Kubernetes. This initiative aims to explore various use cases through community discussion. These use cases include optimizing resource usage for interactive workloads like Jupyter notebooks and AI chatbots. It also addresses accelerating the startup of applications with lengthy initialization periods. Furthermore, the WG will investigate fault tolerance for long-running tasks through periodic checkpointing. Interruption-aware scheduling, allowing preemption of lower-priority pods while preserving application state, is another key area. Pod migration across nodes for load balancing and maintenance without service disruption is also a goal. Additionally, enabling forensic checkpointing for security incident analysis is being considered. The working group seeks to bridge discussions between the Kubernetes community and the Checkpoint/Restore in Userspace (CRIU) ecosystem. Projects like CRIU, checkpointctl, criu-coordinator, and checkpoint-restore-operator are relevant to these use cases. Interested contributors can join meetings, participate on Slack, or use the mailing list to engage with the WG.

https://kubernetes.io/blog/2026/01/21/introducing-checkpoint-restore-wg/ kubernetes.io

RSS Hunter • Jan 21

Uniform API server access using clientcmd

The text describes using the clientcmd library in Go to create command-line clients for Kubernetes APIs, mirroring kubectl's behavior. clientcmd handles loading configuration from various sources like ~/.kube/config and the KUBECONFIG environment variable. It allows overriding configurations via command-line flags, similar to kubectl. The library supports features like kubeconfig selection, context and namespace selection, and user authentication. Configuration merging prioritizes the first definition in a map and the last in a non-map. The usage involves loading rules, configuring overrides, building and binding flags using pflag, building the configuration itself, and finally, obtaining a Kubernetes API client. The clientcmd package provides functions for this process, including those to set command line arguments and retrieve the chosen namespace. A complete example is provided showing the implementation in code. The example demonstrates how to parse command line arguments using flags, configure the client, and interact with the Kubernetes API. The text recommends checking for empty configuration errors and handling them gracefully.

https://kubernetes.io/blog/2026/01/19/clientcmd-apiserver-access/ kubernetes.io

RSS Hunter • Jan 19

Kubernetes v1.35: Restricting executables invoked by kubeconfigs via exec plugin allowList added to kuberc

Kubectl utilizes credential plugins, executables specified in kubeconfig files, for authentication. This feature, while useful, raises security concerns as these plugins run with user privileges. An attacker could exploit compromised kubeconfig generation pipelines to execute malicious code. Kubernetes 1.35 introduces a beta feature for managing these plugins via credential plugin policies. Users can set policies in their kuberc configuration files to control which plugins can run. The credentialPluginPolicy can be set to AllowAll, DenyAll, or Allowlist. The Allowlist option allows specific plugins, by either full path or basename. Full paths are preferable for enhanced security, excluding globbing and wildcard usage. Future enhancements include checksum verification and digital signature checks for increased security. The Kubernetes community welcomes feedback and contributions to further improve this security feature. Users are encouraged to participate in discussions within the sig-cli and sig-auth channels. This security addition provides a way for users to restrict and control the execution of credential plugins within their environments.

https://kubernetes.io/blog/2026/01/09/kubernetes-v1-35-kuberc-credential-plugin-allowlist/ kubernetes.io

RSS Hunter • Jan 9

Kubernetes v1.35: Mutable PersistentVolume Node Affinity (alpha)

Kubernetes v1.35 introduces mutable PersistentVolume (PV) node affinity, allowing changes to volume accessibility post-creation. This feature, previously immutable, facilitates online volume management, addressing evolving storage provider capabilities. The primary motivation stems from scenarios like regional disk migrations and disk upgrades where node access changes. For instance, migrating from zonal to regional disks necessitates adjusting the PV node affinity to reflect the new region. Likewise, upgrading disks may require specifying newer node generations. While enabling this, administrators must ensure the underlying volume is updated before modifying the PV node affinity. A race condition may occur during tightening node affinity if the scheduler doesn't immediately reflect the changes. Currently, the Kubelet failing Pod startup when node affinity is violated is being discussed as a possible mitigation. The goal is to integrate this with VolumeAttributesClass, allowing automated updates via PersistentVolumeClaim. This alpha feature requires enabling a feature gate and appropriate RBAC permissions. The Kubernetes community encourages feedback from users and CSI driver developers regarding its implementation and usability. This is considered a first step towards more flexible and dynamic volume management.

https://kubernetes.io/blog/2026/01/08/kubernetes-v1-35-mutable-pv-nodeaffinity/ kubernetes.io

RSS Hunter • Jan 8

Kubernetes v1.35: A Better Way to Pass Service Account Tokens to CSI Drivers

Kubernetes v1.35 introduces a beta feature, CSI Driver Opt-in for Service Account Tokens via Secrets Field. Previously, service account tokens for CSI drivers were passed through the volume_context field, which is not ideal for sensitive data and has led to tokens being accidentally logged. This new feature allows CSI drivers to receive these tokens via the secrets field in NodePublishVolumeRequest, the designated place for sensitive information in the CSI specification. Existing CSI drivers will continue to receive tokens via volume_context by default, as the new serviceAccountTokenInSecrets field in the CSIDriver spec defaults to false.To adopt this feature, CSI driver authors should first implement fallback logic in their driver code. This logic checks both the secrets field and volume_context for tokens, ensuring compatibility with both older and newer Kubernetes versions. After deploying this updated driver, the cluster must be upgraded to Kubernetes v1.35 or later, including both kube-apiserver and kubelet. Once the cluster and driver are upgraded, the CSIDriver manifest can be updated to set serviceAccountTokenInSecrets: true.It is crucial to follow a specific rollout sequence to avoid breaking existing volumes. The driver update with fallback logic must be deployed and fully rolled out before updating the CSIDriver object to enable the new behavior. This opt-in mechanism eliminates the risk of accidental token logging, uses the correct CSI specification field for sensitive data, and is managed by the protosanitizer tool without needing driver-specific workarounds. CSI driver authors are encouraged to adopt this feature and provide feedback.

https://kubernetes.io/blog/2026/01/07/kubernetes-v1-35-csi-sa-tokens-secrets-field-beta/ kubernetes.io

RSS Hunter • Jan 7