Container Service for Kubernetes:OSS persistent volume FAQ

Why does mounting an OSS volume fail?

Check the following causes in order:

Invalid AccessKey pair — Verify that the AccessKey pair configured in the secret is correct and has the necessary OSS permissions.

Inaccessible bucket endpoint — Make sure that the endpoint of the OSS bucket to be mounted is accessible.

Unsupported node OS — FlexVolume requires the node OS to be CentOS 7 or Alibaba Cloud Linux 2. If the node runs a different OS, download the latest version of ossfs manually onto the node, then delete the pod to trigger OSS volumes to remount.

Why does the mounted OSS directory become unavailable after a cluster upgrade?

When a cluster is upgraded, kubelet and the container network restart, which causes the OSSFS process to restart. This breaks the mapping between the host directory and the container directory.

Restart the container or recreate the pod to which the OSS volume is mounted. To automate recovery, configure the health check feature to restart containers or pods when this mapping becomes invalid.

For more information, see OSS volume overview.

Why does mounting an OSS volume take a long time?

If securityContext.fsgroup is set in the application template, kubelet performs chmod or chown after the volume is mounted, which increases the time consumption.

Use one of the following approaches to resolve this:

• Remove fsgroup: Delete the fsgroup parameter from the securityContext section if your application does not require specific file ownership or permissions.

• Set permissions before provisioning: Mount the OSS bucket to an Elastic Compute Service (ECS) instance, run chown and chmod via CLI to set the required permissions, then provision the OSS volume through the FlexVolume plug-in. For details, see Mount a statically provisioned OSS volume.

• Use OnRootMismatch (Kubernetes 1.20 or later): Set fsGroupChangePolicy to OnRootMismatch so that chmod and chown run only when the pod first starts, instead of on every mount:

  securityContext:
    fsGroup: 2000
    fsGroupChangePolicy: "OnRootMismatch"

  For more information, see Configure volume permission and ownership change policy for Pods.