Workflow steps run in isolated Pods that don't share a filesystem by default. Mount a volume to let steps read and write shared data — one step writes a file, the next reads it — without embedding data in container images or passing it through parameters.
This topic covers statically provisioned volumes: you create PersistentVolume (PV) and PersistentVolumeClaim (PVC) resources manually, then reference them in a Workflow. Supported storage types are Object Storage Service (OSS), Apsara File Storage NAS (NAS), and Cloud Parallel File Storage (CPFS) 2.0.
When to use volumes
Mount a volume when your workflow needs to:
Pass artifacts between steps — one step writes a file to the volume; a later step reads it.
Cache build artifacts — reuse intermediate outputs across workflow runs.
Store logs — write structured log files that persist after the Pod terminates.
Share read-only config or media — make configuration files or media assets available to multiple steps simultaneously.
Choose a storage type
| Storage type | Best for | Access mode |
|---|---|---|
| OSS | Sharing unstructured data (images, audio, video) and read-only config files across Pods; data survives Pod deletion | ReadWriteMany |
| NAS | Data sharing, big data analytics (high throughput), web applications, and log storage | ReadWriteMany |
| CPFS 2.0 | High-performance workloads such as genomic computing and big data analytics; staging data from slower storage tiers as a high-speed cache | ReadWriteOnce |
For additional guidance, see OSS volumes, NAS volumes, and CPFS volumes.
Use OSS volumes
Step 1: Create the PV and PVC
Apply the following YAML to create a Secret for your credentials, a PersistentVolume (PV) backed by OSS, and a PersistentVolumeClaim (PVC) that binds to it.
For detailed configuration options, see Use an ossfs 1.0 statically provisioned volume.
apiVersion: v1
kind: Secret
metadata:
name: oss-secret
namespace: argo
stringData:
akId: <your-access-key-id> # Replace with your AccessKey ID
akSecret: <your-access-key-secret> # Replace with your AccessKey Secret
---
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv-oss
namespace: argo
labels:
alicloud-pvname: pv-oss # Used by the PVC selector below
spec:
capacity:
storage: 5Gi
accessModes:
- ReadWriteMany # Multiple Pods can mount this volume simultaneously
persistentVolumeReclaimPolicy: Retain
csi:
driver: ossplugin.csi.alibabacloud.com
volumeHandle: pv-oss # Must match the PV name above
nodePublishSecretRef:
name: oss-secret
namespace: argo
volumeAttributes:
bucket: <your-bucket-name> # Replace with your OSS bucket name
url: "oss-<your-region-id>-internal.aliyuncs.com" # Internal endpoint, e.g. oss-cn-beijing-internal.aliyuncs.com
otherOpts: "-o max_stat_cache_size=0 -o allow_other -o multipart_size=30 -o parallel_count=20"
path: "/" # Mount the bucket root; use a subdirectory path such as "testdir/testdir1" to scope access
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pvc-oss
namespace: argo
spec:
accessModes:
- ReadWriteMany
resources:
requests:
storage: 5Gi
selector:
matchLabels:
alicloud-pvname: pv-oss # Binds this PVC to the pv-oss PVOptional ossfs parameters
Configure additional mount options using the -o <param> format in otherOpts, for example: -o umask=022 -o max_stat_cache_size=0 -o allow_other.
| Parameter | Description |
|---|---|
umask | Sets file permissions for ossfs. For example, umask=022 changes permissions to 755. Files uploaded through the OSS console, SDK, or ossutil have a default permission of 640 in ossfs — set umask when you need to split read and write permissions. |
max_stat_cache_size | Maximum number of files with cached metadata. Caching speeds up ls operations, but the cache is not updated when files are modified through the OSS console, SDK, or ossutil, which can cause ls to return stale results. |
allow_other | Allows other users to access the mounted directory (but not the files inside). |
For all available parameters, see Mount options.
Step 2: Create a workflow that uses the OSS volume
Apply the following YAML to run a two-step workflow. The first step writes a file to the volume; the second step reads it back.
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
generateName: volumes-existing-
namespace: argo
spec:
entrypoint: volumes-existing-example
volumes:
# Reference the PVC created in Step 1.
# The syntax follows Kubernetes Pod spec.
- name: workdir
persistentVolumeClaim:
claimName: pvc-oss
templates:
- name: volumes-existing-example
steps:
- - name: generate
template: whalesay
- - name: print
template: print-message
- name: whalesay
container:
image: mirrors-ssl.aliyuncs.com/busybox:latest
command: [sh, -c]
args: ["echo generating message in volume; echo hello world | tee /mnt/vol/hello_world.txt"]
volumeMounts:
- name: workdir
mountPath: /mnt/vol
- name: print-message
container:
image: mirrors-ssl.aliyuncs.com/alpine:latest
command: [sh, -c]
args: ["echo getting message from volume; find /mnt/vol; cat /mnt/vol/hello_world.txt"]
volumeMounts:
- name: workdir
mountPath: /mnt/volUse NAS volumes
Step 1: Create the PV and PVC
Apply the following YAML to create a PersistentVolume (PV) backed by NAS and a PersistentVolumeClaim (PVC) that binds to it.
For detailed configuration options, see Mount a statically provisioned NAS volume.
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv-nas
namespace: argo
labels:
alicloud-pvname: pv-nas # Used by the PVC selector below
spec:
capacity:
storage: 100Gi
accessModes:
- ReadWriteMany # Multiple Pods can mount this volume simultaneously
csi:
driver: nasplugin.csi.alibabacloud.com
volumeHandle: pv-nas # Must match the PV name above
volumeAttributes:
server: "<your-nas-filesystem-id>.cn-beijing.nas.aliyuncs.com" # Replace with your NAS mount target address
path: "/" # Mount the root of the NAS file system
mountOptions:
- nolock,tcp,noresvport
- vers=3
---
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: pvc-nas
namespace: argo
spec:
accessModes:
- ReadWriteMany
resources:
requests:
storage: 100Gi
selector:
matchLabels:
alicloud-pvname: pv-nas # Binds this PVC to the pv-nas PVStep 2: Create a workflow that uses the NAS volume
Apply the following YAML to run a two-step workflow that writes and reads a file through the NAS volume.
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
generateName: volumes-existing-
namespace: argo
spec:
entrypoint: volumes-existing-example
volumes:
# Reference the PVC created in Step 1.
# The syntax follows Kubernetes Pod spec.
- name: workdir
persistentVolumeClaim:
claimName: pvc-nas
templates:
- name: volumes-existing-example
steps:
- - name: generate
template: whalesay
- - name: print
template: print-message
- name: whalesay
container:
image: mirrors-ssl.aliyuncs.com/busybox:latest
command: [sh, -c]
args: ["echo generating message in volume; echo hello world | tee /mnt/vol/hello_world.txt"]
volumeMounts:
- name: workdir
mountPath: /mnt/vol
- name: print-message
container:
image: mirrors-ssl.aliyuncs.com/alpine:latest
command: [sh, -c]
args: ["echo getting message from volume; find /mnt/vol; cat /mnt/vol/hello_world.txt"]
volumeMounts:
- name: workdir
mountPath: /mnt/volUse CPFS 2.0 volumes
Step 1: Create the PV and PVC
Run the following command to create a PersistentVolume (PV) backed by CPFS 2.0 and a PersistentVolumeClaim (PVC) that binds to it.
For detailed configuration options, see CPFS 2.0 static volumes.
cat << EOF | kubectl apply -f -
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv-cpfs
namespace: argo
labels:
alicloud-pvname: pv-cpfs # Used by the PVC selector below
spec:
accessModes:
- ReadWriteOnce # Only one Pod can mount this volume at a time
capacity:
storage: 1000Gi
csi:
driver: nasplugin.csi.alibabacloud.com
volumeAttributes:
mountProtocol: cpfs-nfs # Use the NFS protocol to mount the CPFS file system
path: "/share" # The mount path must start with /share
volumeAs: subpath
server: "<your-cpfs-id>.<region-id>.cpfs.aliyuncs.com" # Replace with your CPFS mount target, e.g. cpfs-****.cn-hangzhou.cpfs.aliyuncs.com
volumeHandle: pv-cpfs # Must match the PV name above
mountOptions:
- rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport
- vers=3
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pvc-cpfs
namespace: argo
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 1000Gi
selector:
matchLabels:
alicloud-pvname: pv-cpfs # Binds this PVC to the pv-cpfs PV
EOFStep 2: Create a workflow that uses the CPFS 2.0 volume
Apply the following YAML to run a two-step workflow that writes and reads a file through the CPFS 2.0 volume.
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
generateName: volumes-existing-
namespace: argo
spec:
entrypoint: volumes-existing-example
volumes:
# Reference the PVC created in Step 1.
# The syntax follows Kubernetes Pod spec.
- name: workdir
persistentVolumeClaim:
claimName: pvc-cpfs
templates:
- name: volumes-existing-example
steps:
- - name: generate
template: whalesay
- - name: print
template: print-message
- name: whalesay
container:
image: mirrors-ssl.aliyuncs.com/busybox:latest
command: [sh, -c]
args: ["echo generating message in volume; echo hello world | tee /mnt/vol/hello_world.txt"]
volumeMounts:
- name: workdir
mountPath: /mnt/vol
- name: print-message
container:
image: mirrors-ssl.aliyuncs.com/alpine:latest
command: [sh, -c]
args: ["echo getting message from volume; find /mnt/vol; cat /mnt/vol/hello_world.txt"]
volumeMounts:
- name: workdir
mountPath: /mnt/vol