# Kubernetes Published articles for Kubernetes. 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 Multi-Cluster Project Karmada Reaches CNCF Graduation DevFeed: [Kubernetes Multi-Cluster Project Karmada Reaches CNCF Graduation]() Original publisher: [Read original article]() Author: Claudio Masolo Published: 2026-09-17T10:00:00Z Content type: news Language: en Sources: [InfoQ]() Topics: [Kubernetes](), [Orchestration](), [Cloud](), [Computing]() Tags: [ai-architecture](), [cloud](), [cluster](), [clusters](), [cncf](), [devops](), [karmada-kubernetes-cncf](), [kubernetes](), [multi-cloud](), [news](), [orchestration](), [project](), [release]() ### AI overview The CNCF announced that Karmada, a multi-cluster and multi-cloud Kubernetes orchestration project, graduated to its highest maturity tier. The announcement coincided with Karmada v1.19, which improves multi-component scheduling for AI training jobs and makes priority-based scheduling available by default in Beta. ### Source excerpt The Cloud Native Computing Foundation (CNCF) announced on September 2026 that Karmada, a multi-cluster and multi-cloud Kubernetes orchestration project, has graduated. This multi-cluster and multi-cloud Kubernetes orchestration project reached CNCF's highest maturity tier. By Claudio Masolo ## Group Replication Beyond a Single Cluster: DC-DR with Percona (PS MySQL) Operator DevFeed: [Group Replication Beyond a Single Cluster: DC-DR with Percona (PS MySQL) Operator]() Original publisher: [Read original article]() Author: Anil Joshi Published: 2026-09-17T06:43:32Z Content type: tutorial Language: en Sources: [Blog - Percona]() Topics: [Replication](), [export](), [Percona Server for MySQL](), [configuration](), [Server](), [Kubernetes](), [Database]() Tags: [cloud](), [configuration](), [database-trends](), [featured](), [innodb-clusterset](), [insight-for-dbas](), [kubernetes](), [kubernetes-operators](), [mysql](), [mysql-group-replication](), [mysql-high-availability](), [mysql-replication](), [open-source](), [operator](), [percona-kubernetes-operators](), [percona-operator-for-mysql](), [percona-server-for-mysql](), [percona-software](), [replication](), [uncategorized](), [yaml]() ### AI overview This tutorial explains how to configure cross-site replication between two Percona Operator for MySQL clusters to create a ClusterSet environment for disaster recovery and switchover between data-center and disaster-recovery members. It covers deploying the clusters, retrieving endpoints and cluster names, transferring credentials, and initializing the DR cluster. ### Source excerpt A while ago, we discussed the cross-site replication feature of the Percona PXC operator. Recently, a similar cross-site replication feature was introduced in the Percona (PS MySQL) operator v1.2.0, a topology based on Group Replication/InnoDB Cluster. In this blog post, we will explore how to add a DR Cluster to an existing DC Cluster to ... Continued The post Group Replication Beyond a Single Cluster: DC-DR with Percona (PS MySQL) Operator appeared first on Percona. ## The First Sheet-Native Podcast Episode Examines Moving from Traditional Cloud Infrastructure to Spreadsheet-Based Architecture DevFeed: [The First Sheet-Native Podcast Episode Examines Moving from Traditional Cloud Infrastructure to Spreadsheet-Based Architecture]() Original publisher: [Read original article]() Author: TimurTukaev Published: 2026-09-17T06:35:46Z Content type: news Language: ru Sources: [Tagir Valeev]() Topics: [Computing]() Tags: [computing](), [devops](), [finops](), [google-sheets](), [kubernetes](), [podcast](), [sheet-native](), [sheeternetes](), [tag-0c38326564b9](), [tag-daf2bde78e5c]() ### AI overview Sheet-Native Computing Foundation has published the first episode of the Sheet-Native Podcast. The episode discusses the economic aspects of moving from traditional cloud infrastructure to Sheet-Native architecture, presenting the concept through satire. ### Source excerpt У каждого движения есть день, когда оно начинает становиться заметным в публичном поле. Для sheet-native computing этот день настал сегодня. Sheet-Native Computing Foundation опубликовал первый эпизод Sheet-Native Podcast -- разобрали экономические аспекты переезда с традиционных облаков на Sheet-Native архитектуру. Читать далее ## Kubernetes Architecture: Control Plane, Scheduler, and Kubelet DevFeed: [Kubernetes Architecture: Control Plane, Scheduler, and Kubelet]() Original publisher: [Read original article]() Author: Nimesha Jinarajadasa Published: 2026-09-17T06:25:02Z Content type: tutorial Language: en Sources: [Kubernetes - KodeKloud Blog | DevOps, Cloud, Kubernetes, AI Tutorials & More]() Topics: [Kubernetes](), [control-plane](), [api server](), [Containers](), [etcd](), [kubectl]() Tags: [api](), [api-server](), [containers](), [control-plane](), [controllers](), [etcd](), [kubectl](), [kubernetes](), [kubernetes-architecture](), [kubernetes-networking](), [node](), [scheduler]() ### AI overview A beginner-friendly tutorial explaining how Kubernetes maintains the desired state of containerized applications. It covers the control plane, API server, etcd, controllers, scheduler, and kubelet. ### Source excerpt Learn how Kubernetes works, from the control plane and scheduler to kubelet, pods, and Services, with simple answers to interview questions. ## Kubernetes v1.37: Hardening Container Storage with Bind Mount Options and EmptyDir Permissions DevFeed: [Kubernetes v1.37: Hardening Container Storage with Bind Mount Options and EmptyDir Permissions]() Original publisher: [Read original article]() Author: Nispriha Jagan; Neeraj Krishna Gopalakrishna Published: 2026-09-16T18:30:00Z Content type: article Language: en Sources: [Kubernetes Blog]() Topics: [Kubernetes](), [Security](), [mount](), [Filesystems](), [chmod](), [Unix]() Tags: [chmod](), [container](), [containers](), [filesystem](), [hardening](), [kubernetes](), [linux](), [mount](), [permissions](), [storage](), [volume](), [volumes]() ### AI overview Kubernetes v1.37 adds bind mount options and emptyDir permission modes to strengthen storage security. The article explains how noexec, nosuid, nodev, Unix permissions, and the sticky bit can help enforce security policies on writable volumes. ### Source excerpt Kubernetes v1.37 brings important storage security features: emptyDir permission modes and bind mount options. They help application programmers and security professionals implement rigorous security policies, for example, prohibiting deletion of files across containers or execution of arbitrary binaries from writable volumes, directly in Kubernetes without any complicated circumvention. Linux storage and permission fundamentals Before diving into the new Kubernetes features, let us briefly review the low-level Linux security mechanisms that make them possible. Bind mount flags When Linux mounts or remounts a directory, Virtual File System (VFS) flags control what actions are permitted on that filesystem: noexec: Do not permit direct execution of any binaries on the mounted filesystem. nosuid: Do not allow set-user-identifier or set-group-identifier bits to take effect. nodev: Do not interpret character or block special devices on the file system. Directory permissions and the sticky bit Standard Unix permissions regulate access across three scopes: Owner, Group, and Others (e.g., 0755 or 0777). Beyond standard read, write, and execute bits, Linux supports the sticky bit (as in mode 01777). When applied to a directory, the sticky bit ensures that a file inside that directory can only be deleted or renamed by the file's owner or root. This is essential for shared writable directories like /tmp. Motivation for the improvements Why does Kubernetes need bind mount options and emptyDir permissions? The primary goal of these features is to increase the security of Kubernetes workloads by allowing security-related bind mount options on volume mounts. By default, volumes are bind-mounted into containers by the container runtime and kubelet without noexec, nosuid, or nodev flags. This default can undermine security. For example, with noexec missing, a compromised process can use any writable volume (emptyDir, PersistentVolume, etc.) to download, chmod +x, and execute arbitra ## Publishing a Kubernetes SIG's Images to registry.k8s.io DevFeed: [Publishing a Kubernetes SIG's Images to registry.k8s.io]() Original publisher: [Read original article]() Author: The Kubernetes Authors Published: 2026-09-16T18:00:00Z Content type: tutorial Language: en Sources: [Kubernetes Contributors Blog]() Topics: [Kubernetes](), [container images](), [GitHub Actions](), [CI/CD](), [Google Cloud Platform (GCP)]() Tags: [ci-cd](), [container-image](), [container-image-registry](), [container-images](), [documentation](), [github-actions](), [google-cloud](), [guide](), [kubernetes]() ### AI overview A guide to publishing official Kubernetes SIG container images through registry.k8s.io. It explains why GHCR is unsuitable for public distribution and describes the ordered workflow involving Prow, Google Cloud Build, staging registries, and image promotion. ### Source excerpt If you're publishing container images for a Kubernetes SIG project, you might expect the same publishing workflow used by other container registries to work. That was my assumption too. My workflow successfully published the images, but they weren't publicly available. Instead, official Kubernetes project images are distributed through registry.k8s.io , the Kubernetes project's official container image registry. No single step was hard, but the steps were spread across multiple repositories and had to happen in a particular order, something I mostly learned by tripping over them. This post is the guide I wish I had at the start. It walks through that workflow end to end using Cluster Inventory API from SIG Multicluster as an example. The same process applies to eligible Kubernetes subprojects that publish official container images. My first attempt: GHCR I first tried a common GitHub release pattern: using GitHub Actions to publish images to ghcr.io on a tag push (cluster-inventory-api#40 ). The workflow succeeded, but Kubernetes GitHub organizations keep GHCR packages private, so GHCR cannot be used for public distribution. As described in the registry.k8s.io documentation , official images take a different route: Prow (the Kubernetes project's CI/CD system) picks up a tag push and runs Google Cloud Build on Kubernetes-owned infrastructure to push the image to a staging registry, and the image promoter then copies it to registry.k8s.io. The first-time setup, step by step Besides the image-owning repository, this touches three infrastructure repositories: kubernetes/k8s.io , kubernetes/test-infra , and kubernetes/org . The pieces depend on each other like this: Before you start: decide your project details Before setting up the publishing workflow, decide a few project-specific details. These values will be reused throughout the setup when creating the staging registry, configuring image builds, and setting up image promotion: , which determines the staging ## Microsoft Open-Sources TauGrid to Simplify AI Workload Management on Kubernetes DevFeed: [Microsoft Open-Sources TauGrid to Simplify AI Workload Management on Kubernetes]() Original publisher: [Read original article]() Author: Sergio De Simone Published: 2026-09-16T18:00:00Z Content type: news Language: en Sources: [InfoQ]() Topics: [Artificial Intelligence](), [Kubernetes](), [GPU](), [kueue](), [Go]() Tags: [agents](), [ai](), [artificial-intelligence](), [azure](), [development](), [devops](), [gpu](), [kubernetes](), [kueue](), [microsoft](), [microsoft-taugrid-open-source](), [news](), [open-source](), [orchestration]() ### AI overview Microsoft has open-sourced TauGrid, a cloud-native platform for managing, scheduling, and monitoring AI workloads on GPU-enabled Kubernetes clusters. It combines workload submission, Kueue-based queuing, KubeRay orchestration, GPU-node monitoring, and observability, while planned capabilities remain on its roadmap. ### Source excerpt Microsoft has open-sourced TauGrid, a cloud-native platform designed to manage, schedule, and monitor AI workloads on GPU-enabled Kubernetes clusters. By Sergio De Simone ## Constraining AI agents with Red Hat AI: Containment, identity, and governance DevFeed: [Constraining AI agents with Red Hat AI: Containment, identity, and governance]() Original publisher: [Read original article]() Author: Grace Ableidinger Published: 2026-09-16T13:01:59Z Content type: tutorial Language: en Sources: [Red Hat](), [Red Hat Developer]() Topics: [Artificial Intelligence](), [Security](), [Zero Trust](), [Containers](), [Kubernetes](), [Architecture & Design]() Tags: [ai](), [ai-agents](), [containers](), [deployment](), [kubernetes](), [prompt-injection](), [security](), [trust]() ### AI overview This tutorial explains how to secure AI agents running on Red Hat OpenShift using containment, verifiable identity, and governance. It covers namespace isolation, quotas, sandboxing, workload identity, and admission control, with OpenClaw used in the demo. ### Source excerpt When an agent process runs on your laptop, it typically inherits anything your user has access to. Often this includes the full network stack, the file system, and the credentials sitting in memory. When integrating with GitHub, Slack, or a cloud provider, you could be one faulty permission or well-crafted prompt injection away from a security incident. The post Constraining AI agents with Red Hat AI: Containment, identity, and governance appeared first on Red Hat Developer. ## Cloud Sovereignty, Provider Risk, and Migration Options for EU Companies DevFeed: [Cloud Sovereignty, Provider Risk, and Migration Options for EU Companies]() Original publisher: [Read original article]() Author: Adam Gordon Bell Published: 2026-09-16T13:00:00Z Content type: opinion Language: en Sources: [Pulumi]() Topics: [Cloud](), [migration](), [pulumi](), [Security](), [scaleway](), [Tooling]() Tags: [aws](), [azure](), [cloud](), [customers](), [kubernetes](), [migration](), [platform-engineering](), [pulumi](), [scaleway](), [security]() ### AI overview This recorded discussion examines cloud sovereignty, legal and cost concerns for EU companies using major US cloud providers, and the practical tradeoffs of moving to European providers. Three guests discuss provider exposure, encryption and account shutdown risks, migration costs, and whether Pulumi and agentic infrastructure can make future moves easier. ### Source excerpt Recorded September 3, 2026. Quotes are lightly edited for clarity. Maybe this sounds familiar. You run infrastructure at a company that isn't American. Your workloads are on AWS, Azure, or Google Cloud, probably more than one, because that is what everyone picked. Until recently nobody asked you where the data lives or who can reach it. Now you're getting questions. Legal wants to know what NIS2 means for where your systems run. Someone on the leadership team read that the US government locked the cloud accounts of judges at the International Criminal Court and wants to know if that could happen to you. Finance wants to know why the bill went up again. A customer's security review asked, in writing, which country your data sits in. So now you have questions of your own: If a US court or agency wants my data, can they get it from my provider without involving me? Does putting everything in an EU region change that? The big providers now sell "sovereign cloud" in Europe. Is that different, or a rename? If I encrypt everything and hold the keys myself, am I covered? Could my account be switched off one day? What would I do? Are Hetzner, OVH, and Scaleway usable for real workloads? How much cheaper are they once you count the migration? What should I be building on now so I can leave later if I need to? A migration like this used to be a multi-year project. Does Pulumi and agentic infrastructure change that? Is any of this worth the disruption, or should I leave what works alone? I put those questions to three people who have each dealt with this for real. One of them helps EU companies work out their exposure and builds the tooling to leave. Another has spent fifteen years sizing what cloud actually costs, and thinks most people should stay put. The third moved his company off AWS and onto a European provider. They don't agree on how big the risk is. The full hour is below. Don't just default to the hyperscalers Waldemar Kindler co-founded Think Ahead Technologies, whe ## Running OpenBao on Kubernetes with a CloudNativePG PostgreSQL backend DevFeed: [Running OpenBao on Kubernetes with a CloudNativePG PostgreSQL backend]() Original publisher: [Read original article]() Author: Gabriele Bartolini (EnterpriseDB) and CNCF Ambassador, Rob Kenefeck (ControlPlane) Published: 2026-09-16T11:30:00Z Content type: tutorial Language: en Sources: [Cloud Native Computing Foundation]() Topics: [CloudNativePG](), [Kubernetes](), [PostgreSQL](), [Open Source](), [vendor lock-in]() Tags: [blog](), [cloudnativepg](), [docker](), [hashicorp-vault](), [helm](), [infrastructure](), [kubernetes](), [linux-foundation](), [open-source](), [postgresql](), [secrets](), [vendor-lock-in]() ### AI overview A tutorial describes deploying OpenBao on Kubernetes with a three-instance CloudNativePG PostgreSQL cluster as its storage backend. It explains certificate-based authentication and a local Kind-based test environment. ### Source excerpt Managing infrastructure secrets on Kubernetes needs a backend that is self-healing and free of vendor lock-in, and that is exactly what OpenBao (the Linux Foundation's open-source fork of HashiCorp Vault) and CloudNativePG give you: an entirely... ## Lyft Moves Streaming Fleet to Apache Flink Kubernetes Operator DevFeed: [Lyft Moves Streaming Fleet to Apache Flink Kubernetes Operator]() Original publisher: [Read original article]() Author: Mark Silvester Published: 2026-09-16T11:00:00Z Content type: news Language: en Sources: [InfoQ]() Topics: [flink](), [apache-flink](), [Kubernetes](), [autoscaling](), [Deployment](), [legacy](), [Testing]() Tags: [apache-flink](), [architecture-design](), [autoscaling](), [deployment](), [development](), [devops](), [flink](), [kubernetes](), [kubernetes-operator](), [legacy](), [lyft-flink-k8s-operator](), [news](), [testing](), [upgrade]() ### AI overview Lyft moved hundreds of production Apache Flink jobs from its in-house Kubernetes operator to the Apache Flink Kubernetes Operator. The change enabled last-state upgrades, in-place autoscaling, and resource autotuning, while Lyft adapted legacy deployment specifications through its deploy API and contributed a fix for a configuration-renaming bug. ### Source excerpt Lyft has moved hundreds of production Flink jobs from a 2020 in-house Kubernetes operator to the Apache Flink Kubernetes Operator, unlocking last-state upgrades, in-place autoscaling and resource autotuning across the fleet. By Mark Silvester ## The Original Serverless Architecture is Still Here DevFeed: [The Original Serverless Architecture is Still Here]() Original publisher: [Read original article]() Author: Khan Academy Published: 2018-05-31T22:00:00Z Content type: opinion Language: en Sources: [Khan Academy]() Topics: [serverless architecture](), [Kubernetes](), [Orchestration](), [Docker](), [Cloud](), [Firebase](), [DynamoDB]() Tags: [amazon](), [cloud](), [containers](), [docker](), [dynamodb](), [engineering](), [firebase](), [infrastructure](), [kubernetes](), [news](), [orchestration](), [serverless](), [serverless-architecture]() ### AI overview This commentary compares Kubernetes-based architectures with serverless approaches. It explains that Kubernetes offers flexibility through containers, Helm, ingress controllers, monitoring tools, and service meshes, but requires substantial configuration and maintenance. Serverless platforms such as Firebase and Amazon Lambda abstract away server infrastructure so developers can focus on applications and stateless functions. ### Source excerpt By Kevin Dangoor This month, my colleague Dave Rosile and I went to GlueCon 2018 in sunny Denver, ... Read more ## Implementing GitOps from Infrastructure to DB Operators to Unify Ops for Kubernetes Databases DevFeed: [Implementing GitOps from Infrastructure to DB Operators to Unify Ops for Kubernetes Databases]() Original publisher: [Read original article]() Author: Sucahyo Ardy Prasetiyo Published: 2026-09-16T08:57:10Z Content type: tutorial Language: en Sources: [SeveralNines]() Topics: [GitOps](), [Kubernetes](), [Terraform](), [argo-cd](), [ClusterControl](), [Databases](), [opentofu]() Tags: [argo-cd](), [clustercontrol](), [databases](), [gitops](), [hybrid-operations](), [infrastructure](), [kubernetes](), [opentofu](), [sovereign-dbaas](), [terraform]() ### AI overview This article describes a layered GitOps approach for Kubernetes database platforms: manage infrastructure with Terraform or OpenTofu, manage Kubernetes deployments with Argo CD, and standardize operations for operator-managed databases with ClusterControl. It explains how declarative configuration and drift reconciliation differ between Terraform and Argo CD, and compares infrastructure automation options including Atlantis and Flux tf-controller. ### Source excerpt Most platform teams already use GitOps for their Kubernetes apps. The config lives in Git, Argo CD applies it, and deployments are predictable. But look one layer down and things get messy. Infrastructure setup is often still done by hand, running Terraform locally or through scattered scripts. Database operations, especially for databases running through Kubernetes [...] The post Implementing GitOps from Infrastructure to DB Operators to Unify Ops for Kubernetes Databases appeared first on Severalnines. ## Kubernetes attributes processor reaches v1.0.0 milestone DevFeed: [Kubernetes attributes processor reaches v1.0.0 milestone]() Original publisher: [Read original article]() Author: OpenTelemetry Authors; Docs CC BY Published: 2026-09-16T04:59:27Z Content type: release Language: en Sources: [Blog on OpenTelemetry]() Topics: [OpenTelemetry](), [telemetry](), [releases](), [Kubernetes](), [Go Language]() Tags: [api](), [go](), [kubernetes](), [opentelemetry](), [releases](), [stable](), [telemetry]() ### AI overview The Kubernetes attributes processor has reached version 1.0.0 and fulfills OpenTelemetry's stability criteria for testing, benchmarking, documentation, and telemetry. The release also supports redistribution as a Go library or in binaries without API breakage. ### Source excerpt The Kubernetes attributes processor, which enriches your telemetry with Kubernetes metadata, has officially moved to v1.0.0! You can try it out on your custom distro, and it is also available as part of the latest opentelemetry-collector-contrib and opentelemetry-collector-k8s distro releases. Being v1.0.0 means the component is now verified to fulfill the 'stable' stability criteria including requirements around testing, benchmarking, documentation and telemetry stability. It also ensures you can redistribute it as a Go library or as part of your binaries without API breakage. ## Kubernetes Cost Management Tools: The Best Options 2026 DevFeed: [Kubernetes Cost Management Tools: The Best Options 2026]() Original publisher: [Read original article]() Author: Kelsey Rosen Published: 2026-09-16T00:00:00Z Content type: comparison Language: en Sources: [Harness Blog]() Topics: [Kubernetes](), [finops](), [Monitoring](), [Cloud]() Tags: [2026](), [cloud](), [compare](), [finops](), [kubernetes](), [monitoring]() ### AI overview A comparison of Kubernetes cost management tools for 2026, including Kubecost, OpenCost, and CloudZero. It explains how these tools allocate shared cloud node costs across namespaces, workloads, and pods, while accounting for idle and unallocated capacity and supporting optimization actions. ### Source excerpt Compare the best Kubernetes cost management tools for 2026, from Kubecost and OpenCost to CloudZero, on allocation depth, scale, and pricing model. | Blog ## Automate Docker Registry Creation with Harness and Terraform DevFeed: [Automate Docker Registry Creation with Harness and Terraform]() Original publisher: [Read original article]() Author: Shibam Dhar Published: 2026-09-16T00:00:00Z Content type: tutorial Language: en Sources: [Harness Blog]() Topics: [docker registry](), [Kubernetes](), [Provisioning](), [Terraform](), [Infrastructure as code](), [CI/CD](), [Dockerfile]() Tags: [ci-cd](), [container-image](), [deployment](), [docker-registry](), [infrastructure-as-code](), [kubernetes](), [registry](), [terraform]() ### AI overview A tutorial shows how to use Harness Pipelines and the Harness Terraform Provider to provision a uniquely named Docker Registry, build and push a container image, and deploy it to Kubernetes. It covers Terraform execution in a CI step, passing output variables between stages, and rolling updates with automatic rollback. ### Source excerpt Provision a fresh Docker Registry with Terraform, build your container image into it, and deploy to Kubernetes in one | Blog ## 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 ## What I learned organizing KCD Lima 2026 DevFeed: [What I learned organizing KCD Lima 2026]() Original publisher: [Read original article]() Author: Ronald Requena | CNCF Ambassador Published: 2026-09-15T16:24:05Z Content type: opinion Language: en Sources: [Cloud Native Computing Foundation]() Topics: [Kubernetes](), [data]() Tags: [2026](), [blog](), [community](), [event](), [kubernetes](), [report](), [survey]() ### AI overview Ronald Requena reflects on organizing the third Kubernetes Community Days Lima, held on July 18, 2026. He describes the event's growth, operational challenges, program, sponsorship, and attendee feedback, including 2,244 registrations, more than 900 attendees, 54 sessions, and a 4.7 out of 5 satisfaction rating. ### Source excerpt On July 18, 2026, we held the third edition of Kubernetes Community Days Lima at UTEC in Barranco. By now, we have already sent the Transparency Report to the CNCF, thanked our sponsors, and processed the... ## Scaling Federated Learning Across Docker, Kubernetes, and Slurm with NVIDIA FLARE DevFeed: [Scaling Federated Learning Across Docker, Kubernetes, and Slurm with NVIDIA FLARE]() Original publisher: [Read original article]() Author: Elizabeth Goodman Published: 2026-09-15T15:00:00Z Content type: article Language: en Sources: [NVIDIA Developer](), [NVIDIA Technical Blog]() Topics: [Federated Learning](), [Docker](), [Kubernetes](), [Nvidia](), [Server](), [dataset](), [Deployment]() Tags: [architecture](), [compute](), [configuration](), [container](), [data-analytics-processing](), [data-science](), [dataset](), [deployment](), [docker](), [docker-container](), [federated-learning](), [gpu](), [job](), [kubernetes](), [nvidia](), [nvidia-flare](), [server]() ### AI overview This article explains how NVIDIA FLARE scales federated learning across sites with different infrastructure, including Docker, Kubernetes, and Slurm. Its two-layer architecture separates persistent federation services from on-demand job execution, while allowing each site to retain local control over compute, data, secrets, and scheduling. ### Source excerpt Federated learning (FL) projects often begin with a straightforward setup: one server, a few clients, and one dataset at each site. As those projects grow, the... ## Kubernetes 1.36 restores a lost guarantee for database backups DevFeed: [Kubernetes 1.36 restores a lost guarantee for database backups]() Original publisher: [Read original article]() Author: Shubham Pampattiwar Published: 2026-09-15T13:00:00Z Content type: news Language: en Sources: [Kubernetes Overview, News and Trends | The New Stack](), [The New Stack]() Topics: [Kubernetes](), [PostgreSQL](), [Databases]() Tags: [backups](), [cncf](), [consistency](), [database](), [databases](), [kubernetes](), [post-contributed](), [postgresql](), [snapshots](), [sponsor-cncf](), [sponsored-post-contributed](), [stateful](), [storage]() ### AI overview The article explains how Kubernetes 1.36 restores coordinated snapshots for applications whose state spans multiple volumes, addressing inconsistent database backups caused by taking individual PersistentVolumeClaim snapshots at different times. ### Source excerpt It's 2 a.m., and you're restoring a PostgreSQL cluster from last night's backup. Its data directory lives on one PersistentVolumeClaim The post Kubernetes 1.36 restores a lost guarantee for database backups appeared first on The New Stack. ## Who am I ? DevFeed: [Who am I ?]() Original publisher: [Read original article]() Author: brice.dutheil@gmail.com (Brice Dutheil) Published: 2026-09-15T04:32:32.192351Z Content type: article Language: fr Sources: [The Coffee Workshop]() Topics: [Java](), [Kubernetes](), [Open Source](), [backends]() Tags: [java](), [jvm](), [kubernetes](), [open-source]() ### AI overview The author describes himself as primarily a Java and JVM developer, with experience using Kubernetes and contributing to open-source projects. He previously worked on Mockito, has spent ten years working on backends across various sectors, and currently works for BlaBlaCar. ### Source excerpt English 🇬🇧/🇺🇸 I'm mostly a Java / JVM guy. Now I'm also a Kubernetes user in surface, so I now a few system tricks. ## Monitor TAS and gang scheduling for AI training in Kubernetes DevFeed: [Monitor TAS and gang scheduling for AI training in Kubernetes]() Original publisher: [Read original article]() Author: David Lentz; Kathy Lin Published: 2026-09-15T00:00:00Z Content type: article Language: en Sources: [Datadog | The Monitor blog]() Topics: [Kubernetes](), [kueue](), [distributed-training](), [GPU](), [Monitoring](), [datadog]() Tags: [ai](), [batch](), [containers](), [datadog](), [distributed-training](), [gpu](), [gpu-monitoring](), [kubernetes](), [kueue](), [monitoring](), [scheduler]() ### AI overview This article explains why Kubernetes scheduling is insufficient for distributed AI training workloads and how topology-aware scheduling and gang scheduling address hardware placement and simultaneous startup requirements. It discusses implementing these capabilities with Kueue and the Coscheduling plugin, and monitoring and troubleshooting them with Datadog GPU Monitoring. ### Source excerpt Learn how Datadog helps you correlate Kueue, Coscheduling, GPU, and training framework signals to validate gang scheduling and topology-aware scheduling. ## Intelligence is yours. Let's keep it that way. DevFeed: [Intelligence is yours. Let's keep it that way.]() Original publisher: [Read original article]() Author: Paddy Srinivasan Published: 2026-09-14T21:11:13Z Content type: opinion Language: en Sources: [DigitalOcean]() Topics: [Open Source](), [Software](), [PostgreSQL](), [React](), [GitHub]() Tags: [agents](), [competition](), [github](), [infrastructure](), [intellectual-property](), [kubernetes](), [models](), [mysql](), [news](), [open-source](), [opencode](), [postgresql](), [react]() ### AI overview The article argues that founders should retain ownership and control of their companies' intelligence rather than depend on a single intelligence provider. It advocates an Open Intelligence movement built from open-source models, agents, harnesses, data technologies, and infrastructure, drawing comparisons with the adoption of Linux, PostgreSQL, MySQL, Kubernetes, and other open technologies. ### Source excerpt Intelligence was yours. A founder's intellectual property, business logic, differentiation, their intelligence, was once theirs alone. You built it, you owned it, and no tools/platform vendor stood between you and your customers. This is no longer clear. It is starting to look like it is "theirs." Intelligence can now be manufactured: the models, the agents and the harnesses that drive them, and the compute they run on. Providers who own all these can produce the application, and the differentiation, in every industry. That power runs the risk of becoming increasingly concentrated in a handful of companies. The race for the application layer is not about interfaces or go-to-market; it is a fight over who owns the intelligence layer itself. We have seen this before but we must act before its too late. Linux started behind Unix and Windows and now runs most of the world's servers. PostgreSQL and MySQL started behind Oracle and now underpin most new software. Kubernetes arrived after proprietary orchestrators and made them irrelevant. Each began less capable and won anyway: builders could see inside it, run it anywhere, and never had to ask permission. The same is happening now. Open weight models have repeatedly reached the frontier this past year. Open harnesses like OpenCode have grown to tens of trillions of tokens a day. Hermes reached more than 200,000 GitHub stars in five months, a milestone that took React a decade to achieve. Along with the near total adoption of open source data technologies, this collection of open technologies power an Open Intelligence movement. Open Intelligence restores the order. It returns to founders ownership of what makes their companies theirs. Founders should be free to build without tying their future to a single intelligence provider: their choice of agents, harnesses, data technologies, models, and infrastructure, with open source transparency, control, and competition keeping every layer honest. The stakes go beyond business. ## 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 [Next page]()