本文为您介绍OSS存储卷常见问题的处理方法。
类型 | 问题 |
挂载问题 | |
使用问题 | |
控制台检测失败问题 | |
其他 |
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信息修改后不生效。
问题原因
场景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端发送请求。
解决方案
场景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,使其与容器进程用户一致。
参数 | 说明 |
uid | 指定挂载目录下子目录及文件归属用户的用户UID。 |
gid | 指定挂载目录下子目录及文件归属用户的用户GID。 |
例如,容器访问OSS的进程ID为uid=1000(biodocker)
、gid=1001(biodocker)
、groups=1001(biodocker)
,则需配置-o uid=1000
,-o gid=1001
。
场景4解决方案:切换Secret中新的AccessKey信息后重新挂载。非容器化版本或开启了独享挂载方式的容器化版本,您只需要重启应用Pod触发重挂载。具体操作,请参见共享挂载方式下如何实现ossfs重挂载?。
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解决方案:
建议您将csi-plugin版本升级到v1.26.2或以上版本,该版本修复了刚扩容出的节点初始化时,ossfs安装失败的问题。
执行以下命令,尝试重启对应节点上的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包,请提交工单处理。
原因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解决方案:
将CSI plugin组件版本升级至v1.26.6后,ossfs可支持通过listObjectsV2访问Bucket。
说明CSI plugin组件的v1.26.6版本处于灰度发布中,如需使用,请提交工单申请加入白名单。
在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。
若不满足以上条件,您可以通过以下方式修复:
通过GetObject或命令行工具ossutil快速入门获取该对象,确认数据是否有用。若数据有用或不能确定,建议对其进行备份,例如变更名称(对
xx/
目录对象,请勿使用xx
作为新的名称)后上传至OSS。通过DeleteObject或rm(删除)删除有问题的目录对象,然后确认ossfs是否正常显示目录。
原因2解决方案:
若通过原因1的解决方案未修复问题,您可以在容器内挂载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的请求。如果请求次数很多,会产生费用。
解决方案
通过审计追踪产生请求的进程,并进行相应修复。您可以在节点上进行如下操作。
执行以下命令,安装auditd并启动。
sudo yum install auditd sudo service auditd start
将对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
通过以下命令,在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) ---
借助日志进一步确认是否存在非业务的进程调用,并进行修复。
例如,通过auditlog查到updatedb扫描了所挂载的目录,可以通过修改
/etc/updatedb.conf
让它跳过。具体操作如下。在
RUNEFS =
后面加上fuse.ossfs
。在
PRUNEPATHS =
后面加上挂载的目录。
通过OSS存储卷写入的文件对象的元数据Content-Type全为application/octet-stream类型
问题现象
通过OSS存储卷写入的文件对象的元数据Content-Type全为application/octet-stream类型,导致浏览器或其他客户端未能够正确识别和处理这些文件。
问题原因
未指定Content-Type类型,ossfs默认将文件对象视为二进制流文件。
通过/etc/mime.types配置文件指定Content-Type类型,但未生效。
解决方案
确认CSI组件版本,1.26.6和1.28.1版本的组件对Content-Type配置存在兼容性问题。若使用了相关版本,请升级CSI至最新版本。更多信息,请参见【组件公告】关于1.26.6和1.28.1版本的csi-plugin和csi-provisioner组件兼容性问题。
若您已经通过使用
mailcap
、mime-support
在节点上生成/etc/mime.types
的方式指定Content-Type类型,升级CSI版本后,重新挂载对应OSS存储卷即可。若您未指定Content-Type类型,可通过以下两种方式指定:
节点级别配置:在节点上生成
/etc/mime.types
配置文件,对所有新挂载到该节点上应用的OSS存储卷生效。更多信息,请参见使用ossfs上传到OSS的文件的Content-Type全是application/octet-stream。集群级别配置:该方式对集群所有新挂载的OSS存储卷生效,
/etc/mime.types
内容与mailcap
默认生成的内容一致。执行以下命令,检查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"
重启csi-plugin,使配置生效,重启csi-plugin不会影响当前已经成功挂载的存储卷的使用。
kubectl -n kube-system delete pod -l app=csi-plugin
重新挂载对应的OSS存储卷。
控制台检测长期卡住,或失败无信息透出,或显示unknown error
问题现象
检测长期卡住,或失败无信息透出,或显示unknown error。
问题原因
若检测长期卡在进行中状态,基本判断为网络原因。对于其他未知错误,您可以通过如下查询日志及手动通过ossutil进行原因定位。
解决方案
您可以通过日志和ossutil工具定位具体问题。
通过日志定位具体问题
执行以下命令,找到执行检测任务的Pod。
osssecret-namespace
:保密字典所在命名空间。pv-name
:PV的名称。
kubectl -n <osssecret-namespace> get pod | grep <pv-name>-check
预期输出:
<pv-name>-check-xxxxx
执行以下命令,查询失败原因。
kubectl -n <osssecret-namespace> logs -f <pv-name>-check-xxxxx
预期输出:
check ossutil endpoint: oss-<region-id>-internal.aliyuncs.com bucket: <bucket-name> path: <path> Error: oss: service returned error: StatusCode=403, ErrorCode=InvalidAccessKeyId, ErrorMessage="The OSS Access Key Id you provided does not exist in our records.", RequestId=65267325110A0C3130B7071C, Ec=0002-00000901, Bucket=<bucket-name>, Object=<path>
通过ossutil工具定位具体问题
如果您的相关Pod已被删除,您可以通过ossutil工具复现检测,定位具体问题。
OSS访问检测通过stat(查看Bucket和Object信息)实现,您可以在集群内任意节点上安装ossutil并执行以下指令复现。
ossutil -e "<endpoint>" -i "<accessKeyID>" -k "<accessKeySecret>" stat oss://"<bucket><path>"
参数 | 说明 |
endpoint |
|
accessKeyID | 保密字典中的AccessKeyID。 |
accessKeySecret | 保密字典中的AccessKeySecret。 |
bucket | Bucket ID。 |
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进行变更,您需要手动进行重挂载操作。
解决方案
ossfs重挂载将导致业务Pod重启,引起业务中断,请谨慎操作。
若您使用的是非容器化的CSI版本,或开启了独享挂载,可以直接重启对应的应用Pod。容器化版本后,默认使用共享挂载方式,即每个节点上挂载同一OSS存储卷的所有应用Pod共用ossfs进程实现挂载。
确认当前FUSE Pod被哪些应用Pod在使用。
执行以下命令,确认需要变更的
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>
执行以下命令,确认正在挂载该OSS存储卷的所有Pod。
其中
<ns>
为命名空间名称,<pvc-name>
为PVC名称。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****
执行以下命令,获取通过
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>
进行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读写。