mongona

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 h

eaded 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 w

as 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 w

e 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 from the DP WG designed to support efficient backups. About SIG Storage For

folks who are new: what is SIG Storage, in your own words? What problems in Kubernetes are you trying to solve? SIG Storage is a Special Interest Group focused on how to provide storage to containers running in your Kubernetes cluster. We define standard interfaces so that a storage vendor can write a driver and have its underlying storage system consumed by containers in Kubernetes. Why does Kubernetes need a dedicated storage SIG? What makes storage hard in a distributed system? When Kubernetes was first introduc

ed, it was meant for stateless workloads only. Container applications were regarded as ephemeral and therefore did not need to persist data. However, that changed drastically. Stateful workloads started running in Kubernetes, and we needed a dedicated SIG to tackle the associated storage challenges. PersistentVolumeClaims, PersistentVolumes, and StorageClasses were all introduced to provision data volumes for applications running in Kubernetes. How did SIG Storage originally form, and how has its mission changed ov

er time? SIG Storage was formed to address the challenges of handling persistent data within Kubernetes. Initially, PersistentVolumes were implemented as in-tree plugins, and the SIG managed those plugins while developing core storage primitives like PersistentVolumes and PersistentVolumeClaims. Container Storage Interface (CSI) was introduced later and played a crucial role in simplifying storage integration, enabling third-party storage providers to develop and maintain their own out-of-tree plugins without modif

ying Kubernetes core code. With basic integration addressed by CSI, the SIG's mission expanded to include advanced storage features that leverage the new interface. The SIG has also expanded its scope to support object storage through the Container Object Storage Interface (COSI). Current work and roadmap What are the top features SIG Storage is actively working on right now? The Data Protection WG has been working on a couple of exciting features: VolumeGroupSnapshot is a Kubernetes feature enabling a crash-consis

tent, point-in-time snapshot of multiple PersistentVolumes simultaneously. This ensures data integrity for applications — like databases — that rely on multiple volumes by capturing all volumes in the group atomically, at the exact same point in time. It just moved to GA in Kubernetes v1.36. CSI Changed Block Tracking (CBT) enables efficient, incremental backups. By allowing storage systems to report only the blocks that have changed since the last snapshot, it significantly reduces the amount of data that needs to

be transferred. It just moved to Beta in Kubernetes v1.36. Another feature worth highlighting is Container Object Storage Interface (COSI) . COSI provides a standard interface for provisioning and consuming object storage buckets in Kubernetes — standardizing object storage for containerized applications much like CSI did for block and file storage. COSI is now transitioning to v1alpha2 , with plans for promotion to Beta in a future release. What recent work from SIG Storage do you consider a "win" for users? The g

raduation of VolumeAttributesClass to GA in Kubernetes v1.34 is a major win for users managing stateful workloads. Previously, changing volume attributes like IOPS or throughput required out-of-band actions or disruptive operations. Now, users can dynamically tune storage properties such as IOPS or throughput directly through the Kubernetes API — scaling up for peak loads or down to optimize costs — without external processes or downtime. VolumeAttributesClass enables dynamic modification of storage characteristics

without recreating the volume. This completes the picture by allowing users to tune both capacity and other storage properties dynamically, just as they can now tune both CPU and memory for compute. Looking ahead one or two releases, what's on the roadmap that people should wat...