Home > Storage > PowerMax and VMAX > Storage Admin > Persistent Storage for Containerized Applications on Kubernetes with PowerMax SAN Storage > Why use SAN storage with Kubernetes
The CSI Driver for PowerMax and other drivers offer a native integration between Kubernetes and the back-end storage. All the tasks related to the storage provisioning of a Persistent Volume and back-end block device are delegated to PersistentVolumeClaim from the Pod definition for the application. With a shared storage solution such as SAN, you can ensure that the persistent volume will be accessible from any node of the infrastructure, allowing for workload mobility across the Kubernetes cluster. The SAN allows organic consumption of the storage within Kubernetes, as it does with VMware infrastructure and other compute platforms.
Moreover, by using or reusing SAN storage, you can immediately take advantage of your investment in materials and processes. It is possible to create a portfolio of Storage Classes, as described in Storage Class, with the service level you defined (type of storage, type of replication, type of backup, and so on).
SAN and shared storage offer rich data services for data protection such as LUN-level snapshots, remote replication, and disaster recovery integration with industry-standard tools such as VMware Site Recovery Manager. When migrating a legacy application to a container-based deployment, you can ensure continuity of these services while modernizing your applications.
Even for cloud-native applications with modern data store platforms like Elasticsearch, Cassandra, and Couchbase, using SAN infrastructure can cut down on the compute resources required for replication and take advantage of the mature data services of platforms like Dell PowerMax. The SAN advantage becomes more evident as the size of the data stores grows.