Cross-Namespace Storage Data Sources in Kubernetes

Storage is frequently one of the most challenging and complicated Kubernetes resources for containerised applications. Thankfully, a cutting-edge functionality was added to Kubernetes v1.26 that enables you to declare a data source for a PersistentVolumeClaim even if the source data is located in a separate namespace. Cross-namespace storage data sources are a feature that offers a completely new method to handle storage in your Kubernetes cluster.

In this blog post, we’ll take a deeper dive into what cross-namespace storage data sources are and how you can use them to manage your storage resources more efficiently. We’ll also explore the advantages and disadvantages of using this feature, so you can make an informed decision about whether it’s right for your organisation.

What are Cross-Namespace Storage Data Sources in Kubernetes?

Cross-namespace storage data sources is a Kubernetes feature that allows you to specify a data source for a PersistentVolumeClaim (PVC) from another namespace. With this feature enabled, you can create a PersistentVolume (PV) in a namespace using data stored in another namespace. Before Kubernetes v1.26, users could only provision a PersistentVolume with a claim in one namespace from a data source in the same namespace. This feature allows for greater flexibility and scalability in the management of storage resources in Kubernetes.

How Can I Use It?

To use cross-namespace storage data sources, you need to enable the AnyVolumeDataSource and CrossNamespaceVolumeDataSource feature gates for the kube-apiserver and kube-controller-manager. You also need to install a CRD for the specific VolumeSnapShot controller and install the CSI Provisioner controller and enable the CrossNamespaceVolumeDataSource feature gate. Additionally, you need to install the CSI driver and a CRD for ReferenceGrants. Once all these components are installed and configured, you can create a PersistentVolumeClaim in a namespace using data stored in another namespace.

Here is an example manifest for creating a PersistentVolumeClaim using cross-namespace data sources:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: example-pvc
  namespace: dev
spec:
  storageClassName: example
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
  dataSourceRef:
    API group: snapshot.storage.k8s.io
    kind: VolumeSnapshot
    name: new-snapshot-demo
    namespace: prod
  volumeMode: Filesystem

In this example, we create a PVC in the “dev” namespace using a VolumeSnapshot named “new-snapshot-demo” stored in the “prod” namespace.

Advantages and Disadvantages:

The main advantage of cross-namespace storage data sources is the increased flexibility and scalability it provides in the management of storage resources in Kubernetes. This feature allows for the creation of PersistentVolumes using data stored in any namespace, which can be particularly useful in complex environments with multiple namespaces. Additionally, this feature enables more efficient use of storage resources, as data can be shared across namespaces.

The main disadvantage of cross-namespace storage data sources is that it requires several components to be installed and configured before they can be used. This can be time-consuming and complicated for users who are not familiar with Kubernetes. Additionally, this feature is still in alpha and may have limitations or bugs that have not yet been identified.

Conclusion:

Cross-namespace storage data sources are a powerful feature of Kubernetes that enables greater flexibility and scalability in the management of storage resources. With this feature enabled, you can create PersistentVolumes in any namespace using data stored in another namespace.

While this feature is still in alpha and requires several components to be installed and configured, it has the potential to greatly simplify the management of storage resources in Kubernetes. If you are interested in learning more about this feature or contributing to its development, we encourage you to join the Kubernetes Storage Special Interest Group (SIG).