OSS存储卷FAQ
本文为您介绍OSS存储卷常见问题的处理方法。
OSS存储卷挂载时间延长
问题现象
OSS存储卷挂载时间延长。
问题原因
同时满足以下配置，kubelet在存储卷挂载过程中将执行chmod或chown操作，导致挂载时间延长。
在PV及PVC模板中配置的参数AccessModes值为ReadWriteOnce。
在应用模板中配置了securityContext.fsgroup参数。
解决方案
若应用模板中配置了securityContext.fsgroup参数，请删除securityContext下的fsgroup参数。
若需要将挂载目录内文件变成期望的UID和mode，可以手动将Bucket挂载到一台ECS。关于如何将OSS挂载到ECS实例，请参见通过云存储网关挂载OSS。再通过命令行执行
chown和chmod，完成后通过CSI使用OSS存储卷。关于如何通过CSI使用OSS存储卷，请参见使用OSS静态存储卷。对于1.20及之后版本的Kubernetes集群，除了上述两种解决方法外，也可通过将fsGroupChangePolicy配置为OnRootMismatch，这时只有在首次启动时才会执行
chmod或chown操作，导致存在挂载时间延长的问题，后续挂载OSS存储卷时挂载时间将恢复正常。关于fsGroupChangePolicy参数的更多信息，请参见为Pod或容器配置安全性上下文。OSSFS PVC不建议做写操作，默认只读。
OSS存储挂载权限问题
问题现象
当您执行以下操作时，出现错误提示Permission Denied。
访问挂载目录。
访问通过ossutil、OSS控制台、SDK等其他方式上传的文件。
通过不同的容器进行读写操作时，读、写、运行其他容器创建的文件。
问题原因
OSS默认使用Linux的root用户进行挂载，权限为700。当容器进程以非root用户运行时，权限不足。
通过其他方式上传的文件在ossfs中默认权限为640。当容器进程以非root用户运行时，权限不足。
在ossfs中创建的普通文件默认权限为644。配置
securityConext中的fsGroup字段，或创建后chmod、chown文件，都可能导致权限或所有者的变更。当另一容器进程以其他用户操作文件时，可能权限不足。
解决方案
通过增加配置项修改挂载根目录权限。
参数
说明
allow_other
设置挂载目录的权限为777。
mp_umask
用于设定挂载目录的权限掩码，只有当
allow_other选项设置后，该选项才生效。默认值为000。例如，需设置挂载目录的权限为770，则增加
-o allow_other -omp_umask=007。需设置挂载目录的权限为700，则增加
-o allow_other -omp_umask=077。
以root角色chmod修改目标文件权限。或者通过以下配置项修改挂载目录下子目录及文件的权限。
umask：用于设定挂载目录下子目录及文件的权限掩码。使用方式与mp_umask类似，但无需依赖allow_other配置项。
umask只能修改当前ossfs中看到的文件的权限，再次挂载或对其他ossfs进程并不生效。例如，
配置
-o umask=022后，stat一个通过OSS控制台上传的文件，权限为755；取消-o umask=022配置项后再次挂载，权限仍为640。容器进程以root用户配置
-o umask=133后，通过chmod配置某文件权限为777，stat该文件权限仍为644；取消-o umask=133后再次挂载，权限变更为777。
stat目标文件的权限，若权限不足，请以root用户chmod修改目标文件权限。
以上方式均通过增加目录或文件的权限，解决当前容器进程用户权限不足的问题，您也可以通过修改ossfs挂载目录下子目录及文件所属用户来解决。
容器镜像构建时指定运行用户，或部署时应用模板的securityContext.runAsUser及securityContext.runAsGroup字段非空，都会使应用的容器进程以非root用户运行。
通过以下配置项修改ossfs挂载目录下子目录及文件的UID和GID，使其与容器进程用户一致。
参数 | 说明 |
uid | 指定挂载目录下子目录及文件归属用户的用户UID。 |
gid | 指定挂载目录下子目录及文件归属用户的用户GID。 |
例如，容器访问OSS的进程ID为uid=1000(biodocker)、gid=1001(biodocker)、groups=1001(biodocker)，则需配置-o uid=1000，-o gid=1001。
OSS静态卷挂载失败
问题现象
OSS静态卷挂载失败，Pod无法启动，Event提示FailedMount。
问题原因
原因1：静态卷目前不支持挂载到Bucket中不存在的目录中，原挂载目录不存在导致挂载失败。
原因2：若Event的内容中包含
Failed to find executable /usr/local/bin/ossfs: No such file or directory时，则挂载失败是因为OSSFS在节点上安装失败。
解决方案
原因1的解决方案
您需要更换OSS Bucket目录后重新进行OSS静态卷挂载。
登录OSS管理控制台。
创建Bucket存储空间。具体操作，请参见控制台创建存储空间。
重新进行OSS静态卷挂载。具体操作，请参见使用OSS静态存储卷。
原因2的解决方案
执行以下命令，尝试重启对应节点上的csi-plugin后，查看Pod是否能正常拉起。
以下代码中
csi-plugin-****为节点所在csi-plugin的Pod名称。kubectl -n kube-system delete pod csi-plugin-****登录节点，执行以下命令。
ls /etc/csi-tool部分预期输出：
... ossfs_<ossfsVer>_<ossfsArch>_x86_64.rpm ...若输出中存在OSSFS的RPM包，则执行以下命令，查看Pod是否能正常拉起。
rpm -i /etc/csi-tool/ossfs_<ossfsVer>_<ossfsArch>_x86_64.rpm若输出中不存在OSSFS的RPM包，请提交工单处理。
OSS静态卷访问Bucket失败
问题现象
OSS静态卷访问Bucket失败。
问题原因
使用OSS静态数据卷时，没有填写AK/SK信息。
解决方案
您需要填写AK/SK作为OSS静态卷访问Bucket的凭证。具体操作，请参见使用OSS静态存储卷。
OSS静态卷访问Bucket过慢
问题现象
OSS静态卷访问Bucket过慢。
问题原因
OSS对象存储本身没有文件数限制，但当文件数量大于1000时，会使OSS的FUSE访问元数据过多，导致Bucket访问过慢。
解决方案
容器内挂载OSS时，建议以只读的形式访问Bucket，针对大量平铺对象，可采用OSS SDK方式或CLI方式等非文件系统挂载方式，访问Bucket的数据。更多信息，请参见SDK示例简介。
OSS控制台看到文件大小为0
问题现象
容器内挂载OSS数据卷时，在文件中写入数据，但在OSS控制台看到文件大小为0。
问题原因
容器使用OSSFS挂载OSS，即基于FUSE方式挂载OSS的Bucket，只有文件执行close或者flush时，文件内容才会上传至OSS的服务端。
解决方案
使用lsof+文件名称的方式，查看当前文件是否被其他进程占用，关闭相应进程，释放文件fd。关于lsof更多信息，请参见Isof。
文件目录挂载后，显示为文件对象
问题现象
容器内挂载OSS数据卷时，文件原本是目录，挂载后，显示为文件对象。
问题原因
容器内挂载OSS数据卷，客户端从OSS服务端拉取文件元信息时，缺少元信息x-oss-meta-mode，导致目录被解析为文件。
解决方案
容器内挂载OSS数据卷时，您需要在OSS静态卷PV的otherOpts字段中增加-o complement_stat解决。