alibaba-cloud-csi-driver: four storage backends behind one CSI interface

What the driver does, and the warning to read first

The Alibaba Cloud CSI Driver implements the Container Storage Interface specification, which lets container orchestrators such as Kubernetes manage the full lifecycle of Alibaba Cloud storage volumes, covering dynamic provisioning, attaching, mounting, resizing and snapshotting. There is a warning at the top of the project overview and it is not boilerplate. Deploying this driver to your ACK cluster manually is not recommended, and users should instead use ACK add-ons to automatically deploy and manage the driver. Manual deployment of the driver in your ACK cluster is not officially supported by Alibaba Cloud. The project lives in the kubernetes-sigs organisation, which is the right place for a storage driver that has to work with upstream Kubernetes, and the last push to the repository was on 2026-10-20 with release v1.37.3 tagged on 2026-10-08.

Four backends, and they are not interchangeable

The supported storage table gives each backend a CSI name, a type, access modes and whether dynamic provisioning works, and the differences matter more than the similarities. Cloud Disk is registered as diskplugin.csi.alibabacloud.com and is block storage usable by one workload at a time with ReadWriteOnce, attached to a single node at a time, and it supports snapshots, expansion, topology-aware scheduling, raw block volumes and local-disk data caching for acceleration. NAS is nasplugin.csi.alibabacloud.com, a shared network file system compatible with NFS and SMB, mountable from many nodes at once with ReadWriteMany, and CPFS 2.0 is now served through it. OSS is ossplugin.csi.alibabacloud.com, mounting object-storage buckets into pods with ReadWriteMany, but it does not provision buckets, it mounts them. BMCPFS is bmcpfsplugin.csi.alibabacloud.com, a high-performance parallel file system for high-I/O workloads with ReadWriteMany, supporting static provisioning only because the file system must be pre-created in Alibaba Cloud, with both VSC high performance Lingjun and VPC networking supported.

The CPFS plugin was removed, and the project says so

One line in the project overview is worth reading twice because it describes a removal rather than a feature. The CPFS CSI Plugin has been removed, and the guidance is to use the NAS CSI plugin for CPFS 2.0. That is a consolidation rather than a deletion of capability, since the earlier note already said CPFS 2.0 is served through the NAS CSI plugin, so the dedicated plugin had become redundant. It is also a good example of why a driver project has to be read rather than assumed, because a deployment that references the old plugin name will simply stop resolving. The four CSI names are the stable interface here, and if you are pinning anything in your manifests, pin the name and check the table in the current revision.

The feature matrix tells you the version floor

A short feature matrix sets out which capability became generally available, the minimum Kubernetes version and the minimum driver version. Topology is generally available from Kubernetes 1.17 with driver v1.0.2. Resize, called Expand, is generally available from Kubernetes 1.16 with driver v1.0.5. Snapshots are generally available from Kubernetes 1.20 with driver v1.1.2. That table is the practical way to decide whether an old cluster can run a recent driver, and it is a reminder that a CSI driver is a compatibility surface as much as a piece of software. The current implementation has been tested against Kubernetes 1.14 and newer, while manual deployment via Helm requires Kubernetes 1.26 or newer, so a cluster on 1.20 could in principle run the driver but would not pass the Helm requirement for manual deployment.

Prerequisites, RAM and where the install guide lives

The getting started section lists the prerequisites. You need kubectl configured to communicate with the cluster, Helm 3, and RAM permissions for the driver to invoke Alibaba Cloud OpenAPIs on your behalf, with example policies linked in the documentation, and individual drivers may have additional requirements, which the documentation directory covers. The installation guide is where deployment options, RAM setup, configuration presets and verification steps are described. The RAM point deserves emphasis. A CSI driver is a component in your cluster that makes cloud API calls on your behalf, so the identity it uses is part of your security boundary, and the example policies are there so that the permissions can be scoped rather than granted broadly. The project also carries a Chinese-language readme, a changelog for the early 1.0.x line, a VERSIONS file, an embargo policy and example directories for customfuse, disk, nas and oss.

Building and testing it as a developer

The development section covers the container image and the checks. Container images are built with a make target.

make build

The test targets cover formatting, vetting, linting and unit tests, plus an end-to-end Helm install against a kind cluster.

make fmt      # check formatting
make vet      # go vet
make lint     # golangci-lint
make test     # unit tests

# End-to-end Helm install against a kind cluster
make check-helm-kind

Each of those targets delegates to a script under hack/, so the checks are shell scripts rather than Go tooling, and the Makefile pins the tool versions it downloads, with a Helm version and a Syft version fetched into a local bin directory at the right platform. Syft is used by the Dockerfile update targets, which scan the base image for packages so the shipped image dependencies can be tracked, and there is a check that diffs the generated file to catch drift in a pull request.

The dependency list explains what the driver talks to

The go.mod file is a map of the driver's external surface. On the Alibaba Cloud side there are generated SDK clients for disk through the ecs-20140526 API, for NAS through nas-20170626, for the elastic network service ens-20171110, for the eflo controller and for STS, plus the older alibaba-cloud-sdk-go package and the credentials-go library, and a Darabonba OpenAPI client in two versions. On the Kubernetes side the driver sits on the container-storage-interface spec at version 1.13.0, the csi-lib-utils helper library, the external-snapshotter client at version 8, and the usual k8s.io libraries at v0.37.1. Notably it depends on go-ping for reachability checks, on google/nftables, and on containerd/ttrpc for the node service. The go.mod also declares a mockgen tool dependency and targets go 1.26.0, and the repository vendors its dependencies.

Editorial conclusion

alibaba-cloud-csi-driver fits a team running Kubernetes on Alibaba Cloud that needs block storage, shared NFS or SMB filesystems, and object storage mounted into pods, behind a single CSI interface with the volume lifecycle managed by the orchestrator. It does not fit an ACK user who plans to install it by hand, because the project states that manual deployment is not officially supported by Alibaba Cloud and that you should use the ACK add-ons instead. It also does not fit a team that expects uniform dynamic provisioning across backends, because OSS is bucket mount only and BMCPFS is static provisioning only. Before deploying manually, read the install guide, work out the RAM permissions the driver needs to call the Alibaba Cloud OpenAPIs, and check the feature matrix for the minimum Kubernetes and driver versions your cluster needs.

Frequently asked questions

Official sources

1. Issues
2. kubernetes-sigs/alibaba-cloud-csi-driver on GitHub
3. License: Apache-2.0
4. README
5. Releases