# Kubernetes Contributors Blog

The Kubernetes contributor blog is used by the project to communicate community reports, contributor news, and any updates that might be relevant to people contributing to 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.

## Publishing a Kubernetes SIG's Images to registry.k8s.io

DevFeed: [Publishing a Kubernetes SIG's Images to registry.k8s.io](<https://devfeed.tech/articles/publishing-a-kubernetes-sig-s-images-to-registry-k8s-io-31455.md>)

Original publisher: [Read original article](<https://www.kubernetes.dev/blog/2026/09/16/publishing-images-to-registry-k8s-io/>)

Author: The Kubernetes Authors

Published: 2026-09-16T18:00:00Z

Content type: tutorial

Language: en

Sources: [Kubernetes Contributors Blog](<https://devfeed.tech/sources/kubernetes-contributors-blog.md>)

Topics: [Kubernetes](<https://devfeed.tech/topics/kubernetes.md>), [container images](<https://devfeed.tech/topics/container-images.md>), [GitHub Actions](<https://devfeed.tech/topics/github-actions.md>), [CI/CD](<https://devfeed.tech/topics/cicd.md>), [Google Cloud Platform (GCP)](<https://devfeed.tech/topics/google-cloud.md>)

Tags: [ci-cd](<https://devfeed.tech/tags/ci-cd.md>), [container-image](<https://devfeed.tech/tags/container-image.md>), [container-image-registry](<https://devfeed.tech/tags/container-image-registry.md>), [container-images](<https://devfeed.tech/tags/container-images.md>), [documentation](<https://devfeed.tech/tags/documentation.md>), [github-actions](<https://devfeed.tech/tags/github-actions.md>), [google-cloud](<https://devfeed.tech/tags/google-cloud.md>), [guide](<https://devfeed.tech/tags/guide.md>), [kubernetes](<https://devfeed.tech/tags/kubernetes.md>)

### 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: <project>, which determines the staging

## Kubernetes v1.37: Declarative Validation Drives Record-Breaking API Reviews

DevFeed: [Kubernetes v1.37: Declarative Validation Drives Record-Breaking API Reviews](<https://devfeed.tech/articles/kubernetes-v1-37-declarative-validation-drives-record-breaking-api-reviews-17604.md>)

Original publisher: [Read original article](<https://www.kubernetes.dev/blog/2026/08/27/kubernetes-v1-37-declarative-validation/>)

Author: The Kubernetes Authors

Published: 2026-08-27T00:00:00Z

Content type: release

Language: en

Sources: [Kubernetes Contributors Blog](<https://devfeed.tech/sources/kubernetes-contributors-blog.md>)

Topics: [Kubernetes](<https://devfeed.tech/topics/kubernetes.md>), [Tooling](<https://devfeed.tech/topics/tooling.md>), [Code](<https://devfeed.tech/topics/code.md>), [releases](<https://devfeed.tech/topics/releases.md>)

Tags: [api](<https://devfeed.tech/tags/api.md>), [declarative](<https://devfeed.tech/tags/declarative.md>), [kubernetes](<https://devfeed.tech/tags/kubernetes.md>), [release](<https://devfeed.tech/tags/release.md>), [tooling](<https://devfeed.tech/tags/tooling.md>), [validation](<https://devfeed.tech/tags/validation.md>)

### AI overview

This article reports that Kubernetes v1.37 processed a project-record 118 API review pull requests, up from 88 in v1.36, while reviewers maintained pace. It identifies expanded declarative validation, which reached general availability in v1.36, as a primary efficiency driver; roughly 75% of new validations used declarative validation.

### Source excerpt

Kubernetes v1.37 saw the most API reviews in the project's history. API reviewers reviewed an all-time high of 118 PRs , up from 88 in the v1.36 release. Despite this massive surge, the API reviewers were able to keep pace. A primary driver of this efficiency was the significant expansion of declarative validation (DV), which reached General Availability (GA) in v1.36 and experienced its largest growth to date in v1.37. Declarative validation (DV) allows Kubernetes developers to declare validation rules using Interface Definition Language (IDL) tags (like +k8s:optional or +k8s:minimum=0) directly in the types.go files that define the native API types. These tags are then used by the code generator, validation-gen, to automatically generate the required validation functions, replacing the need for complex, handwritten imperative validation logic. Roughly 75% of new validations were written in DV, significantly saving reviewers' time. Because the tooling handles the complexity, reviewers provided minimal guidance on the validation logic compared to previous releases. Additionally, linters and other correctness checks were a major factor in maintaining this velocity. Pre-reviews conducted by Joel Speed (@joelspeed ), Patrick Ohly (@pohly ), Maciej Szulik (@soltysh ), Tim Allclair (@tallclair ), Joe Betz (@jpbetz ), and Mo Khan (@enj ) saved a lot of time for our core API reviewers like Jordan (@liggitt ) and Tim (@thockin ). (A special congratulations to Joe, who was promoted to API approver this release!) "The guardrail work that made use of declarative validation tags automatically require covering test cases made a big difference in 1.37. Validation expressed as declarative tags shrank the complexity of implementations and reviews, and is feeding a virtuous cycle where reviewers and authors prefer declarative validation once they get used to it. There were a few PRs this cycle that had almost no validation.go changes at all (🎉), and a lot where all the straightforwa

## KCD Around the World: San Francisco Bay Area

DevFeed: [KCD Around the World: San Francisco Bay Area](<https://devfeed.tech/articles/kcd-around-the-world-san-francisco-bay-area-17603.md>)

Original publisher: [Read original article](<https://www.kubernetes.dev/blog/2026/08/19/kcd-around-the-world-san-francisco/>)

Author: The Kubernetes Authors

Published: 2026-08-19T00:00:00Z

Content type: article

Language: en

Sources: [Kubernetes Contributors Blog](<https://devfeed.tech/sources/kubernetes-contributors-blog.md>)

Topics: [Kubernetes](<https://devfeed.tech/topics/kubernetes.md>), [Cloud Native Ecosystem](<https://devfeed.tech/topics/cloud-native-ecosystem.md>), [Google](<https://devfeed.tech/topics/google.md>)

Tags: [2026](<https://devfeed.tech/tags/2026.md>), [cloud-native](<https://devfeed.tech/tags/cloud-native.md>), [cncf](<https://devfeed.tech/tags/cncf.md>), [community](<https://devfeed.tech/tags/community.md>), [contributors](<https://devfeed.tech/tags/contributors.md>), [developer-relations](<https://devfeed.tech/tags/developer-relations.md>), [google-cloud](<https://devfeed.tech/tags/google-cloud.md>), [kubernetes](<https://devfeed.tech/tags/kubernetes.md>), [open-source](<https://devfeed.tech/tags/open-source.md>)

### AI overview

An interview with organizers of the second KCD San Francisco Bay Area, scheduled for September 1, 2026, explores the event's origins, the local Kubernetes community, and the organizers' backgrounds in Kubernetes and cloud-native technology.

### Source excerpt

Welcome back to KCD Around the World, a series where we explore Kubernetes Community Days from every corner of the globe. Behind every event is a community of volunteers, contributors, organizers and attendees who make it all happen. Through conversations with the people behind each KCD, we share what makes it unique. This stop: San Francisco Bay Area. Coming up on September 1, 2026 is the second KCD San Francisco Bay Area, held at the Computer History Museum in Mountain View. We spoke with three of its organizers, Rey Lejano, Lisa-Marie Namphy, and Jason (Jay) Smith, about what makes the Bay Area community tick. Meet the community Kashish Verma (KV): Could you each introduce yourselves and tell us how you got involved in Kubernetes? Rey Lejano (RL): I'm one of the KCD San Francisco Bay Area organizers, a Kubernetes SIG Docs co-chair and SIG Security subproject lead, and I work at Red Hat. I've served on seven Release Teams, including as the v1.23 Release Lead. A conversation with a Kubernetes contributor at the 2019 KubeCon in San Diego is what pulled me into contributing to the project. Lisa-Marie Namphy (LN): Hi! I'm Lisa-Marie Namphy (Lisa), I've been a CNCF Ambassador since the early days of the program and have run one of the largest Kubernetes/Cloud Native user groups for over 10 years, now called Cloud Native Silicon Valley. I also run the Developer Relations and Tech Learning team at Intuit, where open source is core to how we build: our flagship products like TurboTax and QuickBooks run on Kubernetes and other CNCF technologies, including Argo, which Intuit originally created and donated. Jason "Jay" Smith (JS): I'm a Staff Customer Engineer on the Application Ecosystem team at Google Cloud, though I like to call myself the "Cloud Alchemist," since I help customers move from legacy monolithic architectures to microservices. On the community side, I'm a co-lead for the Cloud Native San Francisco Community, an organizer for the 2025 and 2026 KCD San Francisc

## KCD Around the World: New York

DevFeed: [KCD Around the World: New York](<https://devfeed.tech/articles/kcd-around-the-world-new-york-17602.md>)

Original publisher: [Read original article](<https://www.kubernetes.dev/blog/2026/07/28/kcd-around-the-world-new-york/>)

Author: The Kubernetes Authors

Published: 2026-07-28T18:00:00Z

Content type: article

Language: en

Sources: [Kubernetes Contributors Blog](<https://devfeed.tech/sources/kubernetes-contributors-blog.md>)

Topics: [Kubernetes](<https://devfeed.tech/topics/kubernetes.md>), [Cloud](<https://devfeed.tech/topics/cloud.md>)

Tags: [community](<https://devfeed.tech/tags/community.md>), [interview](<https://devfeed.tech/tags/interview.md>), [kubernetes](<https://devfeed.tech/tags/kubernetes.md>)

### AI overview

An interview with Christopher Tineo, an organizer of KCD NY 2026, about his path from volunteering to organizing and the New York Kubernetes community.

### Source excerpt

Welcome to KCD Around the World, a new series where we explore Kubernetes Community Days from every corner of the globe. When most people think of KCD, they think about talks and technical sessions, but behind every event is a community of volunteers, contributors, organizers and attendees who make it all happen. Through conversations with the people behind each KCD, we'll share what makes it unique. Our first stop: New York City. To learn what made this year's event special, we interview Christopher Tineo, one of the organizers for KCD NY 2026. Meet the community Kashish Verma (KV): Hello Christopher, and welcome. Could you start by introducing yourself and telling us how you got involved with Kubernetes and the cloud native community? Christopher Tineo (CT): I'm Christopher Tineo. This year I organized KCD NY 2026, where my main focus was building out the event agenda and our event website . Going back a bit, I first got involved through a meetup organized in Santo Domingo by Victor Recio around February 2024, right after I got my CKAD certification . I had the chance to connect with a few engineers who eventually became organizers for our CNCF chapter , Ayesha Yege and Enmanuel Medina. As I dived deeper into the CNCF community, I knew I wanted to be a part of it. After watching Julia Morgado's inspiring talk at KubeCon 2023 , I was driven to take action. Despite living in the Dominican Republic, I booked a flight to KCD NY 2024 and applied to volunteer. Luckily, I got a spot on the team, and it turned out to be an incredible firsthand experience with the community. KV: What motivated you to volunteer or organize KCD New York? CT: NYC has been the start of all the great things that came after that first KCD NY in 2024, so I wanted to be that person that could motivate more engineers from my country to improve their careers and learn more from the Cloud Native community, which wasn't as developed back then. Attending as a volunteer in 2024 is what motivated me to c

## Human-Centered Automation for Kubernetes Localization in the AI Era

DevFeed: [Human-Centered Automation for Kubernetes Localization in the AI Era](<https://devfeed.tech/articles/human-centered-automation-for-kubernetes-localization-in-the-ai-era-17600.md>)

Original publisher: [Read original article](<https://www.kubernetes.dev/blog/2026/06/26/human-centered-automation-kubernetes-localization-ai-era/>)

Author: The Kubernetes Authors

Published: 2026-06-26T22:00:00Z

Content type: article

Language: en

Sources: [Kubernetes Contributors Blog](<https://devfeed.tech/sources/kubernetes-contributors-blog.md>)

Topics: [Localization (l10n)](<https://devfeed.tech/topics/localization.md>), [Kubernetes](<https://devfeed.tech/topics/kubernetes.md>), [Documentation](<https://devfeed.tech/topics/documentation.md>), [Maintainers](<https://devfeed.tech/topics/maintainers.md>)

Tags: [automation](<https://devfeed.tech/tags/automation.md>), [documentation](<https://devfeed.tech/tags/documentation.md>), [kubernetes](<https://devfeed.tech/tags/kubernetes.md>), [maintainers](<https://devfeed.tech/tags/maintainers.md>), [translation](<https://devfeed.tech/tags/translation.md>)

### AI overview

This article describes a Kubernetes localization mentorship project focused on human-centered automation. Its goal is to help maintainers prioritize review work by improving visibility and reducing repetitive triage, rather than automating translation. The approach addresses ongoing maintenance of localized documentation as English source content changes.

### Source excerpt

This year, the Kubernetes localization subproject participated in LFX Mentorship for the first time through the project "CNCF - Kubernetes: SIG Docs Localization: AI-era localization automation" . The work was also tracked in kubernetes/website#54075 . As the mentee on this project, I worked with Kubernetes SIG Docs localization mentors on a practical maintenance question: In an era of rapidly improving AI translation tools, what kind of automation actually helps localization maintainers? Kubernetes documentation is used by readers around the world. Localization helps make the project more accessible to users and contributors by providing content in their native languages. But localization is not only about translating pages once. It is also about maintaining those pages as Kubernetes changes. For this mentorship project, the focus was human-centered automation: tools that improve visibility, reduce repetitive triage, and protect human reviewer attention. The goal was not to automate translation. The goal was to make localization review work easier to prioritize. The maintenance problem behind localization Kubernetes documentation changes continuously. Concepts are clarified, examples are updated, feature states move forward, commands are corrected, and API-related wording changes. When English documentation changes, localized pages may also need updates. For active localization teams, this creates ongoing maintenance work. Reviewers need to understand both the source content and the target language, and they need enough Kubernetes context to decide whether a change affects technical accuracy. Existing signals can help detect possible drift. Some localization teams compare Git history to see whether the English source changed after a localized page was last updated, and Kubernetes website pages may also show lastmod warnings when localized content appears older than the English source. These signals are useful, but they do not always explain what kind of review is n

## Open source maintainership in the age of AI

DevFeed: [Open source maintainership in the age of AI](<https://devfeed.tech/articles/open-source-maintainership-in-the-age-of-ai-17601.md>)

Original publisher: [Read original article](<https://www.kubernetes.dev/blog/2026/06/26/open-source-maintainership-in-the-age-of-ai/>)

Author: CLA enforcement

Published: 2026-06-26T18:00:00Z

Content type: article

Language: en

Sources: [Kubernetes Contributors Blog](<https://devfeed.tech/sources/kubernetes-contributors-blog.md>)

Topics: [AI-assisted coding](<https://devfeed.tech/topics/ai-assisted-coding.md>), [Kubernetes](<https://devfeed.tech/topics/kubernetes.md>), [Open Source](<https://devfeed.tech/topics/open-source.md>), [Pull Request](<https://devfeed.tech/topics/pull-request.md>), [Code quality](<https://devfeed.tech/topics/code-quality.md>)

Tags: [ai](<https://devfeed.tech/tags/ai.md>), [ai-assisted-coding](<https://devfeed.tech/tags/ai-assisted-coding.md>), [kubernetes](<https://devfeed.tech/tags/kubernetes.md>), [open-source](<https://devfeed.tech/tags/open-source.md>), [policy](<https://devfeed.tech/tags/policy.md>), [pull-request](<https://devfeed.tech/tags/pull-request.md>), [quality](<https://devfeed.tech/tags/quality.md>)

### AI overview

This article explains how the Kubernetes community is adapting its maintainership practices to AI-assisted coding. It describes an AI policy requiring contributors to disclose AI assistance, remain responsible for changes, avoid attributing commits to AI, satisfy contributor license agreement checks, and personally respond to review comments.

### Source excerpt

AI has really changed the game around software development. More people are leveraging AI than ever to contribute patches to projects they use. To me, this is a good thing as more folks will contribute patches rather than fork or not fix them. The main problem is that AI has made generating code fast but there has been very little improvement in maintaining code bases. In this post, we will highlight the ways the Kubernetes community is adapting to the world of AI assisted coding. The first step of this journey was to develop an AI policy. This seems mundane and bureaucratic but there were many PRs that derailed into discussions around AI usage. The AI policy helps steer the conversation around the project's stance on AI and provides a clear signal to contributors on how to use these tools responsibly. Kubernetes AI policy The Kubernetes project has established clear guidelines for AI-assisted contributions that balance innovation with accountability. These policies are designed to maintain code quality and ensure human oversight while acknowledging that AI tools can be valuable aids in the development process. Transparency first Contributors must disclose when AI tools have been used to assist with a pull request. A simple statement in the PR description such as "This PR was written in part with the assistance of generative AI" is sufficient. This transparency helps reviewers understand the context and apply appropriate scrutiny. Human accountability While AI tools can assist, the human contributor remains fully responsible for every change. The policy explicitly prohibits: Listing AI as a co-author on commits Using AI co-signing on commits Adding trailers like "assisted-by" or "co-developed" that attribute work to AI This isn't about diminishing AI's role as a tool--it's about maintaining clear accountability. If something breaks, there needs to be a human who understands why and can fix it. CLA enforcement for co-authors The CNCF provides a tool for verifying the

## Spotlight on WG Device Management

DevFeed: [Spotlight on WG Device Management](<https://devfeed.tech/articles/spotlight-on-wg-device-management-17599.md>)

Original publisher: [Read original article](<https://www.kubernetes.dev/blog/2026/06/24/wg-device-management-spotlight-2026/>)

Author: The Kubernetes Authors

Published: 2026-06-24T18:00:00Z

Content type: article

Language: en

Sources: [Kubernetes Contributors Blog](<https://devfeed.tech/sources/kubernetes-contributors-blog.md>)

Topics: [Kubernetes](<https://devfeed.tech/topics/kubernetes.md>), [Hardware](<https://devfeed.tech/topics/hardware.md>), [Artificial Intelligence](<https://devfeed.tech/topics/ai.md>)

Tags: [ai](<https://devfeed.tech/tags/ai.md>), [hardware](<https://devfeed.tech/tags/hardware.md>), [kubernetes](<https://devfeed.tech/tags/kubernetes.md>), [spotlight](<https://devfeed.tech/tags/spotlight.md>)

### AI overview

This Kubernetes spotlight examines the Device Management Working Group and its work on Dynamic Resource Allocation (DRA), which recently graduated to general availability. The article discusses hardware management requirements for GPUs, TPUs, network interfaces, and other specialized resources, along with limitations of the legacy device model and scheduling challenges.

### Source excerpt

The rising popularity of AI, Edge, and Telecommunications workloads on Kubernetes has led to new requirements for hardware management. We now need hardware specification beyond CPU time and memory allocations. This includes allocating GPUs, TPUs, network interfaces, and other hardware, sometimes after pod start and occasionally through time-sharing. Efficiently managing this specialized hardware is the mission of the Device Management Working Group . Their cornerstone project, Dynamic Resource Allocation (DRA) , recently graduated to GA, marking a fundamental shift in how the project handles hardware-intensive workloads at scale. In this spotlight, we sit down with working group chairs Kevin Klues , Patrick Ohly , and John Belamaric to discuss the limitations of the legacy device model, the NP-hard challenges of scheduling, and how they're building a more programmable, hardware-aware future for Kubernetes. Introducing Device Management Natalie Fisher: Can you introduce yourself, your role, and how you got involved in the Device Management Working Group? Kevin Klues: My name is Kevin Klues. I am a Distinguished Engineer at NVIDIA. I have been a co-chair of the device management working group since its inception at Kubecon EU 2024. I have also been involved with DRA (the working group's primary deliverable) since its inception in 2019 / 2020. I have also been a kubelet maintainer since 2019, with a focus on its device manager, CPU manager, and topology manager subcomponents. The challenges we saw with using these components for workloads that relied on external accelerators (e.g., GPUs) are what triggered us to start working on DRA in the first place. Patrick Ohly: I am a Principal Engineer at Intel. In Kubernetes, I am a Tech Lead for SIG Testing and SIG Instrumentation and co-chair of the Device Management WG. I was co-chair of the WG Structured Logging and a member of the Steering Committee. Some of my early contributions to Kubernetes include ephemeral CSI volumes

## Spotlight on SIG Storage

DevFeed: [Spotlight on SIG Storage](<https://devfeed.tech/articles/spotlight-on-sig-storage-17598.md>)

Original publisher: [Read original article](<https://www.kubernetes.dev/blog/2026/06/15/sig-storage-spotlight-2026/>)

Author: The Kubernetes Authors

Published: 2026-06-15T00:00:00Z

Content type: article

Language: en

Sources: [Kubernetes Contributors Blog](<https://devfeed.tech/sources/kubernetes-contributors-blog.md>)

Topics: [Kubernetes](<https://devfeed.tech/topics/kubernetes.md>), [systems](<https://devfeed.tech/topics/systems.md>), [data](<https://devfeed.tech/topics/data.md>)

Tags: [backups](<https://devfeed.tech/tags/backups.md>), [containers](<https://devfeed.tech/tags/containers.md>), [distributed-system](<https://devfeed.tech/tags/distributed-system.md>), [kubernetes](<https://devfeed.tech/tags/kubernetes.md>), [storage](<https://devfeed.tech/tags/storage.md>), [volumes](<https://devfeed.tech/tags/volumes.md>)

### AI overview

An interview with Xing Yang, co-chair of Kubernetes SIG Storage, covering the group's role in persistent data and volume management, Kubernetes CSI maintenance, recent storage features, and data protection work such as Volume Group Snapshot and Changed Block Tracking.

### Source excerpt

In our ongoing SIG Spotlight series, we shine a light on the groups that keep the Kubernetes project moving forward. This time, we catch up with SIG Storage , the group responsible for persistent data, volume management, and the interfaces that connect Kubernetes workloads to the storage systems beneath them. We spoke with Xing Yang , Co-Chair of SIG Storage and Software Engineer at VMware by Broadcom, about the SIG's history, the features shipping in recent Kubernetes releases, and where storage in Kubernetes is headed as AI workloads become the norm. Introductions Could you introduce yourself and share your role(s) within SIG Storage? My name is Xing Yang , a software engineer at VMware by Broadcom. I'm a co-chair in SIG Storage, alongside another co-chair Saad Ali from Google. There are also two Tech Leads in SIG Storage: Michelle Au from Google and Jan Šafránek from Red Hat. What first drew you to storage in Kubernetes, and how did you start contributing? I have always been working in the storage domain, so SIG Storage was a natural place for me to get started when I began to learn Kubernetes. I started attending SIG Storage meetings , trying to figure out what I could do to help. This was before the first Container Storage Interface (CSI) release -- lots of things were still evolving. It was a very exciting time. What subprojects or areas do you actively maintain or review today? I'm a maintainer in Kubernetes CSI. There are multiple CSI sidecars -- such as csi-provisioner, csi-attacher, csi-resizer, and csi-snapshotter -- that we need to release following every Kubernetes release. I'm also a co-chair for a Data Protection Working Group co-sponsored by SIG Storage and SIG Apps . Several features have come out of that WG aimed at filling gaps in data protection support within Kubernetes. One is Volume Group Snapshot , which provides crash-consistent group snapshots for multiple volumes used by an application. Changed Block Tracking (CBT) is another critical feature

## Eliminating Kubernetes Image Signature Replication

DevFeed: [Eliminating Kubernetes Image Signature Replication](<https://devfeed.tech/articles/eliminating-kubernetes-image-signature-replication-17597.md>)

Original publisher: [Read original article](<https://www.kubernetes.dev/blog/2026/06/05/image-signature-routing/>)

Author: The Kubernetes Authors

Published: 2026-06-05T00:00:00Z

Content type: article

Language: en

Sources: [Kubernetes Contributors Blog](<https://devfeed.tech/sources/kubernetes-contributors-blog.md>)

Topics: [Kubernetes](<https://devfeed.tech/topics/kubernetes.md>), [Replication](<https://devfeed.tech/topics/replication.md>), [container images](<https://devfeed.tech/topics/container-images.md>), [Routing (disambiguation)](<https://devfeed.tech/topics/routing.md>), [Latency](<https://devfeed.tech/topics/latency.md>), [Google](<https://devfeed.tech/topics/google.md>)

Tags: [cloud](<https://devfeed.tech/tags/cloud.md>), [container-images](<https://devfeed.tech/tags/container-images.md>), [cosign](<https://devfeed.tech/tags/cosign.md>), [kubernetes](<https://devfeed.tech/tags/kubernetes.md>), [latency](<https://devfeed.tech/tags/latency.md>), [manifest](<https://devfeed.tech/tags/manifest.md>), [oidc](<https://devfeed.tech/tags/oidc.md>), [registry](<https://devfeed.tech/tags/registry.md>), [replication](<https://devfeed.tech/tags/replication.md>), [route](<https://devfeed.tech/tags/route.md>), [routing](<https://devfeed.tech/tags/routing.md>), [sha256](<https://devfeed.tech/tags/sha256.md>), [signing](<https://devfeed.tech/tags/signing.md>), [verify](<https://devfeed.tech/tags/verify.md>)

### AI overview

This article explains how Kubernetes eliminated replication of image signatures across 22 regional registries. Because signatures are small and regional latency is negligible, archeio now routes signature requests to a canonical registry while image layers continue using geo-routing.

### Source excerpt

The image promoter rewrite laid the groundwork for simplifying how Kubernetes delivers container image signatures. One of the rewrite phases (Phase 6) separated image signing from signature replication into distinct pipeline stages. This follow-up covers the next step: eliminating signature replication entirely. The problem After promoting container images to registry.k8s.io, the promoter signs them using cosign with keyless (OIDC) signatures. These signatures are stored as OCI artifacts alongside the images, tagged with the convention sha256-<digest>.sig and sha256-<digest>.att. The registry.k8s.io domain is backed by archeio , a thin redirector that routes container image requests to the nearest regional Google Artifact Registry backend. When a user in Europe pulls an image, archeio redirects them to europe-west2-docker.pkg.dev; a user in Asia gets redirected to asia-east1-docker.pkg.dev, and so on across 22 regional backends. This geo-routing is great for image layers, where download locality matters for performance. But it created a problem for signatures: if the promoter only wrote a signature to one region, cosign verify would fail for users redirected to any other region. The solution was a dedicated replication pipeline that copied every .sig and .att tag to all 22 regional backends. This pipeline ran as a periodic Prow job every 2 hours on weekdays, performing thousands of API calls per run: listing tags across all repositories, diffing what existed where, and copying the missing signatures. The insight Signatures and attestations are small metadata artifacts, typically a few kilobytes each. Unlike image layers where geo-locality provides meaningful download performance improvements, fetching a signature from a non-local region adds negligible latency. The entire replication pipeline existed to optimize for a latency difference that users would never notice. The solution Instead of replicating signatures everywhere, archeio was taught to route signature req

## Announcing the AI Gateway Working Group

DevFeed: [Announcing the AI Gateway Working Group](<https://devfeed.tech/articles/announcing-the-ai-gateway-working-group-17596.md>)

Original publisher: [Read original article](<https://www.kubernetes.dev/blog/2026/03/09/announcing-ai-gateway-wg/>)

Author: The Kubernetes Authors

Published: 2026-03-09T00:00:00Z

Content type: release

Language: en

Sources: [Kubernetes Contributors Blog](<https://devfeed.tech/sources/kubernetes-contributors-blog.md>)

Topics: [Kubernetes](<https://devfeed.tech/topics/kubernetes.md>), [networking](<https://devfeed.tech/topics/networking.md>), [AI Infrastructure](<https://devfeed.tech/topics/ai-infrastructure.md>), [Artificial Intelligence](<https://devfeed.tech/topics/ai.md>), [API](<https://devfeed.tech/topics/api.md>)

Tags: [ai-gateway](<https://devfeed.tech/tags/ai-gateway.md>), [ai-infrastructure](<https://devfeed.tech/tags/ai-infrastructure.md>), [anomaly-detection](<https://devfeed.tech/tags/anomaly-detection.md>), [architecture](<https://devfeed.tech/tags/architecture.md>), [caching](<https://devfeed.tech/tags/caching.md>), [kubernetes](<https://devfeed.tech/tags/kubernetes.md>), [networking](<https://devfeed.tech/tags/networking.md>), [payload](<https://devfeed.tech/tags/payload.md>), [prompt-injection](<https://devfeed.tech/tags/prompt-injection.md>), [rag](<https://devfeed.tech/tags/rag.md>), [rate-limiting](<https://devfeed.tech/tags/rate-limiting.md>), [routing](<https://devfeed.tech/tags/routing.md>)

### AI overview

The Kubernetes community has formed the AI Gateway Working Group to develop standards, declarative APIs, and best practices for networking infrastructure that supports AI workloads. The group's proposals address policy enforcement, payload processing, routing, caching, guardrails, and RAG integration.

### Source excerpt

The community around Kubernetes includes a number of Special Interest Groups (SIGs) and Working Groups (WGs) facilitating discussions on important topics between interested contributors. Today, we're excited to announce the formation of the AI Gateway Working Group , a new initiative focused on developing standards and best practices for networking infrastructure that supports AI workloads in Kubernetes environments. What is an AI Gateway? In a Kubernetes context, an AI Gateway refers to network gateway infrastructure (including proxy servers, load-balancers, etc.) that generally implements the Gateway API specification with enhanced capabilities for AI workloads. Rather than defining a distinct product category, AI Gateways describe infrastructure designed to enforce policy on AI traffic, including: Token-based rate limiting for AI APIs. Fine-grained access controls for inference APIs. Payload inspection enabling intelligent routing, caching, and guardrails. Support for AI-specific protocols and routing patterns. Working group charter and mission The AI Gateway Working Group operates under a clear charter with the mission to develop proposals for Kubernetes Special Interest Groups (SIGs) and their sub-projects. Its primary goals include: Standards Development: Create declarative APIs, standards, and guidance for AI workload networking in Kubernetes. Community Collaboration: Foster discussions and build consensus around best practices for AI infrastructure. Extensible Architecture: Ensure composability, pluggability, and ordered processing for AI-specific gateway extensions. Standards-Based Approach: Build on established networking foundations, layering AI-specific capabilities on top of proven standards. Active proposals WG AI Gateway currently has several active proposals that address key challenges in AI workload networking: Payload Processing The payload processing proposal addresses the critical need for AI workloads to inspect and transform full HTTP request a

## Spotlight on SIG Architecture: API Governance

DevFeed: [Spotlight on SIG Architecture: API Governance](<https://devfeed.tech/articles/spotlight-on-sig-architecture-api-governance-17595.md>)

Original publisher: [Read original article](<https://www.kubernetes.dev/blog/2026/02/12/sig-architecture-api/>)

Author: The Kubernetes Authors

Published: 2026-02-12T00:00:00Z

Content type: article

Language: en

Sources: [Kubernetes Contributors Blog](<https://devfeed.tech/sources/kubernetes-contributors-blog.md>)

Topics: [API Governance](<https://devfeed.tech/topics/api-governance.md>), [Kubernetes](<https://devfeed.tech/topics/kubernetes.md>), [API](<https://devfeed.tech/topics/api.md>), [Authentication](<https://devfeed.tech/topics/authentication.md>), [Authorization](<https://devfeed.tech/topics/authorization.md>), [OAuth](<https://devfeed.tech/topics/oauth.md>)

Tags: [api-governance](<https://devfeed.tech/tags/api-governance.md>), [apis](<https://devfeed.tech/tags/apis.md>), [auth](<https://devfeed.tech/tags/auth.md>), [authentication](<https://devfeed.tech/tags/authentication.md>), [authorization](<https://devfeed.tech/tags/authorization.md>), [interview](<https://devfeed.tech/tags/interview.md>), [kubernetes](<https://devfeed.tech/tags/kubernetes.md>), [oauth](<https://devfeed.tech/tags/oauth.md>), [spotlight](<https://devfeed.tech/tags/spotlight.md>)

### AI overview

An interview with Jordan Liggitt, lead of Kubernetes SIG Architecture's API Governance sub-project, discusses his work on Kubernetes authentication and authorization and the sub-project's scope. It explains that Kubernetes APIs include REST APIs as well as command-line flags, configuration files, binary execution, backend communication, and data persistence, with goals of stability and continued innovation.

### Source excerpt

This is the fifth interview of a SIG Architecture Spotlight series that covers the different subprojects, and we will be covering SIG Architecture: API Governance . In this SIG Architecture spotlight we talked with Jordan Liggitt , lead of the API Governance sub-project. Introduction FM: Hello Jordan, thank you for your availability. Tell us a bit about yourself, your role and how you got involved in Kubernetes. JL: My name is Jordan Liggitt. I'm a Christian, husband, father of four, software engineer at Google by day, and amateur musician by stealth. I was born in Texas (and still like to claim it as my point of origin), but I've lived in North Carolina for most of my life. I've been working on Kubernetes since 2014. At that time, I was working on authentication and authorization at Red Hat, and my very first pull request to Kubernetes attempted to add an OAuth server to the Kubernetes API server. It never exited work-in-progress status. I ended up going with a different approach that layered on top of the core Kubernetes API server in a different project (spoiler alert: this is foreshadowing), and I closed it without merging six months later. Undeterred by that start, I stayed involved, helped build Kubernetes authentication and authorization capabilities, and got involved in the definition and evolution of the core Kubernetes APIs from early beta APIs, like v1beta3 to v1. I got tagged as an API reviewer in 2016 based on those contributions, and was added as an API approver in 2017. Today, I help lead the API Governance and code organization subprojects for SIG Architecture, and I am a tech lead for SIG Auth. FM: And when did you get specifically involved in the API Governance project? JL: Around 2019. Goals and scope of API Governance FM: How would you describe the main goals and areas of intervention of the subproject? The surface area includes all the various APIs Kubernetes has, and there are APIs that people do not always realize are APIs: command-line flags,

## Announcing the Checkpoint/Restore Working Group

DevFeed: [Announcing the Checkpoint/Restore Working Group](<https://devfeed.tech/articles/announcing-the-checkpoint-restore-working-group-17594.md>)

Original publisher: [Read original article](<https://www.kubernetes.dev/blog/2026/01/21/introducing-checkpoint-restore-wg/>)

Author: The Kubernetes Authors

Published: 2026-01-21T00:00:00Z

Content type: release

Language: en

Sources: [Kubernetes Contributors Blog](<https://devfeed.tech/sources/kubernetes-contributors-blog.md>)

Topics: [Kubernetes](<https://devfeed.tech/topics/kubernetes.md>), [Containers](<https://devfeed.tech/topics/containers.md>), [migration](<https://devfeed.tech/topics/migration.md>), [distributed-systems](<https://devfeed.tech/topics/distributed-systems.md>), [Security](<https://devfeed.tech/topics/security.md>)

Tags: [announce](<https://devfeed.tech/tags/announce.md>), [container](<https://devfeed.tech/tags/container.md>), [distributed](<https://devfeed.tech/tags/distributed.md>), [kubernetes](<https://devfeed.tech/tags/kubernetes.md>), [migration](<https://devfeed.tech/tags/migration.md>), [security](<https://devfeed.tech/tags/security.md>)

### AI overview

Kubernetes announces a new Checkpoint/Restore Working Group focused on integrating checkpoint and restore functionality into Kubernetes. The article outlines potential uses including resource optimization, faster application startup, fault tolerance, interruption-aware scheduling, pod migration, and forensic analysis, and describes related CRIU projects and ways to participate.

### Source excerpt

The community around Kubernetes includes a number of Special Interest Groups (SIGs) and Working Groups (WGs) facilitating discussions on important topics between interested contributors. Today we would like to announce the new Kubernetes Checkpoint Restore WG focusing on the integration of Checkpoint/Restore functionality into Kubernetes. Motivation and use cases There are several high-level scenarios discussed in the working group: Optimizing resource utilization for interactive workloads, such as Jupyter notebooks and AI chatbots Accelerating startup of applications with long initialization times, including Java applications and LLM inference services Using periodic checkpointing to enable fault-tolerance for long-running workloads, such as distributed model training Providing interruption-aware scheduling with transparent checkpoint/restore, allowing lower-priority Pods to be preempted while preserving the runtime state of applications Facilitating Pod migration across nodes for load balancing and maintenance, without disrupting workloads. Enabling forensic checkpointing to investigate and analyze security incidents such as cyberattacks, data breaches, and unauthorized access. Across these scenarios, the goal is to help facilitate discussions of ideas between the Kubernetes community and the growing Checkpoint/Restore in Userspace (CRIU) ecosystem. The CRIU community includes several projects that support these use cases, including: CRIU - A tool for checkpointing and restoring running applications and containers checkpointctl - A tool for in-depth analysis of container checkpoints criu-coordinator - A tool for coordinated checkpoint/restore of distributed applications with CRIU checkpoint-restore-operator - A Kubernetes operator for managing checkpoints More information about the checkpoint/restore integration with Kubernetes is also available here . Related events Following our presentation about transparent checkpointing at KubeCon EU 2025, we are excited to w

## Ingress NGINX Retirement: What You Need to Know

DevFeed: [Ingress NGINX Retirement: What You Need to Know](<https://devfeed.tech/articles/ingress-nginx-retirement-what-you-need-to-know-17593.md>)

Original publisher: [Read original article](<https://www.kubernetes.dev/blog/2025/11/12/ingress-nginx-retirement/>)

Author: The Kubernetes Authors

Published: 2025-11-12T17:00:00Z

Content type: release

Language: en

Sources: [Kubernetes Contributors Blog](<https://devfeed.tech/sources/kubernetes-contributors-blog.md>)

Topics: [ingress-nginx](<https://devfeed.tech/topics/ingress-nginx.md>), [ingress nginx retirement](<https://devfeed.tech/topics/ingress-nginx-retirement.md>), [Kubernetes](<https://devfeed.tech/topics/kubernetes.md>), [Security](<https://devfeed.tech/topics/security.md>), [Vulnerabilities](<https://devfeed.tech/topics/vulnerabilities.md>), [Network](<https://devfeed.tech/topics/network.md>)

Tags: [alternatives](<https://devfeed.tech/tags/alternatives.md>), [gateway](<https://devfeed.tech/tags/gateway.md>), [ingress-nginx](<https://devfeed.tech/tags/ingress-nginx.md>), [ingress-nginx-retirement](<https://devfeed.tech/tags/ingress-nginx-retirement.md>), [kubernetes](<https://devfeed.tech/tags/kubernetes.md>), [releases](<https://devfeed.tech/tags/releases.md>), [security](<https://devfeed.tech/tags/security.md>), [security-vulnerabilities](<https://devfeed.tech/tags/security-vulnerabilities.md>)

### AI overview

Kubernetes SIG Network and the Security Response Committee announce the upcoming retirement of Ingress NGINX. Best-effort maintenance will continue until March 2026; afterward, the project will receive no further releases, bug fixes, or security updates. Existing deployments and installation artifacts will remain available, and users are encouraged to migrate to alternatives such as Gateway API.

### Source excerpt

To prioritize the safety and security of the ecosystem, Kubernetes SIG Network and the Security Response Committee are announcing the upcoming retirement of Ingress NGINX . Best-effort maintenance will continue until March 2026. Afterward, there will be no further releases, no bugfixes, and no updates to resolve any security vulnerabilities that may be discovered. Existing deployments of Ingress NGINX will continue to function and installation artifacts will remain available. We recommend migrating to one of the many alternatives. Consider migrating to Gateway API , the modern replacement for Ingress. If you must continue using Ingress, many alternative Ingress controllers are listed in the Kubernetes documentation . Continue reading for further information about the history and current state of Ingress NGINX, as well as next steps. About Ingress NGINX Ingress is the original user-friendly way to direct network traffic to workloads running on Kubernetes. (Gateway API is a newer way to achieve many of the same goals.) In order for an Ingress to work in your cluster, there must be an Ingress controller running. There are many Ingress controller choices available, which serve the needs of different users and use cases. Some are cloud-provider specific, while others have more general applicability. Ingress NGINX was an Ingress controller, developed early in the history of the Kubernetes project as an example implementation of the API. It became very popular due to its tremendous flexibility, breadth of features, and independence from any particular cloud or infrastructure provider. Since those days, many other Ingress controllers have been created within the Kubernetes project by community groups, and by cloud native vendors. Ingress NGINX has continued to be one of the most popular, deployed as part of many hosted Kubernetes platforms and within innumerable independent users' clusters. History and Challenges The breadth and flexibility of Ingress NGINX has caused maint

## Announcing the 2025 Steering Committee Election Results

DevFeed: [Announcing the 2025 Steering Committee Election Results](<https://devfeed.tech/articles/announcing-the-2025-steering-committee-election-results-17592.md>)

Original publisher: [Read original article](<https://www.kubernetes.dev/blog/2025/11/09/steering-committee-results-2025/>)

Author: The Kubernetes Authors

Published: 2025-11-09T20:10:00Z

Content type: news

Language: en

Sources: [Kubernetes Contributors Blog](<https://devfeed.tech/sources/kubernetes-contributors-blog.md>)

Topics: [Kubernetes](<https://devfeed.tech/topics/kubernetes.md>), [Pull Request](<https://devfeed.tech/topics/pull-request.md>)

Tags: [2025](<https://devfeed.tech/tags/2025.md>), [github](<https://devfeed.tech/tags/github.md>), [governance](<https://devfeed.tech/tags/governance.md>), [issue](<https://devfeed.tech/tags/issue.md>), [kubernetes](<https://devfeed.tech/tags/kubernetes.md>), [project](<https://devfeed.tech/tags/project.md>)

### AI overview

Kubernetes announces the results of its 2025 Steering Committee election. Four new members were elected to two-year terms, joining three continuing members on the seven-seat committee that oversees Kubernetes project governance.

### Source excerpt

The 2025 Steering Committee Election is now complete. The Kubernetes Steering Committee consists of 7 seats, 4 of which were up for election in 2025. Incoming committee members serve a term of 2 years, and all members are elected by the Kubernetes Community. The Steering Committee oversees the governance of the entire Kubernetes project. With that great power comes great responsibility. You can learn more about the steering committee's role in their charter . Thank you to everyone who voted in the election; your participation helps support the community's continued health and success. Results Congratulations to the elected committee members whose two year terms begin immediately (listed in alphabetical order by GitHub handle): Kat Cosgrove (@katcosgrove ), Minimus Paco Xu (@pacoxu ), DaoCloud Rita Zhang (@ritazh ), Microsoft Maciej Szulik (@soltysh ), Defense Unicorns They join continuing members: Antonio Ojea (@aojea ), Google Benjamin Elder (@BenTheElder ), Google Sascha Grunert (@saschagrunert ), Red Hat Maciej Szulik and Paco Xu are returning Steering Committee Members. Big thanks! Thank you and congratulations on a successful election to this round's election officers: Christoph Blecker (@cblecker ) Nina Polshakova (@npolshakova ) Sreeram Venkitesh (@sreeram-venkitesh ) Thanks to the Emeritus Steering Committee Members. Your service is appreciated by the community: Stephen Augustus (@justaugustus ), Bloomberg Patrick Ohly (@pohly ), Intel And thank you to all the candidates who came forward to run for election. Get involved with the Steering Committee This governing body, like all of Kubernetes, is open to all. You can follow along with Steering Committee meeting notes and weigh in by filing an issue or creating a PR against their repo . They have an open meeting on the first Wednesday at 8am PT of every month . They can also be contacted at their public mailing list steering@kubernetes.io . You can see what the Steering Committee meetings are all about by watc

## Spotlight on Policy Working Group

DevFeed: [Spotlight on Policy Working Group](<https://devfeed.tech/articles/spotlight-on-policy-working-group-17591.md>)

Original publisher: [Read original article](<https://www.kubernetes.dev/blog/2025/10/18/wg-policy-spotlight-2025/>)

Author: The Kubernetes Authors

Published: 2025-10-18T00:00:00Z

Content type: article

Language: en

Sources: [Kubernetes Contributors Blog](<https://devfeed.tech/sources/kubernetes-contributors-blog.md>)

Topics: [Kubernetes](<https://devfeed.tech/topics/kubernetes.md>), [Security](<https://devfeed.tech/topics/security.md>), [Architecture & Design](<https://devfeed.tech/topics/architecture-design.md>), [Kyverno](<https://devfeed.tech/topics/kyverno.md>), [JSON Schema](<https://devfeed.tech/topics/json-schema.md>)

Tags: [architecture](<https://devfeed.tech/tags/architecture.md>), [article](<https://devfeed.tech/tags/article.md>), [blog-post](<https://devfeed.tech/tags/blog-post.md>), [json-schema](<https://devfeed.tech/tags/json-schema.md>), [kubernetes](<https://devfeed.tech/tags/kubernetes.md>), [kyverno](<https://devfeed.tech/tags/kyverno.md>), [security](<https://devfeed.tech/tags/security.md>)

### AI overview

This retrospective examines the completed Kubernetes Policy Working Group, its goal of developing an overall architecture for current and future policy implementations, and insights from former co-chairs about policy management in the Kubernetes ecosystem.

### Source excerpt

(Note: The Policy Working Group has completed its mission and is no longer active. This article reflects its work, accomplishments, and insights into how a working group operates.) In the complex world of Kubernetes, policies play a crucial role in managing and securing clusters. But have you ever wondered how these policies are developed, implemented, and standardized across the Kubernetes ecosystem? To answer that, let's take a look back at the work of the Policy Working Group. The Policy Working Group was dedicated to a critical mission: providing an overall architecture that encompasses both current policy-related implementations and future policy proposals in Kubernetes. Their goal was both ambitious and essential: to develop a universal policy architecture that benefits developers and end-users alike. Through collaborative methods, this working group strove to bring clarity and consistency to the often complex world of Kubernetes policies. By focusing on both existing implementations and future proposals, they ensured that the policy landscape in Kubernetes remains coherent and accessible as the technology evolves. This blog post dives deeper into the work of the Policy Working Group, guided by insights from its former co-chairs: Jim Bugwadia Poonam Lamba Andy Suderman Interviewed by Arujjwal Negi . These co-chairs explained what the Policy Working Group was all about. Introduction Hello, thank you for the time! Let's start with some introductions, could you tell us a bit about yourself, your role, and how you got involved in Kubernetes? Jim Bugwadia: My name is Jim Bugwadia, and I am a co-founder and the CEO at Nirmata which provides solutions that automate security and compliance for cloud-native workloads. At Nirmata, we have been working with Kubernetes since it started in 2014. We initially built a Kubernetes policy engine in our commercial platform and later donated it to CNCF as the Kyverno project. I joined the CNCF Kubernetes Policy Working Group to h

## Spotlight on the Kubernetes Steering Committee

DevFeed: [Spotlight on the Kubernetes Steering Committee](<https://devfeed.tech/articles/spotlight-on-the-kubernetes-steering-committee-17590.md>)

Original publisher: [Read original article](<https://www.kubernetes.dev/blog/2025/09/22/k8s-steering-spotlight-2025/>)

Author: The Kubernetes Authors

Published: 2025-09-22T00:00:00Z

Content type: article

Language: en

Sources: [Kubernetes Contributors Blog](<https://devfeed.tech/sources/kubernetes-contributors-blog.md>)

Topics: [Kubernetes](<https://devfeed.tech/topics/kubernetes.md>), [Open Source](<https://devfeed.tech/topics/open-source.md>)

Tags: [interview](<https://devfeed.tech/tags/interview.md>), [kubernetes](<https://devfeed.tech/tags/kubernetes.md>), [open-source](<https://devfeed.tech/tags/open-source.md>), [spotlight](<https://devfeed.tech/tags/spotlight.md>)

### AI overview

An interview with Kubernetes Steering Committee members discusses the committee's responsibilities, organizational challenges, contributor support, motivations, and future outlook. The article notes that the interview was conducted in August 2024 and may not reflect the committee's current composition.

### Source excerpt

This interview was conducted in August 2024, and due to the dynamic nature of the Steering Committee membership and election process it might not represent the actual composition accurately. The topics covered are, however, overwhelmingly relevant to understand its scope of work. As we approach the Steering Committee elections, it provides useful insights into the workings of the Committee. The Kubernetes Steering Committee is the backbone of the Kubernetes project, ensuring that its vibrant community and governance structures operate smoothly and effectively. While the technical brilliance of Kubernetes is often spotlighted through its Special Interest Groups (SIGs) and Working Groups (WGs) , the unsung heroes quietly steering the ship are the members of the Steering Committee. They tackle complex organizational challenges, empower contributors, and foster the thriving open source ecosystem that Kubernetes is celebrated for. But what does it really take to lead one of the world's largest open source communities? What are the hidden challenges, and what drives these individuals to dedicate their time and effort to such an impactful role? In this exclusive conversation, we sit down with current Steering Committee (SC) members -- Ben, Nabarun, Paco, Patrick, and Maciej -- to uncover the rewarding, and sometimes demanding, realities of steering Kubernetes. From their personal journeys and motivations to the committee's vital responsibilities and future outlook, this Spotlight offers a rare behind-the-scenes glimpse into the people who keep Kubernetes on course. Introductions Sandipan: Can you tell us a little bit about yourself? Ben: Hi, I'm Benjamin Elder , also known as BenTheElder. I started in Kubernetes as a Google Summer of Code student in 2015 and have been working at Google in the space since 2017. I have contributed a lot to many areas but especially build, CI, test tooling, etc. My favorite project so far was building KIND . I have been on the release team, a c

## Changes to Kubernetes Slack

DevFeed: [Changes to Kubernetes Slack](<https://devfeed.tech/articles/changes-to-kubernetes-slack-17588.md>)

Original publisher: [Read original article](<https://www.kubernetes.dev/blog/2025/06/16/changes-to-kubernetes-slack-2025/>)

Author: The Kubernetes Authors

Published: 2025-06-16T00:00:00Z

Content type: news

Language: en

Sources: [Kubernetes Contributors Blog](<https://devfeed.tech/sources/kubernetes-contributors-blog.md>)

Topics: [Slack](<https://devfeed.tech/topics/slack.md>), [Discord](<https://devfeed.tech/topics/discord.md>), [Kubernetes](<https://devfeed.tech/topics/kubernetes.md>), [GitHub](<https://devfeed.tech/topics/github.md>)

Tags: [2025](<https://devfeed.tech/tags/2025.md>), [cncf](<https://devfeed.tech/tags/cncf.md>), [community](<https://devfeed.tech/tags/community.md>), [discord](<https://devfeed.tech/tags/discord.md>), [enterprise](<https://devfeed.tech/tags/enterprise.md>), [free](<https://devfeed.tech/tags/free.md>), [github](<https://devfeed.tech/tags/github.md>), [integrations](<https://devfeed.tech/tags/integrations.md>), [slack](<https://devfeed.tech/tags/slack.md>), [update](<https://devfeed.tech/tags/update.md>)

### AI overview

The Kubernetes Slack workspace will become a standard free Slack on June 20, 2025, with 90 days of history and the loss of several apps and workflows. The community is considering Discord as a future platform, but the Steering Committee has not decided.

### Source excerpt

UPDATE: We've received notice from Salesforce that our Slack workspace WILL NOT BE DOWNGRADED on June 20th. Stand by for more details, but for now, there is no urgency to back up private channels or direct messages. Kubernetes Slack will lose its special status and will be changing into a standard free Slack on June 20, 2025. Sometime later this year, our community may move to a new platform. If you are responsible for a channel or private channel, or a member of a User Group, you will need to take some actions as soon as you can. For the last decade, Slack has supported our project with a free customized enterprise account. They have let us know that they can no longer do so, particularly since our Slack is one of the largest and more active ones on the platform. As such, they will be downgrading it to a standard free Slack while we decide on, and implement, other options. On Friday, June 20, we will be subject to the feature limitations of free Slack . The primary ones which will affect us will be only retaining 90 days of history, and having to disable several apps and workflows which we are currently using. The Slack Admin team will do their best to manage these limitations. Responsible channel owners, members of private channels, and members of User Groups should take some actions to prepare for the upgrade and preserve information as soon as possible. The CNCF projects staff have proposed that our community look at migrating to Discord. Because of existing issues where we have been pushing the limits of Slack, they have already explored what a Kubernetes Discord would look like. Discord would allow us to implement new tools and integrations which would help the community, such as GitHub group membership synchronization. The Steering Committee will discuss and decide on our future platform. Please see our FAQ , and check the kubernetes-dev mailing list and the #announcements channel for further news. If you have specific feedback on our Slack status join the di

## Spotlight on SIG Apps

DevFeed: [Spotlight on SIG Apps](<https://devfeed.tech/articles/spotlight-on-sig-apps-17587.md>)

Original publisher: [Read original article](<https://www.kubernetes.dev/blog/2025/03/12/sig-apps-spotlight-2025/>)

Author: The Kubernetes Authors

Published: 2025-03-12T00:00:00Z

Content type: article

Language: en

Sources: [Kubernetes Contributors Blog](<https://devfeed.tech/sources/kubernetes-contributors-blog.md>)

Topics: [Kubernetes](<https://devfeed.tech/topics/kubernetes.md>), [Development](<https://devfeed.tech/topics/development.md>), [Deployment](<https://devfeed.tech/topics/deployment.md>), [Command-line interface](<https://devfeed.tech/topics/cli.md>)

Tags: [applications](<https://devfeed.tech/tags/applications.md>), [controllers](<https://devfeed.tech/tags/controllers.md>), [interview](<https://devfeed.tech/tags/interview.md>), [kubernetes](<https://devfeed.tech/tags/kubernetes.md>), [spotlight](<https://devfeed.tech/tags/spotlight.md>)

### AI overview

An interview with the chairs and tech leads of Kubernetes SIG Apps about the group's mission, leadership, and work on developing, deploying, and operating applications on Kubernetes. The discussion also covers controllers and challenges from running AI-related workloads.

### Source excerpt

In our ongoing SIG Spotlight series, we dive into the heart of the Kubernetes project by talking to the leaders of its various Special Interest Groups (SIGs). This time, we focus on SIG Apps , the group responsible for everything related to developing, deploying, and operating applications on Kubernetes. Sandipan Panda (DevZero ) had the opportunity to interview Maciej Szulik (Defense Unicorns ) and Janet Kuo (Google ), the chairs and tech leads of SIG Apps. They shared their experiences, challenges, and visions for the future of application management within the Kubernetes ecosystem. Introductions Sandipan: Hello, could you start by telling us a bit about yourself, your role, and your journey within the Kubernetes community that led to your current roles in SIG Apps? Maciej: Hey, my name is Maciej, and I'm one of the leads for SIG Apps. Aside from this role, you can also find me helping SIG CLI and also being one of the Steering Committee members. I've been contributing to Kubernetes since late 2014 in various areas, including controllers, apiserver, and kubectl. Janet: Certainly! I'm Janet, a Staff Software Engineer at Google, and I've been deeply involved with the Kubernetes project since its early days, even before the 1.0 launch in 2015. It's been an amazing journey! My current role within the Kubernetes community is one of the chairs and tech leads of SIG Apps. My journey with SIG Apps started organically. I started with building the Deployment API and adding rolling update functionalities. I naturally gravitated towards SIG Apps and became increasingly involved. Over time, I took on more responsibilities, culminating in my current leadership roles. About SIG Apps All following answers were jointly provided by Maciej and Janet. Sandipan: For those unfamiliar, could you provide an overview of SIG Apps' mission and objectives? What key problems does it aim to solve within the Kubernetes ecosystem? As described in our charter , we cover a broad area related to de

## Spotlight on SIG etcd

DevFeed: [Spotlight on SIG etcd](<https://devfeed.tech/articles/spotlight-on-sig-etcd-17586.md>)

Original publisher: [Read original article](<https://www.kubernetes.dev/blog/2025/03/04/sig-etcd-spotlight/>)

Author: The Kubernetes Authors

Published: 2025-03-04T00:00:00Z

Content type: article

Language: en

Sources: [Kubernetes Contributors Blog](<https://devfeed.tech/sources/kubernetes-contributors-blog.md>)

Topics: [Kubernetes](<https://devfeed.tech/topics/kubernetes.md>), [Maintainers](<https://devfeed.tech/topics/maintainers.md>), [Open Source](<https://devfeed.tech/topics/open-source.md>), [distributed-systems](<https://devfeed.tech/topics/distributed-systems.md>), [Google](<https://devfeed.tech/topics/google.md>)

Tags: [distributed-systems](<https://devfeed.tech/tags/distributed-systems.md>), [google](<https://devfeed.tech/tags/google.md>), [kubernetes](<https://devfeed.tech/tags/kubernetes.md>), [maintainers](<https://devfeed.tech/tags/maintainers.md>), [open-source](<https://devfeed.tech/tags/open-source.md>), [tech-lead](<https://devfeed.tech/tags/tech-lead.md>), [testing](<https://devfeed.tech/tags/testing.md>)

### AI overview

A Kubernetes community spotlight interviews SIG etcd leaders and maintainers about their roles, paths into Kubernetes and etcd, and contributions to the open-source ecosystem.

### Source excerpt

In this SIG etcd spotlight we talked with James Blair , Marek Siarkowicz , Wenjia Zhang , and Benjamin Wang to learn a bit more about this Kubernetes Special Interest Group. Introducing SIG etcd Frederico: Hello, thank you for the time! Let's start with some introductions, could you tell us a bit about yourself, your role and how you got involved in Kubernetes. Benjamin: Hello, I am Benjamin. I am a SIG etcd Tech Lead and one of the etcd maintainers. I work for VMware, which is part of the Broadcom group. I got involved in Kubernetes & etcd & CSI (Container Storage Interface ) because of work and also a big passion for open source. I have been working on Kubernetes & etcd (and also CSI) since 2020. James: Hey team, I'm James, a co-chair for SIG etcd and etcd maintainer. I work at Red Hat as a Specialist Architect helping people adopt cloud native technology. I got involved with the Kubernetes ecosystem in 2019. Around the end of 2022 I noticed how the etcd community and project needed help so started contributing as often as I could. There is a saying in our community that "you come for the technology, and stay for the people": for me this is absolutely real, it's been a wonderful journey so far and I'm excited to support our community moving forward. Marek: Hey everyone, I'm Marek, the SIG etcd lead. At Google, I lead the GKE etcd team, ensuring a stable and reliable experience for all GKE users. My Kubernetes journey began with SIG Instrumentation , where I created and led the Kubernetes Structured Logging effort . I'm still the main project lead for Kubernetes Metrics Server , providing crucial signals for autoscaling in Kubernetes. I started working on etcd 3 years ago, right around the 3.5 release. We faced some challenges, but I'm thrilled to see etcd now the most scalable and reliable it's ever been, with the highest contribution numbers in the project's history. I'm passionate about distributed systems, extreme programming, and testing. Wenjia: Hi there, my

## Spotlight on SIG Architecture: Enhancements

DevFeed: [Spotlight on SIG Architecture: Enhancements](<https://devfeed.tech/articles/spotlight-on-sig-architecture-enhancements-17585.md>)

Original publisher: [Read original article](<https://www.kubernetes.dev/blog/2025/01/21/sig-architecture-enhancements/>)

Author: The Kubernetes Authors

Published: 2025-01-21T00:00:00Z

Content type: article

Language: en

Sources: [Kubernetes Contributors Blog](<https://devfeed.tech/sources/kubernetes-contributors-blog.md>)

Topics: [Kubernetes](<https://devfeed.tech/topics/kubernetes.md>), [Processes](<https://devfeed.tech/topics/processes.md>)

Tags: [interview](<https://devfeed.tech/tags/interview.md>), [kubernetes](<https://devfeed.tech/tags/kubernetes.md>), [release](<https://devfeed.tech/tags/release.md>), [series](<https://devfeed.tech/tags/series.md>)

### AI overview

An interview with Kirsten Garrison, lead of the Kubernetes SIG Architecture Enhancements subproject, explains how Kubernetes Enhancement Proposals support feature design and significant project changes. It describes the KEP approval process across release cycles and feature phases.

### Source excerpt

This is the fourth interview of a SIG Architecture Spotlight series that will cover the different subprojects, and we will be covering SIG Architecture: Enhancements . In this SIG Architecture spotlight we talked with Kirsten Garrison , lead of the Enhancements subproject. The Enhancements subproject Frederico (FSM): Hi Kirsten, very happy to have the opportunity to talk about the Enhancements subproject. Let's start with some quick information about yourself and your role. Kirsten Garrison (KG): I'm a lead of the Enhancements subproject of SIG-Architecture and currently work at Google. I first got involved by contributing to the service-catalog project with the help of Carolyn Van Slyck . With time, I joined the Release team , eventually becoming the Enhancements Lead and a Release Lead shadow. While on the release team, I worked on some ideas to make the process better for the SIGs and Enhancements team (the opt-in process) based on my team's experiences. Eventually, I started attending Subproject meetings and contributing to the Subproject's work. FSM: You mentioned the Enhancements subproject: how would you describe its main goals and areas of intervention? KG: The Enhancements Subproject primarily concerns itself with the Kubernetes Enhancement Proposal (KEP for short)--the "design" documents required for all features and significant changes to the Kubernetes project. The KEP and its impact FSM: The improvement of the KEP process was (and is) one in which SIG Architecture was heavily involved. Could you explain the process to those that aren't aware of it? KG: Every release , the SIGs let the Release Team know which features they intend to work on to be put into the release. As mentioned above, the prerequisite for these changes is a KEP - a standardized design document that all authors must fill out and approve in the first weeks of the release cycle. Most features will move through 3 phases : alpha, beta and finally GA so approving a feature represents a signi

## Spotlight on Kubernetes Upstream Training in Japan

DevFeed: [Spotlight on Kubernetes Upstream Training in Japan](<https://devfeed.tech/articles/spotlight-on-kubernetes-upstream-training-in-japan-17584.md>)

Original publisher: [Read original article](<https://www.kubernetes.dev/blog/2024/10/28/k8s-upstream-training-japan-spotlight/>)

Author: The Kubernetes Authors

Published: 2024-10-28T00:00:00Z

Content type: article

Language: en

Sources: [Kubernetes Contributors Blog](<https://devfeed.tech/sources/kubernetes-contributors-blog.md>)

Topics: [Kubernetes](<https://devfeed.tech/topics/kubernetes.md>), [Development](<https://devfeed.tech/topics/development.md>), [Pull Request](<https://devfeed.tech/topics/pull-request.md>), [GitHub](<https://devfeed.tech/topics/github.md>), [CI/CD](<https://devfeed.tech/topics/cicd.md>)

Tags: [beginners](<https://devfeed.tech/tags/beginners.md>), [ci-cd](<https://devfeed.tech/tags/ci-cd.md>), [github](<https://devfeed.tech/tags/github.md>), [japan](<https://devfeed.tech/tags/japan.md>), [kubernetes](<https://devfeed.tech/tags/kubernetes.md>), [training](<https://devfeed.tech/tags/training.md>)

### AI overview

This article highlights Kubernetes Upstream Training in Japan, an online program designed to help newcomers begin contributing to the Kubernetes community. It covers community structure, development setup, codebase navigation, pull requests, communication, and the contribution workflow.

### Source excerpt

We are organizers of Kubernetes Upstream Training in Japan . Our team is composed of members who actively contribute to Kubernetes, including individuals who hold roles such as member, reviewer, approver, and chair. Our goal is to increase the number of Kubernetes contributors and foster the growth of the community. While Kubernetes community is friendly and collaborative, newcomers may find the first step of contributing to be a bit challenging. Our training program aims to lower that barrier and create an environment where even beginners can participate smoothly. What is Kubernetes upstream training in Japan? Our training started in 2019 and is held 1 to 2 times a year. Initially, Kubernetes Upstream Training was conducted as a co-located event of KubeCon (Kubernetes Contributor Summit), but we launched Kubernetes Upstream Training in Japan with the aim of increasing Japanese contributors by hosting a similar event in Japan. Before the pandemic, the training was held in person, but since 2020, it has been conducted online. The training offers the following content for those who have not yet contributed to Kubernetes: Introduction to Kubernetes community Overview of Kubernetes codebase and how to create your first PR Tips and encouragement to lower participation barriers, such as language How to set up the development environment Hands-on session using kubernetes-sigs/contributor-playground At the beginning of the program, we explain why contributing to Kubernetes is important and who can contribute. We emphasize that contributing to Kubernetes allows you to make a global impact and that Kubernetes community is looking forward to your contributions! We also explain Kubernetes community, SIGs, and Working Groups. Next, we explain the roles and responsibilities of Member, Reviewer, Approver, Tech Lead, and Chair. Additionally, we introduce the communication tools we primarily use, such as Slack, GitHub, and mailing lists. Some Japanese speakers may feel that communic

## Announcing the 2024 Steering Committee Election Results

DevFeed: [Announcing the 2024 Steering Committee Election Results](<https://devfeed.tech/articles/announcing-the-2024-steering-committee-election-results-17583.md>)

Original publisher: [Read original article](<https://www.kubernetes.dev/blog/2024/10/02/steering-committee-results-2024/>)

Author: The Kubernetes Authors

Published: 2024-10-02T20:10:00Z

Content type: news

Language: en

Sources: [Kubernetes Contributors Blog](<https://devfeed.tech/sources/kubernetes-contributors-blog.md>)

Topics: [Kubernetes](<https://devfeed.tech/topics/kubernetes.md>), [GitHub](<https://devfeed.tech/topics/github.md>)

Tags: [community](<https://devfeed.tech/tags/community.md>), [github](<https://devfeed.tech/tags/github.md>), [governance](<https://devfeed.tech/tags/governance.md>), [kubernetes](<https://devfeed.tech/tags/kubernetes.md>)

### AI overview

The Kubernetes 2024 Steering Committee election concluded with three elected members--Antonio Ojea, Benjamin Elder, and Sascha Grunert--joining the continuing committee members for two-year terms. The article also explains how the community can follow and participate in committee activities.

### Source excerpt

The 2024 Steering Committee Election is now complete. The Kubernetes Steering Committee consists of 7 seats, 3 of which were up for election in 2024. Incoming committee members serve a term of 2 years, and all members are elected by the Kubernetes Community. This community body is significant since it oversees the governance of the entire Kubernetes project. With that great power comes great responsibility. You can learn more about the steering committee's role in their charter . Thank you to everyone who voted in the election; your participation helps support the community's continued health and success. Results Congratulations to the elected committee members whose two year terms begin immediately (listed in alphabetical order by GitHub handle): Antonio Ojea (@aojea ), Google Benjamin Elder (@BenTheElder ), Google Sascha Grunert (@saschagrunert ), Red Hat They join continuing members: Stephen Augustus (@justaugustus ), Cisco Paco Xu 徐俊杰 (@pacoxu ), DaoCloud Patrick Ohly (@pohly ), Intel Maciej Szulik (@soltysh ), Defense Unicorns Benjamin Elder is a returning Steering Committee Member. Big thanks! Thank you and congratulations on a successful election to this round's election officers: Bridget Kromhout (@bridgetkromhout ) Christoph Blecker (@cblecker ) Priyanka Saggu (@Priyankasaggu11929 ) Thanks to the Emeritus Steering Committee Members. Your service is appreciated by the community: Bob Killen (@mrbobbytables ) Nabarun Pal (@palnabarun ) And thank you to all the candidates who came forward to run for election. Get involved with the Steering Committee This governing body, like all of Kubernetes, is open to all. You can follow along with Steering Committee meeting notes and weigh in by filing an issue or creating a PR against their repo . They have an open meeting on the first Monday at 8am PT of every month . They can also be contacted at their public mailing list steering@kubernetes.io . You can see what the Steering Committee meetings are all about by watching

## Spotlight on CNCF Deaf and Hard-of-hearing Working Group (DHHWG)

DevFeed: [Spotlight on CNCF Deaf and Hard-of-hearing Working Group (DHHWG)](<https://devfeed.tech/articles/spotlight-on-cncf-deaf-and-hard-of-hearing-working-group-dhhwg-17582.md>)

Original publisher: [Read original article](<https://www.kubernetes.dev/blog/2024/09/30/cncf-deaf-and-hard-of-hearing-working-group-spotlight/>)

Author: The Kubernetes Authors

Published: 2024-09-30T00:00:00Z

Content type: article

Language: en

Sources: [Kubernetes Contributors Blog](<https://devfeed.tech/sources/kubernetes-contributors-blog.md>)

Topics: [User interface design](<https://devfeed.tech/topics/ui-design.md>), [Open Source](<https://devfeed.tech/topics/open-source.md>), [Kubernetes](<https://devfeed.tech/topics/kubernetes.md>), [Cloud Native Ecosystem](<https://devfeed.tech/topics/cloud-native-ecosystem.md>), [Maintainers](<https://devfeed.tech/topics/maintainers.md>), [linkerd](<https://devfeed.tech/topics/linkerd.md>)

Tags: [accessibility](<https://devfeed.tech/tags/accessibility.md>), [diversity](<https://devfeed.tech/tags/diversity.md>), [inclusion](<https://devfeed.tech/tags/inclusion.md>), [inclusive](<https://devfeed.tech/tags/inclusive.md>), [kubernetes](<https://devfeed.tech/tags/kubernetes.md>), [linkerd](<https://devfeed.tech/tags/linkerd.md>), [maintainers](<https://devfeed.tech/tags/maintainers.md>), [open-source](<https://devfeed.tech/tags/open-source.md>)

### AI overview

An interview with Catherine Paganini explores the CNCF Deaf and Hard-of-Hearing Working Group, its role in improving inclusion and accessibility, and pathways for people with disabilities to contribute to cloud native open-source projects such as Kubernetes.

### Source excerpt

In recognition of Deaf Awareness Month and the importance of inclusivity in the tech community, we are spotlighting Catherine Paganini , facilitator and one of the founding members of CNCF Deaf and Hard-of-Hearing Working Group (DHHWG). In this interview, Sandeep Kanabar , a deaf member of the DHHWG and part of the Kubernetes SIG ContribEx Communications team , sits down with Catherine to explore the impact of the DHHWG on cloud native projects like Kubernetes. Sandeep's journey is a testament to the power of inclusion. Through his involvement in the DHHWG, he connected with members of the Kubernetes community who encouraged him to join SIG ContribEx - the group responsible for sustaining the Kubernetes contributor experience. In an ecosystem where open-source projects are actively seeking contributors and maintainers, this story highlights how important it is to create pathways for underrepresented groups, including those with disabilities, to contribute their unique perspectives and skills. In this interview, we delve into Catherine's journey, the challenges and triumphs of establishing the DHHWG, and the vision for a more inclusive future in cloud native. We invite Kubernetes contributors, maintainers, and community members to reflect on the significance of empathy, advocacy, and community in fostering a truly inclusive environment for all, and to think about how they can support efforts to increase diversity and accessibility within their own projects. Introduction Sandeep Kanabar (SK): Hello Catherine, could you please introduce yourself, share your professional background, and explain your connection to the Kubernetes ecosystem? Catherine Paganini (CP): I'm the Head of Marketing at Buoyant , the creator of Linkerd , the CNCF-graduated service mesh, and 5th CNCF project. Four years ago, I started contributing to open source. The initial motivation was to make cloud native concepts more accessible to newbies and non-technical people. Without a technical backgrou

## Spotlight on SIG Scheduling

DevFeed: [Spotlight on SIG Scheduling](<https://devfeed.tech/articles/spotlight-on-sig-scheduling-17581.md>)

Original publisher: [Read original article](<https://www.kubernetes.dev/blog/2024/09/24/sig-scheduling-spotlight-2024/>)

Author: The Kubernetes Authors

Published: 2024-09-24T00:00:00Z

Content type: article

Language: en

Sources: [Kubernetes Contributors Blog](<https://devfeed.tech/sources/kubernetes-contributors-blog.md>)

Topics: [Kubernetes](<https://devfeed.tech/topics/kubernetes.md>), [Scalability](<https://devfeed.tech/topics/scalability.md>)

Tags: [kubernetes](<https://devfeed.tech/tags/kubernetes.md>), [scalability](<https://devfeed.tech/tags/scalability.md>)

### AI overview

An interview with Kensei Nakada, an approver in Kubernetes SIG Scheduling, covering the group's role in maintaining kube-scheduler and related components. It discusses recent improvements to PodTopologySpread, the QueueingHint enhancement for scheduling throughput, scalability challenges, and the kube-scheduler-wasm-extension subproject.

### Source excerpt

In this SIG Scheduling spotlight we talked with Kensei Nakada , an approver in SIG Scheduling. Introductions Arvind: Hello, thank you for the opportunity to learn more about SIG Scheduling! Would you like to introduce yourself and tell us a bit about your role, and how you got involved with Kubernetes? Kensei: Hi, thanks for the opportunity! I'm Kensei Nakada (@sanposhiho ), a software engineer at Tetrate.io . I have been contributing to Kubernetes in my free time for more than 3 years, and now I'm an approver of SIG Scheduling in Kubernetes. Also, I'm a founder/owner of two SIG subprojects, kube-scheduler-simulator and kube-scheduler-wasm-extension . About SIG Scheduling AP: That's awesome! You've been involved with the project since a long time. Can you provide a brief overview of SIG Scheduling and explain its role within the Kubernetes ecosystem? KN: As the name implies, our responsibility is to enhance scheduling within Kubernetes. Specifically, we develop the components that determine which Node is the best place for each Pod. In Kubernetes, our main focus is on maintaining the kube-scheduler , along with other scheduling-related components as part of our SIG subprojects. AP: I see, got it! That makes me curious-what recent innovations or developments has SIG Scheduling introduced to Kubernetes scheduling? KN: From a feature perspective, there have been several enhancements to PodTopologySpread recently. PodTopologySpread is a relatively new feature in the scheduler, and we are still in the process of gathering feedback and making improvements. Most recently, we have been focusing on a new internal enhancement called QueueingHint which aims to enhance scheduling throughput. Throughput is one of our crucial metrics in scheduling. Traditionally, we have primarily focused on optimizing the latency of each scheduling cycle. QueueingHint takes a different approach, optimizing when to retry scheduling, thereby reducing the likelihood of wasting scheduling cycles. A:

[Next page](<https://devfeed.tech/sources/kubernetes-contributors-blog.md?cursor=WyIyMDI0LTA5LTI0VDAwOjAwOjAwKzAwOjAwIiwgIjY1MWIzZmY1LWRlZmQtNDVkNi1iOTdiLTlmYjI2Y2UwNWNjMyJd>)