I am however pleased that more people are considering using a traditional SAN (or SAN like service) for data persistence in containers as opposed to migrating actual data volumes.
[1] http://kubernetes.io/docs/user-guide/volumes/#awselasticbloc...
As to your specific comment about storage augmentation from vanila Kubernetes. We needed to run stateful DB type apps (Elasticsearch) which require persistent storage for each node in the cluster. This is doable in vanilla Kube, but requires a weird setup with multiple replication controllers. (The Kubernetes team is currently working to get past this limitation.) This can be time consuming and not very easy to understand for a user less experienced with Kubernetes. Our augmentation basically allows you to specify a Supergiant component (collection of services, RCs, and pods) with a volume blueprint. When you increase the number of instances of your component, (Elasticsearch cluster nodes.) the Supergiant API will take care of all the replication controllers, and volume mounts. Our work around volumes is less about being a huge feature, and more about our approach to fixing a tough concept in Kubernetes.