阿里云容器服务ACKOSS存储卷FAQ-云淘科技

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 -o mp_umask=007。 需设置挂载目录的权限为700，则增加-o allow_other -o mp_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，使其与容器进程用户一致。

例如，容器访问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在节点上安装失败。

• 原因3：Bucket配置了镜像回源，挂载目录未从源站同步。

解决方案

• 原因1解决方案：

  您可以通过ossutil、SDK、OSS控制台等工具手动创建缺失的Bucket或子目录，然后重建PV。

• 原因2解决方案：

  1. 建议您将csi-plugin版本升级到v1.26.2或以上版本，该版本修复了刚扩容出的节点初始化时，ossfs安装失败的问题。

  2. 执行以下命令，尝试重启对应节点上的csi-plugin后，查看Pod是否能正常启动。以下代码中csi-plugin-****为节点所在csi-plugin的Pod名称。

     kubectl -n kube-system delete pod csi-plugin-****

  3. 若升级或重启组件后，问题仍无法解决，请登录节点，执行以下命令。

     ls /etc/csi-tool

     部分预期输出：

     ... ossfs___x86_64.rpm ...

     • 若输出中存在OSSFS的RPM包，则执行以下命令，查看Pod是否能正常启动。

       rpm -i /etc/csi-tool/ossfs___x86_64.rpm

     • 若输出中不存在OSSFS的RPM包，请提交工单处理。

• 原因3解决方案：

  您需要同步源站数据后，再进行挂载。更多信息，请参见回源概述。

OSS静态卷访问Bucket失败

问题现象

OSS静态卷访问Bucket失败。

问题原因

使用OSS静态数据卷时，没有填写AK/SK信息。

解决方案

您需要填写AK/SK作为OSS静态卷访问Bucket的凭证。具体操作，请参见使用OSS静态存储卷。

OSS静态卷访问Bucket过慢

问题现象

OSS静态卷访问Bucket过慢。

问题原因

• 原因1：OSS对象存储本身没有文件数限制，但当文件数量大于1000时，会使OSS的FUSE访问元数据过多，导致Bucket访问过慢。

• 原因2：OSS开启版本控制后，当Bucket中存在大量删除标记时，listObjectsV1性能下降。

解决方案

原因1解决方案：

容器内挂载OSS时，建议以只读的形式访问Bucket，针对大量平铺对象，可采用OSS SDK方式或CLI方式等非文件系统挂载方式，访问Bucket的数据。更多信息，请参见SDK示例简介。

原因2解决方案：

1. 将CSI plugin组件版本升级至v1.26.6后，ossfs可支持通过listObjectsV2访问Bucket。

   说明

   CSI plugin组件的v1.26.6版本处于灰度发布中，如需使用，请提交工单申请加入白名单。

2. 在OSS静态卷PV的otherOpts字段中增加-o listobjectsv2解决。

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解决。

说明

• CSI plugin组件版本为v1.26.6及以上版本时，配置项已默认开启，您可以将存储组件升级至v1.26.6或以上版本，重启业务Pod并重新挂载OSS静态卷解决。

• CSI plugin组件的v1.26.6版本处于灰度发布中，如需使用，请提交工单申请加入白名单。

OSS服务端监控到大量异常请求流量

问题现象

在容器内挂载OSS数据卷时，OSS服务端监控到请求数量远超出业务预期产生量。

问题原因

通过ossfs挂载OSS对象存储时，将在节点上产生挂载路径，ECS上的其他进程对挂载点的扫描也会转换为向OSS的请求。如果请求次数很多，会产生费用。

解决方案

通过审计追踪产生请求的进程，并进行相应修复。您可以在节点上进行如下操作。

1. 执行以下命令，安装auditd并启动。

   sudo yum install auditd
   sudo service auditd start

2. 将对ossfs挂载路径设为监测目录。

   • 如需添加所有挂载路径，请执行以下命令。

     for i in $(mount | grep -i ossfs | awk '{print $3}');do auditctl -w ${i};done

   • 如需添加某个PV的挂载路径，请执行以下命令。其中，为指定的PV名称。

     for i in $(mount | grep -i ossfs | grep -i  | awk '{print $3}');do auditctl -w ${i};done

3. 通过以下命令，在auditlog中查看存在哪些进程访问了OSS Bucket中的路径。

   ausearch -i 

   审计日志分析示例如下。以下示例中，---分隔符间的审计日志为一组，记录对监控挂载点的单次操作。该示例表示updatedb进程对挂载点中的子目录进行了open的操作，进程PID为1636611。

   ---
   type=PROCTITLE msg=audit(2023年09月22日 15:09:26.244:291) : proctitle=updatedb
   type=PATH msg=audit(2023年09月22日 15:09:26.244:291) : item=0 name=. inode=14 dev=00:153 mode=dir,755 ouid=root ogid=root rdev=00:00 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0
   type=CWD msg=audit(2023年09月22日 15:09:26.244:291) : cwd=/subdir1/subdir2
   type=SYSCALL msg=audit(2023年09月22日 15:09:26.244:291) : arch=x86_64 syscall=open success=yes exit=9 a0=0x55f9f59da74e a1=O_RDONLY|O_DIRECTORY|O_NOATIME a2=0x7fff78c34f40 a3=0x0 items=1 ppid=1581119 pid=1636611 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts1 ses=1355 comm=updatedb exe=/usr/bin/updatedb key=(null)
   ---

4. 借助日志进一步确认是否存在非业务的进程调用，并进行修复。

   例如，通过auditlog查到updatedb扫描了所挂载的目录，可以通过修改/etc/updatedb.conf让它跳过。具体操作如下。

   1. 在RUNEFS =后面加上fuse.ossfs。

   2. 在PRUNEPATHS =后面加上挂载的目录。

控制台检测长期卡住，或失败无信息透出，或显示unknown error

问题现象

检测长期卡住，或失败无信息透出，或显示unknown error。

问题原因

若检测长期卡在进行中状态，基本判断为网络原因。对于其他未知错误，您可以通过如下查询日志及手动通过ossutil进行原因定位。

解决方案

您可以通过日志和ossutil工具定位具体问题。

ossutil -e "" -i "" -k "" stat oss://""

ossutil -e "oss--internal.aliyuncs.com" -i "" -k "" stat oss://"cnfs-oss-xxx-xxx/xx/"

网络问题：connection timed out

问题现象

错误信息为connection timed out。

问题原因

访问OSS Bucket超时，可能的超时原因如下

• 选择的Bucket与集群不在同一地域时，选择私有域名，导致访问不通。

• 选择公有域名，但集群无公网访问能力，导致访问不通。

解决方案

• 重建PV，并选择公有域名。

• 若您的集群与Bucket在同一地域，可重建PV并选择私有域名。否则，您可以检查安全组、网络等相关配置，修复后再重建PV。

权限问题：错误码StatusCode=403

问题现象

错误信息为service returned error: StatusCode=403。

问题原因

挂载OSS存储卷时，AccessKey至少需要Bucket的读权限，当前权限不足。

• StatusCode=403, ErrorCode=AccessDenied, ErrorMessage="You do not have read acl permission on this object." ，提供的AccessKey权限不足。

• StatusCode=403, ErrorCode=InvalidAccessKeyId, ErrorMessage="The OSS Access Key Id you provided does not exist in our records." ，提供的AccessKey不存在。

• StatusCode=403, ErrorCode=SignatureDoesNotMatch, ErrorMessage="The request signature we calculated does not match the signature you provided. Check your key and signing method." ，提供的AccessKey可能存在拼写错误。

解决方案

确认AccessKey已存在、无拼写错误，且至少拥有对该Bucket的读权限。

Bucket或目录对象不存在：错误码StatusCode=404

问题现象

错误信息为service returned error: StatusCode=404。

问题原因

OSS静态存储卷不支持挂载到不存在的Bucket或子目录中，需要预先手动创建Bucket。

• StatusCode=404, ErrorCode=NoSuchBucket, ErrorMessage="The specified bucket does not exist."，选择的Bucket不存在。

• StatusCode=404, ErrorCode=NoSuchKey, ErrorMessage="The specified key does not exist."，选择的子目录对象不存在。

  重要

  OSS控制台中可见的子路径在Server端不一定真实存在。例如，直接创建/a/b/c/目录，/a/b/c/为单独的目录对象，而/a/或/a/b/目录对象实际并不存在。同理，如上传/a/*文件，/a/b、/a/c等为单独的文件对象，/a/目录对象不存在。

解决方案

通过ossutil、SDK、OSS控制台等工具手动创建缺失的Bucket或子目录，然后重建PV。

其他OSS返回错误码

问题现象

错误信息为service returned error: StatusCode=xxx。

问题原因

当访问OSS出现错误时，OSS会返回StatusCode、ErrorCode、ErrorMessage等信息，方便您定位并解决问题。

解决方案

当您遇到其他OSS的StatusCode或ErrorCode时，请参见HTTP错误码解决。