# v1 Published articles for v1. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Kubernetes v1.37: Pod-Level Resource Managers graduated to Beta DevFeed: [Kubernetes v1.37: Pod-Level Resource Managers graduated to Beta]() Original publisher: [Read original article]() Author: Kevin Torres Martinez Published: 2026-09-15T18:30:00Z Content type: release Language: en Sources: [Kubernetes Blog]() Topics: [Kubernetes](), [cpu](), [Hardware](), [Latency](), [API](), [gRPC](), [Monitoring]() Tags: [api](), [cpu](), [hardware](), [kubernetes](), [latency](), [monitoring](), [numa](), [release](), [v1]() ### AI overview Kubernetes v1.37 graduates Pod-Level Resource Managers to Beta, disabled by default. The feature lets Kubelet resource managers use pod-level declarations for hardware placement, enabling NUMA-aligned exclusive resources for primary containers while placing sidecars in a shared pod-isolated pool. The release also adds pod-level reporting to the PodResources gRPC API. ### Source excerpt With the release of Kubernetes v1.37, the Pod-Level Resource Managers feature has graduated to Beta status (disabled by default)! First introduced as an Alpha feature in Kubernetes v1.36, this enhancement builds on Pod-Level Resources by equipping Kubelet's Topology Manager, CPU Manager, and Memory Manager to use Pod-level resource declarations (.spec.resources) directly when making hardware placement decisions. Bringing pod-level resources to node managers Before this feature, obtaining exclusive NUMA-aligned CPU cores or memory for latency-critical applications forced cluster operators into an all-or-nothing choice: assign integer resource requests to every container in the Pod, or forfeit exclusive NUMA alignment entirely. For modern workloads running lightweight sidecars (such as logging agents or telemetry exporters), allocating dedicated physical cores to auxiliary containers was wasteful. Pod-Level Resource Managers solves this challenge by enabling hybrid allocation models. The Kubelet can reserve exclusive NUMA-aligned resources for primary application containers while placing non-Guaranteed sidecars into a pod-isolated shared pool. This ensures primary workloads get unthrottled, NUMA-local performance while sidecars benefit from running in a pod-isolated shared pool, enjoying local NUMA alignment and protection from external node interference without consuming dedicated physical cores. What's new in Beta Graduating to Beta brings key operational and API enhancements: Graduation to Beta: Controlled by the PodLevelResourceManagers feature gate, available to opt in (disabled by default) in Kubernetes v1.37. PodResources API Reporting: The v1 PodResources gRPC service (PodResourcesLister) introduces top-level cpu_ids and memory fields on PodResources responses. Monitoring tools and device plugins can query pod-level exclusive assignments directly without double-counting container allocations. Getting started and providing feedback For a deep dive into the tech ## The Dodo Digest: The Report Is the Product DevFeed: [The Dodo Digest: The Report Is the Product]() Original publisher: [Read original article]() Author: Rishabh Goel Published: 2026-09-15T00:00:00Z Content type: article Language: en Sources: [Dodo Payments Blog]() Topics: [anthropic](), [Threat Research](), [Artificial Intelligence](), [Software Engineering]() Tags: [ai](), [anthropic](), [newsletter](), [product](), [report](), [threat-intelligence](), [v1]() ### AI overview This newsletter discusses Anthropic's report on eight months of AI misuse, including a campaign in which one person built an AI-assisted platform for mass attacks. It argues that startups can use reports to document learning, demonstrate expertise, and build trust, and mentions Dodo Payments v1.113.28 product improvements. ### Source excerpt Anthropic turned eight months of threat intelligence into a public report. Why every startup should document what it learns, plus v1.113.28: Reports, grace periods, and blocklists. ## Kubernetes v1.37: Memory QoS Graduates to Beta DevFeed: [Kubernetes v1.37: Memory QoS Graduates to Beta]() Original publisher: [Read original article]() Author: Qi Wang; Sohan Kunkerkar Published: 2026-09-14T18:30:00Z Content type: article Language: en Sources: [Kubernetes Blog]() Topics: [Kubernetes](), [releases](), [configuration](), [Linux](), [Kernel]() Tags: [clusters](), [configuration](), [container](), [kernel](), [kubernetes](), [linux](), [memory](), [qos](), [releases](), [upgrade](), [v1]() ### AI overview Kubernetes v1.37 promotes Memory QoS to Beta and enables it by default on Linux nodes using cgroup v2. The article explains the updated defaults, configuration options for memory throttling and tiered memory protection, and upgrade behavior intended to preserve existing runtime behavior. ### Source excerpt Memory QoS has graduated to Beta in Kubernetes v1.37 and is now enabled by default. On Linux nodes running cgroup v2, the feature uses the memory controller to give the kernel better guidance on how to treat container memory. It was first introduced as Alpha in v1.22, and expanded in v1.36 with tiered memory reservation. This post covers what changed in v1.37, what the Beta promotion means for cluster operators, and how to configure the feature. What changed in v1.37Memory QoS is Beta and enabled by default The MemoryQoS feature gate is now Beta in v1.37. This means every v1.37 kubelet has the feature gate turned on without any configuration change. Turning on the feature by default is safe because the default kubelet configuration does not enable memory throttling or memory reservation. No memory.high, memory.min, or memory.low values are written to cgroups unless you explicitly configure them. You can opt into specific behaviors through kubelet configuration fields: Set memoryThrottlingFactor (for example, 0.9) to enable memory.high throttling on Burstable and BestEffort containers. The default is null, which means no throttling. Set memoryReservationPolicy to TieredReservation to enable tiered memory protection via memory.min and memory.low. The default is None, which means no memory reservation. Default memoryThrottlingFactor changed to null In earlier Alpha releases, memoryThrottlingFactor defaulted to 0.9, which meant enabling the feature gate caused the kubelet to set memory.high on containers. In v1.37, the default is null, so the kubelet does not set memory.high unless you configure a value. This change was made because, with the feature gate now on by default, an automatic memory.high could throttle workloads that were previously running without throttling. Making it null ensures that upgrading to v1.37 does not change runtime behavior for existing clusters. If your kubelet configuration file already contains an explicit memoryThrottlingFactor value, that ## Kubernetes v1.37: KubeletInUserNamespace (aka Rootless mode) Graduates to Beta DevFeed: [Kubernetes v1.37: KubeletInUserNamespace (aka Rootless mode) Graduates to Beta]() Original publisher: [Read original article]() Author: Akihiro Suda Published: 2026-09-04T18:30:00Z Content type: release Language: en Sources: [Kubernetes Blog]() Topics: [Kubernetes](), [Vulnerabilities](), [Containers]() Tags: [containers](), [feature](), [kubernetes](), [linux](), [production](), [v1](), [vulnerabilities]() ### AI overview Kubernetes v1.37 promotes KubeletInUserNamespace, or rootless mode, to beta. It lets Kubernetes node components run as a non-root host user in a Linux user namespace, reducing the impact of container-breakout vulnerabilities while complementing conventional hardening such as seccomp. ### Source excerpt Kubernetes v1.37 promotes the KubeletInUserNamespace feature gate to beta. With this feature enabled, all of the node components (kubelet, CRI and OCI runtimes, CNI plugins, and kube-proxy) can run as a non-root user on the host, using a Linux user namespace. This technique is also known as rootless mode. The work started as an experiment in 2018, and was merged into Kubernetes v1.22 (2021) as an alpha feature (Kubernetes Enhancement Proposal KEP-2033). This feature should not be confused with user namespaces for pods (hostUsers: false with the UserNamespacesSupport feature gate, GA since v1.36), which puts pods in user namespaces but still runs the node components as root. These two features do not conflict. Moreover, they can be combined to nest Kubernetes inside Kubernetes without resorting to the full privileged: true. Why run the node components in a user namespace? Because the node components have historically had container-breakout vulnerabilities that could compromise full root privileges on the host. Examples of such vulnerabilities include: CVE-2022-0811 ("cr8escape"): CRI-O could be tricked into setting arbitrary sysctls, such as kernel.core_pattern, resulting in arbitrary code execution as root on the host CVE-2023-27561: runc could be tricked into bypassing the masked paths of a container via a volume mount race, exposing the host's procfs files (a regression of CVE-2019-19921) CVE-2024-10220: the kubelet could be made to execute arbitrary commands as root via gitRepo volumes (gitRepo volumes had a similar vulnerability, CVE-2018-11235, back in 2018 too) CVE-2025-31133: runc could be tricked into bind-mounting attacker-controlled paths and writing to the host's procfs files, such as /proc/sysrq-trigger and /proc/sys/kernel/core_pattern CVE-2026-53488: containerd could be tricked into executing arbitrary commands on the host, via crafted labels in a container image By running the node components in a user namespace, the potential damage is confined to th ## Kubernetes v1.37: Storage Version Migration Enabled by Default DevFeed: [Kubernetes v1.37: Storage Version Migration Enabled by Default]() Original publisher: [Read original article]() Author: Michael Aspinwall Published: 2026-08-31T18:30:00Z Content type: article Language: en Sources: [Kubernetes Blog]() Topics: [Kubernetes](), [migration](), [API](), [Encryption](), [releases]() Tags: [api](), [encryption](), [kubernetes](), [manifest](), [migration](), [releases](), [support](), [v1]() ### AI overview Kubernetes v1.37 makes Storage Version Migration generally available and enables it by default. The built-in API and control-plane controller migrate existing stored resources to the current storage version, addressing stale versions, encryption-at-rest changes, and key rotation. ### Source excerpt I am excited that storage version migration (SVM) has graduated to General Availability (GA) in Kubernetes v1.37! After a number of releases of work and testing, the built-in StorageVersionMigration API (storagemigration.k8s.io/v1) and control plane controller are now fully stable and enabled by default across all v1.37 Kubernetes clusters. The problem with stale storage versions In Kubernetes, stored API resources are written using a specific storage version (schema representation). The way Kubernetes interacts with object storage fundamentally requires mutation of a resource in order to ensure that the latest storage version is used for all resources. This creates problems when you want to change the storage version of a resource. One example of a scenario where you may want to change the storage version of a resource is when you are promoting a CRD to drop an older API version (such as v1alpha1) to a newer version (leaving just v1beta1 and v1). It's a problem to drop the older API version whilst there are still resources stored with the old alpha version. To avoid problems, you designate v1 as the new storage version; but, on it's own, that's not enough. While new writes are stored as v1, any existing resource could remain stored as v1alpha1 or v1beta1 in storage. You cannot safely remove v1alpha1 from the CRD's .status.storedVersions or drop serving support until every single resource in storage has been re-written to not be serialized and stored with the alpha version. Another relevant example is encryption at rest and, related, key rotation. When you configure encryption at rest or rotate encryption keys, existing resources in storage remain unencrypted (or encrypted under old keys) until they are actively re-written through the Kubernetes API server. Historically, cluster administrators and CRD authors had to rely on manual kubectl get / kubectl replace scripts, or to deploy the out-of-tree kube-storage-version-migrator component to force re-writes. These app ## 【kube-apiserver】CRD / aggregation / 扩展边界：API 扩展停损线 DevFeed: [【kube-apiserver】CRD / aggregation / 扩展边界：API 扩展停损线]() Original publisher: [Read original article]() Author: Liao Tonglang Published: 2026-08-28T00:00:00Z Content type: article Language: zh Sources: [土法炼钢 - 系统与基础设施]() Topics: [Kubernetes](), [API](), [etcd](), [Extension](), [Server]() Tags: [aggregation](), [api](), [api-server](), [apiserver](), [apiservice](), [authorization](), [crd](), [distributed](), [encryption](), [etcd](), [extension](), [kubernetes](), [v1](), [v1-30-3](), [v3-5](), [v3-5-33](), [webhook]() ### AI overview This article explains the boundary between Kubernetes CRD and Aggregated API extension paths in kube-apiserver. CRD requests remain within the apiserver and use its storage and admission paths, while Aggregated API requests are proxied to an external Extension Server. The two paths have different failure modes and troubleshooting points, although both can appear as 503 errors or timeouts. ### Source excerpt 厘清 CRD v1 与 Aggregated API 两条扩展路径在 kube-apiserver 中的存储与请求分界：CRD 对象存 etcd、conversion webhook 失败如何体现在 Storage 轴，APIService 则把请求转发到外部 Extension Server 可引发 503。明确 scheduler/controller/kubelet 为扩展停损线之外的数据面与控制循环。 ## 【kube-apiserver】Watch cache / cacher：dispatch、bookmark 与穿透 etcd DevFeed: [【kube-apiserver】Watch cache / cacher：dispatch、bookmark 与穿透 etcd]() Original publisher: [Read original article]() Author: Liao Tonglang Published: 2026-08-28T00:00:00Z Content type: article Language: zh Sources: [土法炼钢 - 系统与基础设施]() Topics: [Caching](), [Kubernetes](), [API](), [Kubernetes v1.32]() Tags: [410-gone](), [apiserver](), [bookmark](), [cache](), [cacher](), [distributed](), [kubernetes](), [metrics](), [resourceversion](), [storage](), [v1](), [v1-30-3](), [watch-cache]() ### AI overview This article explains the Kubernetes v1.30.3 apiserver watch cache and cacher implementation. It covers the watchCache sliding window, the Ready gate during startup synchronization, in-memory event dispatch, bookmark progress notifications, and the conditions that cause cache misses to fall back to etcd. ### Source excerpt 钉 Kubernetes v1.30.3 cacher 对 storage.Interface 的包装：watchCache 滑动窗口与 Ready 门、bookmark 推送路径、cache miss 打穿 etcd 的触发条件，以及 List 风暴成因与 watch cache SLO 与 compaction 间隔之间的开放问题。 ## 【kube-apiserver】Authorization 与 Audit：RBAC、SAR 与 403 分列 DevFeed: [【kube-apiserver】Authorization 与 Audit：RBAC、SAR 与 403 分列]() Original publisher: [Read original article]() Author: Liao Tonglang Published: 2026-08-28T00:00:00Z Content type: tutorial Language: zh Sources: [土法炼钢 - 系统与基础设施]() Topics: [Authorization](), [Kubernetes](), [audit](), [API]() Tags: [403](), [admission](), [api](), [apiserver](), [audit](), [auth](), [authorization](), [authz](), [distributed](), [etcd](), [http](), [k8s](), [kubernetes](), [policy](), [post](), [rbac](), [subjectaccessreview](), [v1](), [v1-30-3](), [webhook]() ### AI overview This tutorial explains Kubernetes v1.30.3 authorization and auditing. It distinguishes the RBAC, Node, Webhook, and legacy ABAC authorizer paths; describes SAR and SSAR access checks; outlines audit policies and stages; and explains why user-facing 403 errors come from Kubernetes authorization rather than etcd permissions or Admission failures. ### Source excerpt 钉 K8s v1.30.3 的授权链：RBAC、Node、Webhook、ABAC（遗留）；SubjectAccessReview / SelfSubjectAccessReview 用法；Audit policy 四级；403 与 etcd 权限错误、Admission 拒绝的分列；不把 etcd 的 mTLS 错误写成 K8s RBAC 故障。 ## Kubernetes v1.37: Metrics API graduates to stable DevFeed: [Kubernetes v1.37: Metrics API graduates to stable]() Original publisher: [Read original article]() Author: ChengHao Yang Published: 2026-08-27T18:30:00Z Content type: article Language: en Sources: [Kubernetes Blog]() Topics: [Kubernetes](), [API](), [autoscaling](), [cpu](), [Monitoring]() Tags: [api](), [autoscaling](), [cpu](), [developers](), [kubernetes](), [memory](), [metrics](), [monitoring](), [production](), [release](), [resource](), [v1]() ### AI overview Kubernetes v1.37 promotes the Metrics API to the stable v1 version. The API provides CPU and memory usage for nodes and Pods, supporting commands such as kubectl top and resource-metrics-based autoscaling, without changing the collected metrics, resource types, or fields. ### Source excerpt Kubernetes v1.37 promotes the metrics.k8s.io API to stable (v1). This API provides CPU and memory usage for nodes and Pods, and is the API behind commands such as kubectl top and resource-metrics-based autoscaling. For cluster operators and application developers, this graduation means that the API now has the stability guarantees associated with a Kubernetes stable API. The v1 API has the same resource types and fields as v1beta1; this is an API-version graduation, not a change to the metrics that are collected or returned. A long-lived API reaches stable The resource Metrics API was introduced as alpha in Kubernetes v1.6 and became beta in v1.8. It has remained unchanged and has been used in production for years by clients including the HorizontalPodAutoscaler (HPA) and kubectl top. Kubernetes v1.37 formally graduates that proven API to metrics.k8s.io/v1. The API exposes two resource types: NodeMetrics, for CPU and memory usage for a node. PodMetrics, for CPU and memory usage for a Pod, with a per-container breakdown in its containers field. The API remains intentionally small. It provides the resource metrics needed for autoscaling and basic inspection; it is not a replacement for a full monitoring pipeline or the custom metrics (custom.metrics.k8s.io) API. What changed with the v1.37 release? The v1 API surface is identical to v1beta1, except for the API version. There are no renamed fields, new fields, or changes to the meaning of the returned CPU and memory values. For example, a client can retrieve node metrics from the stable endpoint: kubectl get --raw /apis/metrics.k8s.io/v1/nodes Likewise, it can retrieve metrics for the pods in a namespace: kubectl get --raw /apis/metrics.k8s.io/v1/namespaces/default/pods kubectl top supports both API versions. It prefers v1 when available and automatically falls back to v1beta1 on clusters that do not yet serve v1. The HPA controller currently supports only v1beta1. Support for discovery-based selection between v1 and v ## Kubernetes v1.37: Garhwal DevFeed: [Kubernetes v1.37: Garhwal]() Original publisher: [Read original article]() Author: Kubernetes v Published: 2026-08-26T00:00:00Z Content type: article Language: en Sources: [Kubernetes Blog]() Topics: [Kubernetes](), [Kubernetes v1.33](), [releases]() Tags: [community](), [kubernetes](), [release](), [releases](), [v1]() ### AI overview Kubernetes v1.37, named Garhwal, introduces 67 enhancements across Stable, Beta, and Alpha stages, including a deprecation or removal. The article also explains the release theme and its Himalayan-inspired logo. ### Source excerpt Editors: Arsh Sharma, Christopher Tineo, Kirti Goyal, Sophia Ugochukwu, Swathi Rao, Troy Connor Similar to previous releases, the release of Kubernetes v1.37 introduces new Stable, Beta, and Alpha features. The consistent delivery of high-quality releases underscores the strength of our development cycle and the vibrant support from our community. This release consists of 67 enhancements. Of those enhancements, 16 have graduated to Stable, 23 have graduated to Beta, 27 are entering Alpha, and 1 is a deprecation/removal. Release theme and logo The theme for Kubernetes v1.37 is Garhwal (गढ़वाल, pronounced gaṛhvāl), a Himalayan region of Uttarakhand, India. The snow-capped peaks of the Garhwal Himalaya, deodar forests, terraced fields, rivers and streams, and mountain paths shape both the region and the logo. Together, these elements reflect a community in which every layer, route, and contribution is connected. The logo is imagined as a window into Garhwal's landscape.1 Inside, terraced fields climb towards the snowy peaks, each level supported by the one below, much as every Kubernetes release depends on work carried forward. A river winds through the valley and gathers mountain streams, reflecting contributions from many SIGs and communities flowing into one project. The deodar forest represents the wider Kubernetes ecosystem, where distinct projects share common ground and grow side by side. Stonework and woodcraft shape the path and mountain house, placing people at the centre and evoking shared foundations maintained for those who follow. Above the river, colourful flags catch the wind and bring the scene to life. Encircling the scene is a patterned frame inspired by basketry woven from ringaal, a flexible dwarf Himalayan bamboo. Individual strips gain strength when interlaced, just as code, reviews, tests, documentation, and coordination come together to make a release. Within the frame, the Himalayan monal, Uttarakhand's state bird, lives at high altitudes in t ## The Dodo Digest: Don't Make Customers Learn How to Pay DevFeed: [The Dodo Digest: Don't Make Customers Learn How to Pay]() Original publisher: [Read original article]() Author: Rishabh Goel Published: 2026-08-24T00:00:00Z Content type: article Language: en Sources: [Dodo Payments Blog]() Topics: [P2P](), [App]() Tags: [analytics](), [billing](), [checkout](), [newsletter](), [payments](), [tiktok](), [updates](), [v1](), [whatsapp]() ### AI overview TikTok is exploring peer-to-peer payments in direct messages, while Venmo is expanding into tuition payments. The article argues that products should support payment methods customers already trust to reduce checkout friction and payment-related drop-off. It also highlights Dodo Payments v1.112.0 updates to discount codes, payments, billing, webhooks, and analytics. ### Source excerpt TikTok explores payments in DMs and Venmo moves into tuition. Why founders should offer the payment methods customers already trust, plus v1.112.0 updates. ## The Dodo Digest: Building in Public Means Failing in Public DevFeed: [The Dodo Digest: Building in Public Means Failing in Public]() Original publisher: [Read original article]() Author: Rishabh Goel Published: 2026-08-07T00:00:00Z Content type: article Language: en Sources: [Dodo Payments Blog]() Topics: [Artificial Intelligence](), [Security](), [anthropic](), [Claude](), [OpenAI](), [Software]() Tags: [ai](), [announcement](), [anthropic](), [building](), [claude](), [community](), [newsletter](), [openai](), [security](), [software](), [updates](), [v1]() ### AI overview Dodo Payments describes how AI-enhanced office photos became the focus of a viral debate about authenticity and public scrutiny. The newsletter also discusses startup visibility, product security, fraud and operational abuse, and the company's v1.112.0 release with discount-code, webhooks, payment-method, and analytics improvements. ### Source excerpt Our AI-enhanced office photos hit 11M views and a Community Note. Plus v1.112.0: amount discount codes, rebuilt webhooks, Cash App Pay, and SEPA Direct Debit. ## Gateway API v1.6: TCPRoute and UDPRoute Graduate to Standard DevFeed: [Gateway API v1.6: TCPRoute and UDPRoute Graduate to Standard]() Original publisher: [Read original article]() Author: Beka Modebadze; Ricardo Katz Published: 2026-08-03T16:00:00Z Content type: article Language: en Sources: [Kubernetes Blog]() Topics: [Kubernetes](), [networking](), [Protocol (disambiguation)](), [API](), [releases]() Tags: [api](), [kubernetes](), [networking](), [release](), [v1]() ### AI overview Gateway API v1.6.0 expands Kubernetes service networking with TCPRoute and UDPRoute graduating to the Standard channel and v1 API, enabling portable Layer 4 routing for raw TCP and UDP traffic. The release also separates experimental API resources into a distinct group. ### Source excerpt The Kubernetes SIG Network community is thrilled to share the release of Gateway API v1.6.0, which was released on June 30th of this year! Gateway API has become the standard for modern, role-oriented, and expressive service networking in Kubernetes. In previous releases, Gateway API established a production-grade foundation for HTTP and TLS layer 7 traffic. With version 1.6.0, Gateway API takes a major step forward by expanding standard layer 4 protocol routing and introducing cleaner API boundaries for experimental innovation. Here is a quick summary of what's new in Gateway API v1.6.0: TCPRoute and UDPRoute Graduate to Standard: Raw L4 TCP and UDP traffic routing reach GA stability in the v1 API version. Experimental API Group Separation: Experimental resources transition to a distinct API group (gateway.networking.x-k8s.io) with an X prefix to make experimental vs. standard boundaries crystal clear. Let's dive into the details! TCPRoute and UDPRoute graduate to Standard Leads: Nick Young, Ricardo Katz and Zac Nixon GEP-2644 - TCPRoute GEP-2645 - UDPRoute Until now, Gateway API only offered a stable routing model for HTTP and TLS traffic. Workloads that speak a raw protocol over TCP or UDP - databases, DNS, VoIP, gaming, IoT telemetry - had no portable way to plug into a Gateway. Users either fell back to a plain Kubernetes Service, or to an implementation-specific CRD that doesn't travel between Gateway controllers. TCPRoute and UDPRoute close that gap: they route traffic to backends based on protocol and port alone, no L7 awareness required. With this release, both have graduated from the Experimental channel to Standard, and moved to the v1 API version. The v1alpha2 version of each was deprecated as of the v1.6 release, and will be removed in a future release. How it works A Gateway needs a listener that allows TCPRoute attachment: apiVersion: gateway.networking.k8s.io/v1 kind: Gateway metadata: name: example-gateway spec: gatewayClassName: example-gateway-cla ## Kubernetes v1.36: PSI Metrics for Kubernetes Graduates to GA DevFeed: [Kubernetes v1.36: PSI Metrics for Kubernetes Graduates to GA]() Original publisher: [Read original article]() Author: Maria Fernanda Romano Silva Published: 2026-05-12T18:35:00Z Content type: article Language: en Sources: [Kubernetes Blog]() Topics: [Kubernetes](), [telemetry](), [Performance Testing](), [cpu](), [Latency](), [Linux](), [Monitoring](), [IO]() Tags: [cpu](), [kernel](), [kubernetes](), [latency](), [linux](), [metrics](), [monitoring](), [performance](), [performance-testing](), [production](), [resource](), [scale](), [telemetry](), [testing](), [v1]() ### AI overview Kubernetes v1.36 graduates Pressure Stall Information (PSI) metrics to general availability, providing stable visibility into CPU, memory, and I/O resource contention at node, pod, and container levels. The article explains PSI signals, moving averages, and performance validation on high-density workloads to assess production readiness and collection overhead. ### Source excerpt Since its original implementation in the Linux kernel in 2018, Pressure Stall Information (PSI) has provided users with the high-fidelity signals needed to identify resource saturation before it becomes an outage. Unlike traditional utilization metrics, PSI tells the story of tasks stalled and time lost, all in nicely-packaged percentages of time across the CPU, memory, and I/O. With the recent release of Kubernetes v1.36, users across the ecosystem have a stable, reliable interface to observe resource contention at the node, pod, and container levels. In this post, we will dive into the improvements and performance testing that proved its readiness for production. Beyond utilization: why PSI? Monitoring CPU or memory usage alone can be misleading. A node may report XX% (below 100%) CPU utilization while certain tasks are experiencing severe latency due to scheduling delays. PSI fills this gap by providing: Cumulative Totals: Absolute time spent in a stalled state. Moving Averages: 10s, 60s, and 300s windows that allow operators to distinguish between transient spikes and sustained resource tension. Proving stability: performance testing at scale A common concern when graduating telemetry features is the resource overhead required to collect and serve the metrics. To address this, SIG Node conducted extensive performance validation on high-density workloads (80+ pods) across various machine types. Our testing focused on two primary scenarios to isolate the impact of the Kubelet and kernel-level collection respectively: Kernel PSI ON / Kubelet Feature OFF vs Kernel PSI ON / Kubelet Feature ON (Kubelet overhead) Kernel PSI OFF / Kubelet Feature ON vs Kernel PSI ON / Kubelet Feature ON (Kernel overhead) Scenario 1: The Kubelet Overhead First, we looked at the kubelet usage on 4 core machines (Case 1). For these, the Linux kernel was already tracking pressure on both clusters by default(psi=1), but we toggled the KubeletPSI feature gate to see if the Kubelet actively qu ## Kubernetes v1.36: Moving Volume Group Snapshots to GA DevFeed: [Kubernetes v1.36: Moving Volume Group Snapshots to GA]() Original publisher: [Read original article]() Author: Xing Yang Published: 2026-05-08T18:35:00Z Content type: article Language: en Sources: [Kubernetes Blog]() Topics: [Kubernetes](), [API](), [data](), [Provisioning](), [App](), [systems]() Tags: [api](), [applications](), [data](), [kubernetes](), [release](), [storage](), [systems](), [v1]() ### AI overview Kubernetes v1.36 promotes volume group snapshots to General Availability. The feature uses extension APIs and label selectors to create crash-consistent snapshots of multiple volumes, which can be restored to new or existing volumes. It is supported for CSI volume drivers. ### Source excerpt Volume group snapshots were introduced as an Alpha feature with the Kubernetes v1.27 release, moved to Beta in v1.32, and to a second Beta in v1.34. We are excited to announce that in the Kubernetes v1.36 release, support for volume group snapshots has reached General Availability (GA). The support for volume group snapshots relies on a set of extension APIs for group snapshots. These APIs allow users to take crash-consistent snapshots for a set of volumes. Behind the scenes, Kubernetes uses a label selector to group multiple PersistentVolumeClaim objects for snapshotting. A key aim is to allow you to restore that set of snapshots to new volumes and recover your workload based on a crash-consistent recovery point. This feature is only supported for CSI volume drivers. An overview of volume group snapshots Some storage systems provide the ability to create a crash-consistent snapshot of multiple volumes. A group snapshot represents copies made from multiple volumes that are taken at the same point-in-time. A group snapshot can be used either to rehydrate new volumes (pre-populated with the snapshot data) or to restore existing volumes to a previous state (represented by the snapshots). Why add volume group snapshots to Kubernetes? The Kubernetes volume plugin system already provides a powerful abstraction that automates the provisioning, attaching, mounting, resizing, and snapshotting of block and file storage. Underpinning all these features is the Kubernetes goal of workload portability. There was already a VolumeSnapshot API that provides the ability to take a snapshot of a persistent volume to protect against data loss or data corruption. However, some storage systems support consistent group snapshots that allow a snapshot to be taken from multiple volumes at the same point-in-time to achieve write order consistency. This is extremely useful for applications that contain multiple volumes. For example, an application may have data stored in one volume and logs st ## ESP-IDF Extension for VS Code: What's New in v2.1.0 DevFeed: [ESP-IDF Extension for VS Code: What's New in v2.1.0]() Original publisher: [Read original article]() Author: John Lee Published: 2026-05-08T00:00:00Z Content type: release Language: en Sources: [Blog on Developer Portal]() Topics: [ESP-IDF Extension for vs Code](), [VS Code Extension](), [Visual Studio Code](), [Espressif](), [releases](), [Developer experience](), [debug]() Tags: [ai](), [blog](), [debugging](), [eim](), [esp-idf](), [esp-idf-extension-for-vs-code](), [esp-idf-tool](), [espressif](), [improvements](), [installation](), [integration](), [release](), [v1](), [vs-code]() ### AI overview This article reviews releases v1.10.0 through v2.1.0 of the ESP-IDF Extension for VS Code. It highlights integration with the cross-platform Espressif Installation Manager, automatic discovery of installed ESP-IDF versions, GUI and terminal installation flows, improved debugging, AI-assisted workflows, and a refreshed native UI. ### Source excerpt A look at the Espressif Installation Manager (EIM) integration in the ESP-IDF Extension for VS Code, and a roundup of all major improvements across v1.10.x, v1.11.x, v2.0.2, and v2.1.0. ## Kubernetes v1.36: More Drivers, New Features, and the Next Era of DRA DevFeed: [Kubernetes v1.36: More Drivers, New Features, and the Next Era of DRA]() Original publisher: [Read original article]() Author: The DRA team Published: 2026-05-07T18:35:00Z Content type: article Language: en Sources: [Kubernetes Blog]() Topics: [Kubernetes](), [Hardware](), [systems](), [networking](), [Availability]() Tags: [availability](), [drivers](), [feature](), [hardware](), [infrastructure](), [kubernetes](), [release](), [resource](), [resources](), [systems](), [v1]() ### AI overview Kubernetes v1.36 advances Dynamic Resource Allocation (DRA) with feature graduations, broader driver support, and improved handling of hardware and native resources. The article covers prioritized device requests, extended resource compatibility, partitionable devices, and support for sharing specialized hardware across workloads. ### Source excerpt Dynamic Resource Allocation (DRA) has fundamentally changed how platform administrators handle hardware accelerators and specialized resources in Kubernetes. In the v1.36 release, DRA continues to mature, bringing a wave of feature graduations, critical usability improvements, and new capabilities that extend the flexibility of DRA to native resources like memory and CPU, and support for ResourceClaims in PodGroups. Driver availability continues to expand. Beyond specialized compute accelerators, the ecosystem includes support for networking and other hardware types, reflecting a move toward a more robust, hardware-agnostic infrastructure. Whether you are managing massive fleets of GPUs, need better handling of failures, or simply looking for better ways to define resource fallback options, the upgrades to DRA in 1.36 have something for you. Let's dive into the new features and graduations! Feature graduations The community has been hard at work stabilizing core DRA concepts. In Kubernetes 1.36, several highly anticipated features have graduated to Beta and Stable. Prioritized list (stable) Hardware heterogeneity is a reality in most clusters. With the Prioritized list feature, you can confidently define fallback preferences when requesting devices. Instead of hardcoding a request for a specific device model, you can specify an ordered list of preferences (e.g., "Give me an H100, but if none are available, fall back to an A100"). The scheduler will evaluate these requests in order, drastically improving scheduling flexibility and cluster utilization. Extended resource support (beta) As DRA becomes the standard for resource allocation, bridging the gap with legacy systems is crucial. The DRA Extended resource feature allows users to request resources via traditional extended resources on a Pod. This allows for a gradual transition to DRA, meaning cluster operators can migrate clusters to DRA but let application developers adopt the ResourceClaim API on their own sche ## Kubernetes v1.36: Server-Side Sharded List and Watch DevFeed: [Kubernetes v1.36: Server-Side Sharded List and Watch]() Original publisher: [Read original article]() Author: Jeffrey Ying Published: 2026-05-06T18:35:00Z Content type: article Language: en Sources: [Kubernetes Blog]() Topics: [Kubernetes](), [Kubernetes v1.32](), [API](), [servers]() Tags: [api](), [cpu](), [kubernetes](), [memory](), [network](), [v1]() ### AI overview Kubernetes v1.36 introduces server-side sharded list and watch as an alpha feature. The API server filters high-cardinality resource events by deterministic hash ranges, reducing unnecessary CPU, memory, and network usage for horizontally scaled controllers. ### Source excerpt As Kubernetes clusters grow to tens of thousands of nodes, controllers that watch high-cardinality resources like Pods face a scaling wall. Every replica of a horizontally scaled controller receives the full stream of events from the API server, paying the CPU, memory, and network cost to deserialize everything, only to discard the objects it is not responsible for. Scaling out the controller does not reduce per-replica cost; it multiplies it. Kubernetes v1.36 introduces server-side sharded list and watch as an alpha feature (KEP-5866). With this feature enabled, the API server filters events at the source so that each controller replica receives only the slice of the resource collection it owns. The problem with client-side sharding Some controllers, such as kube-state-metrics, already support horizontal sharding. Each replica is assigned a portion of the keyspace and discards objects that do not belong to it. While this works functionally, it does not reduce the volume of data flowing from the API server: N replicas x full event stream: every replica deserializes and processes every event, then throws away what it does not need. Network bandwidth scales with replicas, not with shard size. CPU spent on deserialization is wasted for the discarded fraction. Server-side sharded list and watch solves this by moving the filtering upstream into the API server. Each replica tells the API server which hash range it owns, and the API server only sends matching events. How it works The feature adds a shardSelector field to ListOptions. Clients specify a hash range using the shardRange() function: shardRange(object.metadata.uid, '0x0000000000000000', '0x8000000000000000') The API server computes a deterministic 64-bit FNV-1a hash of the specified field and returns only objects whose hash falls within the range [start, end). This applies to both list responses and watch event streams. The hash function produces the same result across all API server instances, so the feature is ## Kubernetes v1.36: Declarative Validation Graduates to GA DevFeed: [Kubernetes v1.36: Declarative Validation Graduates to GA]() Original publisher: [Read original article]() Author: Yongrui Lin Published: 2026-05-05T18:35:00Z Content type: article Language: en Sources: [Kubernetes Blog]() Topics: [Kubernetes](), [API](), [Code](), [Go Language](), [Boilerplate](), [OpenAPI Specification](), [migration](), [Tooling]() Tags: [api](), [apis](), [code](), [contributors](), [developers](), [ecosystem](), [errors](), [feature](), [framework](), [go](), [kubernetes](), [migration](), [openapi](), [release](), [tooling](), [v1](), [validation]() ### AI overview Kubernetes v1.36 makes declarative validation for Kubernetes native types generally available. The article explains how marker tags and generated Go validation functions replace extensive handwritten validation code, improving maintainability, consistency, API discoverability, and integration with OpenAPI and ecosystem tooling. ### Source excerpt In Kubernetes v1.36, Declarative Validation for Kubernetes native types has reached General Availability (GA). For users, this means more reliable, predictable, and better-documented APIs. By moving to a declarative model, the project also unlocks the future ability to publish validation rules via OpenAPI and integrate with ecosystem tools like Kubebuilder. For contributors and ecosystem developers, this replaces thousands of lines of handwritten validation code with a unified, maintainable framework. This post covers why this migration was necessary, how the declarative validation framework works, and what new capabilities come with this GA release. The Motivation: Escaping the "Handwritten" Technical Debt For years, the validation of Kubernetes native APIs relied almost entirely on handwritten Go code. If a field needed to be bounded by a minimum value, or if two fields needed to be mutually exclusive, developers had to write explicit Go functions to enforce those constraints. As the Kubernetes API surface expanded, this approach led to several systemic issues: Technical Debt: The project accumulated roughly 18,000 lines of boilerplate validation code. This code was difficult to maintain, error-prone, and required intense scrutiny during code reviews. Inconsistency: Without a centralized framework, validation rules were sometimes applied inconsistently across different resources. Opaque APIs: Handwritten validation logic was difficult to discover or analyze programmatically. This meant clients and tooling couldn't predictably know validation rules without consulting the source code or encountering errors at runtime. The solution proposed by SIG API Machinery was Declarative Validation: using Interface Definition Language (IDL) tags (specifically +k8s: marker tags) directly within types.go files to define validation rules. Enter validation-gen At the core of the declarative validation feature is a new code generator called validation-gen. Just as Kubernetes uses ge ## Kubernetes v1.36: In-Place Vertical Scaling for Pod-Level Resources Graduates to Beta DevFeed: [Kubernetes v1.36: In-Place Vertical Scaling for Pod-Level Resources Graduates to Beta]() Original publisher: [Read original article]() Author: Narang Dixita Sohanlal Published: 2026-04-30T18:35:00Z Content type: article Language: en Sources: [Kubernetes Blog]() Topics: [Kubernetes](), [autoscaling](), [Containers]() Tags: [containers](), [cpu](), [feature](), [kubernetes](), [resources](), [scale](), [update](), [v1]() ### AI overview Kubernetes v1.36 promotes in-place vertical scaling for pod-level resources to beta and enables it by default. Running Pods can resize their shared aggregate resource budget, often without restarting containers. ### Source excerpt Following the graduation of Pod-Level Resources to Beta in v1.34 and the General Availability (GA) of In-Place Pod Vertical Scaling in v1.35, the Kubernetes community is thrilled to announce that In-Place Pod-Level Resources Vertical Scaling has graduated to Beta in v1.36! This feature is now enabled by default via the InPlacePodLevelResourcesVerticalScaling feature gate. It allows users to update the aggregate Pod resource budget (.spec.resources) for a running Pod, often without requiring a container restart. Why Pod-level in-place resize? The Pod-level resource model simplified management for complex Pods (such as those with sidecars) by allowing containers to share a collective pool of resources. In v1.36, you can now adjust this aggregate boundary on-the-fly. This is particularly useful for Pods where containers do not have individual limits defined. These containers automatically scale their effective boundaries to fit the newly resized Pod-level dimensions, allowing you to expand the shared pool during peak demand without manual per-container recalculations. Resource inheritance and the resizePolicy When a Pod-level resize is initiated, the Kubelet treats the change as a resize event for every container that inherits its limits from the Pod-level budget. To determine whether a restart is required, the Kubelet consults the resizePolicy defined within individual containers: Non-disruptive Updates: If a container's restartPolicy is set to NotRequired, the Kubelet attempts to update the cgroup limits dynamically via the Container Runtime Interface (CRI). Disruptive Updates: If set to RestartContainer, the container will be restarted to apply the new aggregate boundary safely. Note: Currently, resizePolicy is not supported at the Pod level. The Kubelet always defers to individual container settings to decide if an update can be applied in-place or requires a restart. Example: Scaling a shared resource pool In this scenario, a Pod is defined with a 2 CPU pod-level ## Kubernetes v1.36: Tiered Memory Protection with Memory QoS DevFeed: [Kubernetes v1.36: Tiered Memory Protection with Memory QoS]() Original publisher: [Read original article]() Author: Qi Wang; Sohan Kunkerkar Published: 2026-04-29T18:35:00Z Content type: news Language: en Sources: [Kubernetes Blog]() Topics: [Kubernetes](), [configuration](), [observability](), [kernels]() Tags: [feature](), [kernels](), [kubernetes](), [memory](), [metrics](), [observability](), [v1]() ### AI overview Kubernetes v1.36 updates the alpha Memory QoS feature with opt-in memory reservation, tiered protection based on Pod QoS class, observability metrics, and a warning for kernels older than 5.9. Guaranteed Pods receive hard protection, Burstable Pods receive reclaimable soft protection, and BestEffort Pods remain fully reclaimable. ### Source excerpt On behalf of SIG Node, we are pleased to announce updates to the Memory QoS feature (alpha) in Kubernetes v1.36. Memory QoS uses the cgroup v2 memory controller to give the kernel better guidance on how to treat container memory. It was first introduced in v1.22 and updated in v1.27. In Kubernetes v1.36, we're introducing: opt-in memory reservation, tiered protection by QoS class, observability metrics, and kernel-version warning for memory.high. What's new in v1.36Opt-in memory reservation with memoryReservationPolicy v1.36 separates throttling from reservation. Enabling the feature gate turns on memory.high throttling (the kubelet sets memory.high based on memoryThrottlingFactor, default 0.9), but memory reservation is now controlled by a separate kubelet configuration field: None (default): no memory.min or memory.low is written. Throttling via memory.high still works. TieredReservation: the kubelet writes tiered memory protection based on the Pod's QoS class: Guaranteed Pods get hard protection via memory.min. For example, a Guaranteed Pod requesting 512 MiB of memory results in: $ cat /sys/fs/cgroup/kubepods.slice/kubepods-pod6a4f2e3b_1c9d_4a5e_8f7b_2d3e4f5a6b7c.slice/memory.min 536870912 The kernel will not reclaim this memory under any circumstances. If it cannot honor the guarantee, it invokes the OOM killer on other processes to free pages. Burstable Pods get soft protection via memory.low. For the same 512 MiB request on a Burstable Pod: $ cat /sys/fs/cgroup/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-pod8b3c7d2e_4f5a_6b7c_9d1e_3f4a5b6c7d8e.slice/memory.low 536870912 The kernel avoids reclaiming this memory under normal pressure, but may reclaim it if the alternative is a system-wide OOM. BestEffort Pods get neither memory.min nor memory.low. Their memory remains fully reclaimable. Comparison with v1.27 behavior In earlier versions, enabling the MemoryQoS feature gate immediately set memory.min for every container with a memory request. memo ## TRL v1.0: Post-Training Library Built to Move with the Field DevFeed: [TRL v1.0: Post-Training Library Built to Move with the Field]() Original publisher: [Read original article]() Author: Quentin Gallouédec; Steven Liu; Pedro Cuenca; Sergio Paniego Published: 2026-03-31T00:00:00Z Content type: article Language: en Sources: [Hugging Face - Blog]() Topics: [trl](), [post-training](), [dpo](), [grpo](), [rlvr](), [Artificial Intelligence](), [Code]() Tags: [announcement](), [artificial-intelligence](), [code](), [dpo](), [grpo](), [open-source](), [post-training](), [reinforcement-learning](), [rlvr](), [software](), [trl](), [v1]() ### AI overview TRL v1.0 presents a post-training library designed to remain useful as algorithms, models, and paradigms change. The article explains the evolution from PPO to DPO-style preference optimization and RLVR methods such as GRPO, emphasizing flexible abstractions and practical comparison over a supposedly permanent design. ### Source excerpt We're on a journey to advance and democratize artificial intelligence through open source and open science. ## Node.js 22.22.0 (LTS) DevFeed: [Node.js 22.22.0 (LTS)]() Original publisher: [Read original article]() Published: 2026-01-13T14:18:09Z Content type: release Language: en Sources: [Node.js Blog]() Topics: [Node.js](), [Security](), [JavaScript](), [Open Source](), [cross-platform](), [Command-line interface](), [Server]() Tags: [command-line](), [cross-platform](), [javascript](), [node-js](), [open-source](), [release](), [security](), [servers](), [v1]() ### AI overview Node.js 22.22.0 is an LTS security release addressing multiple vulnerabilities in TLS handling, permission-model behavior, symlink APIs, async_hooks, buffer creation, and callback exception handling. It also updates c-ares and undici dependencies. ### Source excerpt Node.js® is a free, open-source, cross-platform JavaScript runtime environment that lets developers create servers, web apps, command line tools and scripts. ## Compose Unstyled v1.49: Introducing Platform Themes DevFeed: [Compose Unstyled v1.49: Introducing Platform Themes]() Original publisher: [Read original article]() Author: Alex Styl Published: 2025-11-20T00:00:00Z Content type: release Language: en Sources: [Composables - Concise, no-fluff video tutorials for Android developers]() Topics: [Compose](), [Android](), [iOS](), [Web](), [Mobile]() Tags: [android](), [compose](), [ios](), [themes](), [tokens](), [typography](), [v1](), [web]() ### AI overview Compose Unstyled v1.49 introduces Platform Themes, which provide platform-specific interaction effects and typography defaults across Android, iOS, desktop, and Web. On Web, the feature also bundles Noto Sans and supports scripts including Japanese, Korean, Traditional Chinese, and Simplified Chinese. ### Source excerpt Native look and feel on every platform, not just Android. [Next page]()