Clarification about Azure Container Storage

Question

Hello,

I'm testing the new Azure Container Service. The documentation mentions that the service orchestrates volumes using microservice-based storage controllers and emphasizes the benefits of using the service compared to the classic CSI. However, it seems that it's still utilizing CSI drivers.

kubectl get csidrivers.storage.k8s.io                                                    13:41:52
NAME                             ATTACHREQUIRED   PODINFOONMOUNT   STORAGECAPACITY   TOKENREQUESTS   REQUIRESREPUBLISH   MODES                  AGE
containerstorage.csi.azure.com   true             false            false             <unset>         false               Persistent             44h
disk.csi.azure.com               true             false            false             <unset>         false               Persistent             47h
file.csi.azure.com               false            true             false             <unset>         false               Persistent,Ephemeral   47h
san.csi.azure.com                true             false            false             <unset>         true                Persistent,Ephemeral   44h

Additionally, after I installed the extension and deployed a StoragePool resource using AzureDisk, I observed that it internally creates an OpenEBS DiskPool as well as a custom DiskPool resource. The DiskPool utilizes a pod with a specific image to manage its capacity.

$ kubectl get dsp -A                                                                                  
NAMESPACE   NAME        NODE                                STATUS   CAPACITY       USED        AVAILABLE      RESERVED
acstor      csi-zvpkp   aks-agentpool-25098983-vmss000003   Online   107321753600   782135296   106539618304   782135296

$  kubectl describe dsp -n acstor csi-zvpkp                                             
Name:         csi-zvpkp
Namespace:    acstor
Labels:       acstor.azure.com/diskpool=azuredisk-diskpool-dfjxv
              acstor.azure.com/managedby=capacity-provisioner
              acstor.azure.com/storagepool=azuredisk
              acstor.azure.com/worker=diskpool-worker-lnhsc
Annotations:  <none>
API Version:  openebs.io/v1alpha1
Kind:         DiskPool
Metadata:
  ...
  Owner References:
    API Version:           containerstorage.azure.com/v1alpha1
    Block Owner Deletion:  true
    Controller:            true
    Kind:                  DiskPool
    Name:                  azuredisk-diskpool-dfjxv
    UID:                   c82a20df-32ac-432b-b70a-f6a4bb9d30f3
  Resource Version:        994518
  UID:                     7032bf2a-5c38-4680-bbe0-65c984e00359
Spec:
  Disks:
    /dev/sdc
  Node:  aks-agentpool-25098983-vmss000003
...

Can you explain the relationships between these components and describe the general workflow? Moreover, since this service still utilizes CSI, what are the benefits of enabling the traditional CSI drivers in the cluster with the following command?

az aks update -n myAKSCluster -g myResourceGroup --enable-disk-driver --enable-file-driver --enable-blob-driver --enable-snapshot-controller

Answer 1

@Ivan Porta ,

Basically , when you run “kubectl get csidrivers.storage.k8s.io”, you see the file and disk csi drivers listed because those are enabled by default on AKS clusters. Additionally, when using Azure Container Storage with the Azure Disks storage type, the service leverages the Disk CSI driver.

In terms of using CSI drivers vs Azure Container Storage:

• Azure Container Storage in preview supports block storage read-write once storage types – Azure Disks, ephemeral disks, and Azure Elastic SAN. Ephemeral disks and Azure Elastic SAN aren’t currently supported via one of the existing CSI drivers, so they can only be leveraged via Azure Container Storage.
• If customer is interested in Azure Disks (which is both supported in Azure Container Storage and Disk CSI driver), our recommendation is to use Azure Container Storage, as it comes with additional benefits such as:
  • Lower total cost of ownership (TCO): Azure Container Storage allows for a larger number of volumes supported per pod or node, and it reduces the storage resources needed by dynamically sharing storage resources.
    • Rapid scale out and fast failover: Customers create a Storage Pool that maps to a backing storage type, and from there, it creates and mounts persistent volumes (PVs) over network block storage protocols (NVMe-oF or iSCSI) which offers a faster attach/detach of PVs.
• If a customer was interested in using Azure Files or in a read-write many scenario, since that is not currently supported via Azure Container Storage, our recommendation would be to leverage the Files or Blob CSI drivers.

As for the relationship between OpenEBS and Azure Container Storage, Azure Container Storage is derived from OpenEBS – an open-source solution that provides container storage capabilities.

Finally there is also a nice video with good amount of explanation!

https://www.youtube.com/watch?v=mXH7FUIfoMs

Kindly let me know if you have any additional questions ! Happy to help out.

Regards,

Shiva.