All Products
Search
Document Center

Container Service for Kubernetes:CSI storage FAQ

Last Updated:Mar 26, 2026

This page covers frequently asked questions about mounting and using persistent volumes with Container Storage Interface (CSI) components in Container Service for Kubernetes (ACK).

If a pod is in an abnormal state or a persistent volume fails to mount, see Troubleshoot storage issues for a full diagnostic workflow.

Typical issues

The following issues apply regardless of storage type.

Cloud disk persistent volumes

Type

Issue

Creation

Mounting

Usage

Expansion

Unmounting

Other

NAS persistent volumes

Category

Issue

Mounting

Usage

Unmounting

Unmount times out and pod is stuck in Terminating state

OSS persistent volumes

ossfs 1.0

Category

Issue

Mounting

Usage

Scaling

Do I need to scale out a volume when the actual storage capacity exceeds the volume's configuration?

Unmounting

Unmounting a statically provisioned OSS volume fails and the pod remains in the Terminating state

ossfs 2.0

Category

Issue

Mounting

Scaling

Do I need to scale out a volume when the actual storage capacity exceeds the volume's configuration?

Usage

How to restart the ossfs 2.0 process

Storage components

Category

Issue

Component issues

Component upgrade failures

CNFS

"IPAddress ... for Service ... has a wrong reference" event alert after an ACK cluster upgrade

Symptom

After upgrading the cluster, running kubectl get events -A returns continuous Warning events:

IPAddress: <IP_ADDRESS> for Service kube-system/cnfs-cache-ds-service has a wrong reference; cleaning up

This issue usually occurs in the following scenarios:

  1. The storage-operator component version in the cluster is earlier than v1.33.1.

  2. The cluster is upgraded from a version earlier than 1.33 to version 1.33 or later.

Cause

Versions of storage-operator earlier than v1.33.1 have a known issue where they continuously try to create an already-existing Service. In Kubernetes 1.33 and later, the MultiCIDRServiceAllocator feature is enabled by default. This repetitive creation behavior triggers the feature, causing the system to enter a loop of rapidly creating and deleting temporary IPAddress resources.

Solution

Upgrade the storage-operator component.

Why is kube-system/cnfs-cache-ds-service automatically recreated after I manually delete it?

Symptom

After manually deleting cnfs-cache-ds-service in the kube-system namespace, the deletion appears to succeed, but the service reappears shortly after.

Cause

The storage-operator component manages the desired state of cluster resources. Its reconciliation loop works as follows:

  1. Desired state: In the storage-operator ConfigMap, the installation status of cnfs-cache-ds-service is set to true.

  2. Continuous monitoring: The component continuously checks the cluster to confirm the service exists.

  3. Automatic reconciliation: When you delete the service, the controller detects the mismatch and immediately recreates it to match the desired state.

Solution

Option 1: Upgrade the storage-operator component (recommended)

See Upgrade the storage-operator component.

Option 2: Modify the storage-operator configuration (temporary)

This option prevents the cnfs-cache-ds service from being automatically recreated by updating the operator's desired state.

  1. Edit the storage-operator ConfigMap in the kube-system namespace.

    kubectl edit configmap storage-operator -n kube-system
  2. In the data field, locate cnfs-cache-ds and change the value of its install key from "true" to "false".

    cnfs-cache-ds:
      install: "false"
      # ...other configurations...
  3. Save the changes and exit the editor. The storage-operator applies the new configuration.

  4. Delete the service.

    kubectl delete service cnfs-cache-ds-service -n kube-system