容器服务 Kubernetes 版 ACK：OSS存储卷FAQ

OSS存储卷挂载时间延长

问题现象

OSS存储卷挂载时间延长。

问题原因

同时满足以下配置，kubelet在存储卷挂载过程中将执行chmod或chown操作，导致挂载时间延长。

• 在PV及PVC模板中配置的参数AccessModes值为ReadWriteOnce。

• 在应用模板中配置了securityContext.fsgroup参数。

解决方案

• 若应用模板中配置了securityContext.fsgroup参数，请删除securityContext下的fsgroup参数。

• 若需要将挂载目录内文件变成期望的UID和mode，可以手动将Bucket挂载到一台ECS。再通过命令行执行chown和chmod，完成后通过CSI使用OSS存储卷。关于如何通过CSI使用OSS存储卷，请参见使用OSS静态存储卷。

• 对于1.20及之后版本的Kubernetes集群，除了上述两种解决方法外，也可通过将fsGroupChangePolicy配置为OnRootMismatch，这时只有在首次启动时才会执行chmod或chown操作，导致存在挂载时间延长的问题，后续挂载OSS存储卷时挂载时间将恢复正常。关于fsGroupChangePolicy参数的更多信息，请参见为Pod或容器配置安全性上下文。

• ossfs PVC不建议进行写操作，默认只读。

OSS存储挂载权限问题

问题现象

当您执行以下操作时，出现错误提示Permission Denied。

• 场景1：访问挂载目录。

• 场景2：访问通过ossutil、OSS控制台、SDK等其他方式上传的文件。

• 场景3：通过不同的容器进行读写操作时，读、写、运行其他容器创建的文件。

• 场景4：OSS挂载时使用Secret记录AccessKey信息，并在PV中通过nodePublishSecretRef字段指定Secret。因为AK轮转等原因撤销了原AK，Secret中AccessKey信息修改后不生效。

• 场景5：硬链接操作时，返回Operation not permitted。

问题原因

• 场景1原因：OSS默认使用Linux的root用户进行挂载，权限为700。当容器进程以非root用户运行时，权限不足。

• 场景2原因：通过其他方式上传的文件在ossfs中默认权限为640。当容器进程以非root用户运行时，权限不足。

• 场景3原因：在ossfs中创建的普通文件默认权限为644。配置securityContext中的fsGroup字段，或创建后chmod、chown文件，都可能导致权限或所有者的变更。当另一容器进程以其他用户操作文件时，可能权限不足。

• 场景4原因：OSS数据卷是使用ossfs文件进行挂载的FUSE文件系统，挂载成功后无法更新AccessKey信息，已经挂载了OSS存储卷的应用仍然使用原AK向OSS Server端发送请求。

• 场景5原因：OSS存储卷不支持硬链接操作。在早期的CSI版本中，硬链接操作返回的报错为Operation not permitted。

解决方案

• 场景1解决方案：通过增加配置项修改挂载根目录的权限。

  参数	说明
  allow_other	设置挂载目录的权限为777。
  mp_umask	用于设定挂载目录的权限掩码，只有当allow_other选项设置后，该选项才生效。默认值为000。例如： 需设置挂载目录的权限为770，则增加-o allow_other -o mp_umask=007。 需设置挂载目录的权限为700，则增加-o allow_other -o mp_umask=077。

• 场景2解决方案：以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。

• 场景3解决方案：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。

• 场景4解决方案：切换Secret中新的AccessKey信息后重新挂载。非容器化版本或开启了独享挂载方式的容器化版本，您只需要重启应用Pod触发重挂载。具体操作，请参见共享挂载方式下如何实现ossfs重挂载？。

• 场景5解决方案：改造业务，使用OSS存储卷时，应避免硬链接操作。若您的业务必须使用硬链接操作，建议您更换存储。

OSS静态卷挂载失败

问题现象

OSS静态卷挂载失败，Pod无法启动，Event提示FailedMount。

问题原因

• 原因1：静态卷目前不支持挂载到Bucket中不存在的目录中，原挂载目录不存在导致挂载失败。

  重要

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

• 原因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_<ossfsVer>_<ossfsArch>_x86_64.rpm ...

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

       rpm -i /etc/csi-tool/ossfs_<ossfsVer>_<ossfsArch>_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性能下降。

• 原因3：OSS服务端设置存储类型为标准存储（Standard）以外的存储，其他存储类型将不同程度地降低数据访问的性能。

解决方案

原因1解决方案：

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

原因2解决方案：

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

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

原因3解决方案：

您需要修改存储类型或者解冻文件。

OSS控制台看到文件大小为0

问题现象

容器内挂载OSS数据卷时，在文件中写入数据，但在OSS控制台看到文件大小为0。

问题原因

容器使用ossfs挂载OSS，即基于FUSE方式挂载OSS的Bucket，只有在文件执行close或者flush时，文件内容才会上传至OSS的服务端。

解决方案

使用lsof+文件名称的方式，查看当前文件是否被其他进程占用，关闭相应进程，释放文件fd。关于lsof更多信息，请参见Isof。

文件目录挂载后，显示为文件对象

问题现象

容器内挂载OSS数据卷时，文件原本是目录，挂载后，显示为文件对象。

问题原因

原因1：目录对象在OSS服务端content-type类型是非默认的application/octet-stream类型（例如text/html, image/jpeg等），或目录对象的大小非0，ossfs根据其元信息将其视为相应的文件对象。

原因2：非原因1的情况，但目录对象缺少元信息x-oss-meta-mode。

解决方案

原因1解决方案：

通过HeadObject或stat（查看Bucket和Object信息）获取目录对象元信息，目录对象需要以"/"结尾（例如a/b/），以API返回为例。

{
  "server": "AliyunOSS",
  "date": "Wed, 06 Mar 2024 02:48:16 GMT",
  "content-type": "application/octet-stream",
  "content-length": "0",
  "connection": "keep-alive",
  "x-oss-request-id": "65E7D970946A0030334xxxxx",
  "accept-ranges": "bytes",
  "etag": "\"D41D8CD98F00B204E9800998ECFxxxxx\"",
  "last-modified": "Wed, 06 Mar 2024 02:39:19 GMT",
  "x-oss-object-type": "Normal",
  "x-oss-hash-crc6xxxxx": "0",
  "x-oss-storage-class": "Standard",
  "content-md5": "1B2M2Y8AsgTpgAmY7Phxxxxx",
  "x-oss-server-time": "17"
}

以上返回示例中：

• content-type：为application/octet-stream，即目录对象为application/octet-stream类型。

• content-length：为0，即目录对象大小为0。

若不满足以上条件，您可以通过以下方式修复：

1. 通过GetObject或命令行工具ossutil快速入门获取该对象，确认数据是否有用。若数据有用或不能确定，建议对其进行备份，例如变更名称（对xx/目录对象，请勿使用xx作为新的名称）后上传至OSS。

2. 通过DeleteObject或rm（删除）删除有问题的目录对象，然后确认ossfs是否正常显示目录。

原因2解决方案：

若通过原因1的解决方案未修复问题，您可以在容器内挂载OSS数据卷时，在OSS静态卷PV的otherOpts字段中增加-o complement_stat来解决。

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-name>为指定的PV名称。

     for i in $(mount | grep -i ossfs | grep -i <pv-name> | 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 =后面加上挂载的目录。

通过OSS存储卷写入的文件对象的元数据Content-Type全为application/octet-stream类型

问题现象

通过OSS存储卷写入的文件对象的元数据Content-Type全为application/octet-stream类型，导致浏览器或其他客户端未能够正确识别和处理这些文件。

问题原因

• 未指定Content-Type类型，ossfs默认将文件对象视为二进制流文件。

• 通过/etc/mime.types配置文件指定Content-Type类型，但未生效。

解决方案

1. 确认CSI组件版本，1.26.6和1.28.1版本的组件对Content-Type配置存在兼容性问题。若使用了相关版本，请升级CSI至最新版本。更多信息，请参见【组件公告】关于1.26.6和1.28.1版本的csi-plugin和csi-provisioner组件兼容性问题。

2. 若您已经通过使用mailcap、mime-support在节点上生成/etc/mime.types的方式指定Content-Type类型，升级CSI版本后，重新挂载对应OSS存储卷即可。

3. 若您未指定Content-Type类型，可通过以下两种方式指定：

   • 节点级别配置：在节点上生成/etc/mime.types配置文件，对所有新挂载到该节点上应用的OSS存储卷生效。更多信息，请参见使用ossfs上传到OSS的文件的Content-Type全是application/octet-stream。

   • 集群级别配置：该方式对集群所有新挂载的OSS存储卷生效，/etc/mime.types内容与mailcap默认生成的内容一致。

     1. 执行以下命令，检查csi-plugin配置文件是否存在。

        kubectl -n kube-system get cm csi-plugin

        若不存在，使用以下内容，创建csi-plugin同名ConfigMap；若不存在，则需要在原ConfigMap中增加data.fuse-ossfs中的内容mime-support="true"。

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: csi-plugin
          namespace: kube-system
        data:
          fuse-ossfs: |
            mime-support="true"

     2. 重启csi-plugin，使配置生效，重启csi-plugin不会影响当前已经成功挂载的存储卷的使用。

        kubectl -n kube-system delete pod -l app=csi-plugin

4. 重新挂载对应的OSS存储卷。

如何在RRSA鉴权方式中使用指定的ARNs或ServiceAccount？

通过RRSA方式的OSS存储卷鉴权时，无法满足例如使用第三方OIDC身份提供商、使用非默认ServiceAccount等需求。

此时，您只需要在PV中通过roleName配置项指定RAM角色名称，即可由CSI存储插件获取默认的Role ARN及OIDC Provider ARN。若您需要实现定制化的RRSA鉴权，则需要更改PV的配置信息如下：

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-oss
spec:
  capacity:
    storage: 5Gi
  accessModes:
    - ReadOnlyMany
  persistentVolumeReclaimPolicy: Retain
  csi:
    driver: ossplugin.csi.alibabacloud.com
    volumeHandle: pv-oss # 需要和PV名字一致。
    volumeAttributes:
      bucket: "oss"
      url: "oss-cn-hangzhou.aliyuncs.com"
      otherOpts: "-o umask=022 -o max_stat_cache_size=0 -o allow_other"
      authType: "rrsa"
      oidcProviderArn: "<oidc-provider-arn>"
      roleArn: "<role-arn>"
      #roleName: "<role-name>" #配置roleArn和oidcProviderArn后，roleName失效。
      serviceAccountName: "<service-account-name>" 

创建硬链接时返回错误Operation not supported或Operation not permitted

问题现象

创建硬链接时返回错误Operation not supported或Operation not permitted。

问题原因

OSS存储卷不支持硬链接操作，将返回Operation not supported错误。在早期的CSI版本中，硬链接操作返回的报错为Operation not permitted。

解决方案

改造业务，在使用OSS存储卷时，应避免硬链接操作。若您的业务必须使用硬链接操作，建议您更换存储。

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

问题现象

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

问题原因

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

解决方案

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

ossutil -e "<endpoint>" -i "<accessKeyID>" -k "<accessKeySecret>" stat oss://"<bucket><path>"

ossutil -e "oss-<region-id>-internal.aliyuncs.com" -i "<accessKeyID>" -k "<accessKeySecret>" 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错误码解决。

ossfs容器化后如何开启独享挂载模式？

问题现象

同一节点上挂载了相同OSS存储卷的多个Pod共享挂载点。

问题原因

ossfs容器化前，默认使用独享方式挂载，即每个挂载OSS存储卷的Pod，都将在对应节点上为该存储卷拉起ossfs进程。不同ossfs进程对应的挂载点之间完全独立，即对于挂载了同一OSS存储卷的不同Pod在读写时互不影响。

ossfs容器化后，ossfs进程将以容器的方式运行在集群的Pod中，具体为kube-system下的csi-fuse-ossfs-* Pod。在多挂载的场景下，独享方式挂载将在集群中拉起大量Pod，进而导致弹性网卡不足等问题。因此，容器化后将默认使用共享方式挂载，即同一节点上挂载了相同OSS存储卷的多个Pod共享挂载点，即均对应同一个csi-fuse-ossfs-* Pod，实际由同一ossfs进程实现挂载。

解决方案

如果您期望恢复到容器化前的独享挂载，请在创建OSS存储卷时增加useSharedPath配置项，并将其设为"false"。示例如下：

apiVersion: v1
kind: PersistentVolume
metadata:
  name: oss-pv
spec:
  accessModes:
  - ReadOnlyMany
  capacity:
    storage: 5Gi
  csi:
    driver: ossplugin.csi.alibabacloud.com
    nodePublishSecretRef:
      name: oss-secret
      namespace: default
    volumeAttributes:
      bucket: bucket-name
      otherOpts: -o max_stat_cache_size=0 -o allow_other
      url: oss-cn-zhangjiakou.aliyuncs.com
      useSharedPath: "false" 
    volumeHandle: oss-pv
  persistentVolumeReclaimPolicy: Delete
  volumeMode: Filesystem

共享挂载方式下如何实现ossfs重挂载？

问题现象

修改鉴权信息或ossfs版本后，已经在运行的ossfs进程无法自动变更。

问题原因

ossfs运行后无法变更鉴权信息等配置，变更配置后，需要重启ossfs进程（容器化版本后，即为kube-system下的csi-fuse-ossfs-* Pod）与对应的应用Pod，造成业务中断。因此，默认情况下CSI不会对已经运行的ossfs进行变更，您需要手动进行重挂载操作。

解决方案

若您使用的是非容器化的CSI版本，或开启了独享挂载，可以直接重启对应的应用Pod。容器化版本后，默认使用共享挂载方式，即每个节点上挂载同一OSS存储卷的所有应用Pod共用ossfs进程实现挂载。

1. 确认当前FUSE Pod被哪些应用Pod在使用。

   1. 执行以下命令，确认需要变更的csi-fuse-ossfs-* Pod。

      其中<pv-name>为PV名称，<node-name>为节点名称。

      kubectl -n kube-system get pod -lcsi.alibabacloud.com/volume-id=<pv-name> -owide | grep <node-name>

      预期输出：

      csi-fuse-ossfs-xxxx   1/1     Running   0          10d     192.168.128.244   cn-beijing.192.168.XX.XX   <none>           <none>

   2. 执行以下命令，确认正在挂载该OSS存储卷的所有Pod。

      其中<ns>为命名空间名称，<pvc-name>为PVC名称。

   3. kubectl -n <ns> describe pvc <pvc-name>

      预期输出（包含User By）：

      Used By:       oss-static-94849f647-4****
                     oss-static-94849f647-6****
                     oss-static-94849f647-h****
                     oss-static-94849f647-v****
                     oss-static-94849f647-x****

   4. 执行以下命令，获取通过csi-fuse-ossfs-xxxx挂载的Pod，即与csi-fuse-ossfs-xxxx运行在同一节点的Pod。

      kubectl -n <ns> get pod -owide | grep 192.168.128.244

      预期输出：

      NAME                         READY   STATUS    RESTARTS   AGE     IP               NODE                         NOMINATED NODE   READINESS GATES
      oss-static-94849f647-4****   1/1     Running   0          10d     192.168.100.11   cn-beijing.192.168.100.3     <none>           <none>
      oss-static-94849f647-6****   1/1     Running   0          7m36s   192.168.100.18   cn-beijing.192.168.100.3     <none>           <none>

2. 进行ossfs重挂载，会导致业务重启。

   将应用Pod（上述示例中为oss-static-94849f647-4****和oss-static-94849f647-6****）通过kubectl scale等方式同时删除。在无应用Pod挂载时，csi-fuse-ossfs-xxxx Pod将自动被回收；恢复副本数后，将使用PV的新配置重新挂载，由CSI创建新的csi-fuse-ossfs-yyyy Pod。

   如果无法同时保证这些Pod被删除，或Pod能容忍OSS读写失败，您可以直接删除csi-fuse-ossfs-xxxx Pod，此时应用Pod内读写OSS将返回disconnected error。然后，逐个重启业务Pod，重启后的Pod将通过CSI新建的csi-fuse-ossfs-yyyy Pod恢复OSS读写。

如何查看通过OSS存储卷访问OSS的记录？

调用OSS的操作记录统一在OSS管理控制台查看，且要求已开通OSS的日志查询功能。关于开通日志查询的操作，请参见开通实时日志查询。

1. 登录OSS管理控制台。

2. 单击Bucket 列表，然后单击目标Bucket名称。

3. 在左侧导航栏，选择日志管理 > 实时查询。

4. 在实时查询页签下，根据查询语法和分析语法，输入查询和分析语句，对OSS日志进行分析。您可以通过user_agent和client_ip字段定位日志是否来源于ACK。

   1. 定位由ACK发送的OSS操作请求时，您需要选择user_agent字段，展开后看到user_agent里包含ossfs的都可以选择。

      重要

      • user-agent字段的取值与ossfs版本有关，ossfs版本不同，user-agent字段的值也不一样，但均以aliyun-sdk-http/1.0()/ossfs开头。

      • 如果您在ECS上也通过ossfs挂载，相关日志也会被耦合到这里。

   2. 如需定位到某个ECS实例或集群，您还可以选择client_ip字段，然后选择对应的IP。

   结合以上两个字段选择，查询到的日志示例如下图所示。

日志查询部分字段说明