This topic provides answers to some frequently asked questions about Object Storage Service (OSS) volumes.
Why do I fail to mount an OSS volume?
Your attempt to mount an OSS volume failed.
- The AccessKey pair that you used is invalid.
- The endpoint of the OSS bucket to be mounted is inaccessible.
- Use a valid AccessKey pair.
- Make sure that the endpoint of the OSS bucket to be mounted is accessible.
Why does the directory in an OSS volume that is mounted to a container become unavailable after the cluster that runs the pod is upgraded?
The directory in an OSS volume that is mounted to a container becomes unavailable after the cluster that runs the pod is upgraded.
After the cluster is upgraded, kubelet and the container network are restarted, which cause the OSSFS process to restart. As a result, the mapping between the host and the container directory becomes invalid.
Restart the container or recreate the pod to which the OSS volume is mounted. You can configure the health check feature to automate the restart of containers or pods.
For more information about how to use OSS, see OSS volume overview.
Why does it require a long time to mount an OSS volume?
It requires a long time to mount an OSS volume.
If the securityContext.fsgroup parameter is set in the application template, kubelet performs the
chown operation after the volume is mounted, which increases the time consumption.
- If the securityContext.fsgroup parameter is set in the application template, delete the fsgroup parameter in the securityContext section.
- If you want to configure the user ID (UID) and mode of the files in the mounted directory, you can manually mount the OSS bucket to an
Elastic Compute Service (ECS) instance. You can then perform
chmodoperations through a CLI and provision the OSS volume through the FlexVolume plug-in. For more information about how to provision OSS volumes through FlexVolume, see Mount a statically provisioned OSS volume.
- For clusters of Kubernetes 1.20 or later, you can set the fsGroupChangePolicy parameter to OnRootMismatch. This way, the
chownoperation is performed only when the pod that uses the volume is first started. For more information, see Set the security context for a container.