阿里云助力您在中国加快取得成功
一站式安全合规咨询服务
MLPS 2.0 一站式合规解决方案
依托我们的网络进军中国市场
提升面向互联网应用的性能和安全性
保障您的中国业务安全无忧
通过强大的数据安全框架保护您的数据资产
申请 ICP 备案的流程解读和咨询服务
面向大数据建设、管理及应用的全域解决方案
企业内大数据建设、管理和应用的一站式解决方案
将您的采购和销售置于同一企业级全渠道数字平台上
全渠道内置 AI 驱动、拟人化、多语言对话的聊天机器人
快速搭建在线教育平台
提供域名注册、分析和保护服务
云原生 Kubernetes 容器化应用运行环境
以 Kubernetes 为使用界面的容器服务产品,提供符合容器规范的算力资源
安全的镜像托管服务,支持全生命周期管理
多集群环境下微服务应用流量统一管理
提供任意基础设施上容器集群的统一管控,助您轻松管控分布式云场景
高弹性、高可靠的企业级无服务器 Kubernetes 容器产品
敏捷安全的 Serverless 容器运行服务
为虚拟机和容器提供高可靠性、高性能、低时延的块存储服务
一款海量、安全、低成本、高可靠的云存储服务
可靠、弹性、高性能、多共享的文件存储服务
全托管、可扩展的并行文件系统服务。
全托管的 NoSQL 结构化数据实时存储服务
可抵扣多种存储产品的容量包,兼具灵活性和长期成本优化
让您的应用跨不同可用区资源自动分配访问量
随时绑定和解绑 VPC ECS
云网络公网、跨域流量统一计费
高性价比,可抵扣按流量计费的流量费用
创建云上隔离的网络,在专有环境中运行资源
在 VPC 环境下构建公网流量的出入口
具备网络状态可视化、故障智能诊断能力的自助式网络运维服务。
安全便捷的云上服务专属连接
基于阿里云专有网络的私有 DNS 解析服务
保障在线业务不受大流量 DDoS 攻击影响
系统运维和安全审计管控平台
业务上云的第一个网络安全基础设施
集零信任内网访问、办公数据保护、终端管理等多功能于一体的办公安全管控平台
提供7X24小时安全运维平台
防御常见 Web 攻击,缓解 HTTP 泛洪攻击
实现全站 HTTPS,呈现可信的 WEB 访问
为云上应用提供符合行业标准和密码算法等级的数据加解密、签名验签和数据认证能力
一款发现、分类和保护敏感数据的安全服务
创建、控制和管理您的加密密钥
快速提高应用高可用能力服务
围绕应用和微服务的 PaaS 平台
兼容主流开源微服务生态的一站式平台
多集群环境下微服务应用流量统一管理
企业级全托管实时数据流平台
全托管,开箱即用的Apache Kafka全托管服务
提供物联网移动端和云交互的消息队列
开箱即用的全托管 RabbitMQ 服务
提供基于消息的可靠异步通信机制
应用之间的消息队列和通知
无服务器事件总线服务
Super MySQL 和 PostgreSQL,高度兼容 Oracle 语法
全托管 MySQL、PostgreSQL、SQL Server、MariaDB
兼容 Redis® 的缓存和KV数据库
兼容Apache Cassandra、Apache HBase、Elasticsearch、OpenTSDB 等多种开源接口
文档型数据库,支持副本集和分片架构
100%兼容 Apache HBase 并深度扩展,稳定、易用、低成本的NoSQL数据库。
低成本、高可用、可弹性伸缩的在线时序数据库服务
专为搜索和分析而设计,成本效益达到开源的两倍,采用最新的企业级AI搜索和AI助手功能。
一款兼容PostgreSQL协议的实时交互式分析产品
一种快速、完全托管的 TB/PB 级数据仓库
基于 Flink 为大数据行业提供解决方案
基于Qwen和其他热门模型的一站式生成式AI平台,可构建了解您业务的智能应用程
一站式机器学习平台,满足数据挖掘分析需求
高性能向量检索服务,提供低代码API和高成本效益
帮助您的应用快速构建高质量的个性化推荐服务能力
提供定制化的高品质机器翻译服务
全面的AI计算平台,满足大模型训练等高性能AI计算的算力和性能需求
具备智能会话能力的会话机器人
基于机器学习的智能图像搜索产品
基于阿里云深度学习技术,为用户提供图像分割、视频分割、文字识别等离线SDK能力,支持Android、iOS不同的适用终端。
语音识别、语音合成服务以及自学习平台
一站式智能搜索业务开发平台
助力金融企业快速搭建超低时延、高质量、稳定的行情数据服务
帮助企业快速测算和分析企业的碳排放和产品碳足迹
企业工作流程自动化,全面提高效率
金融级云原生分布式架构的一站式高可用应用研发、运维平台
eKYC 数字远程在线解决方案
可智能检测、大数据驱动的综合性反洗钱 (AML) 解决方案
阿里云APM类监控产品
实时云监控服务,确保应用及服务器平稳运行
为系统运维人员管理云基础架构提供全方位服务的云上自动化运维平台
面向您的云资源的风险检测服务
提升分布式环境下的诊断效率
日志类数据一站式服务,无需开发就能部署
ECS 预留实例
让弹性计算产品的成本和灵活性达到最佳平衡的付费方式。云原生 AI 套件
加速AI平台构建,提高资源效率和交付速度FinOps
实时分析您的云消耗并实现节约SecOps
实施细粒度安全控制DevOps
快速、安全地最大限度提高您的DevOps优势自带IP上云
自带公网 IP 地址上云全球网络互联
端到端的软件定义网络解决方案,可推动跨国企业的业务发展全球应用加速
提升面向互联网应用的性能和安全性全球互联网接入
将IDC网关迁移到云端云原生 AI 套件
加速AI平台构建,提高资源效率和交付速度FinOps
实时分析您的云消耗并实现节约SecOps
实施细粒度安全控制DevOps
快速、安全地最大限度提高您的DevOps优势金融科技云数据库解决方案
利用专为金融科技而设的云原生数据库解决方案游戏行业云数据库解决方案
提供多种成熟架构,解决所有数据问题Oracle 数据库迁移
将 Oracle 数据库顺利迁移到云原生数据库数据库迁移
加速迁移您的数据到阿里云阿里云上的数据湖
实时存储、管理和分析各种规模和类型的数据数码信贷
利用大数据和 AI 降低信贷和黑灰产风险面向企业数据技术的大数据咨询服务
帮助企业实现数据现代化并规划其数字化未来人工智能对话服务
全渠道内置 AI 驱动、拟人化、多语言对话的聊天机器人EasyDispatch 现场服务管理
为现场服务调度提供实时AI决策支持在线教育
快速搭建在线教育平台窄带高清 (HD) 转码
带宽成本降低高达 30%广电级大型赛事直播
为全球观众实时直播大型赛事,视频播放流畅不卡顿直播电商
快速轻松地搭建一站式直播购物平台用于供应链规划的Alibaba Dchain
构建和管理敏捷、智能且经济高效的供应链云胸牌
针对赛事运营的创新型凭证数字服务数字门店中的云 POS 解决方案
将所有操作整合到一个云 POS 系统中元宇宙
元宇宙是下一代互联网人工智能 (AI) 加速
利用阿里云 GPU 技术,为 AI 驱动型业务以及 AI 模型训练和推理加速DevOps
快速、安全地最大限度提高您的DevOps优势数据迁移解决方案
加速迁移您的数据到阿里云企业 IT 治理
在阿里云上构建高效可控的云环境基于日志管理的AIOps
登录到带有智能化日志管理解决方案的 AIOps 环境备份与存档
数据备份、数据存档和灾难恢复用阿里云金融服务加快创新
在云端开展业务,提升客户满意度
为全球资本市场提供安全、准确和数字化的客户体验
利用专为金融科技而设的云原生数据库解决方案
利用大数据和 AI 降低信贷和黑灰产风险
建立快速、安全的全球外汇交易平台
新零售时代下,实现传统零售业转型
利用云服务处理流量波动问题,扩展业务运营、降低成本
快速轻松地搭建一站式直播购物平台
面向大数据建设、管理及应用的全域解决方案
全渠道内置 AI 驱动、拟人化、多语言对话的聊天机器人
以数字化媒体旅程为当今的媒体市场准备就绪您的内容
带宽成本降低高达 30%
快速轻松地搭建一站式直播购物平台
为全球观众实时直播大型赛事,视频播放流畅不卡顿
使用阿里云弹性高性能计算 E-HPC 将本地渲染农场连接到云端
构建发现服务,帮助客户找到最合适的内容
保护您的媒体存档安全
通过统一的数据驱动平台提供一致的全生命周期客户服务
在钉钉上打造一个多功能的电信和数字生活平台
在线存储、共享和管理照片与文件
提供全渠道的无缝客户体验
面向中小型企业,为独立软件供应商提供可靠的IT服务
打造最快途径,助力您的新云业务扬帆起航
先进的SD-WAN平台,可实现WAN连接、实时优化并降低WAN成本
通过自动化和流程标准化实现快速事件响应
针对关键网络安全威胁提供集中可见性并进行智能安全分析
提供大容量、可靠且高度安全的企业文件传输
用智能技术数字化体育赛事
基于人工智能的低成本体育广播服务
专业的广播转码及信号分配管理服务
基于云的音视频内容引入、编辑和分发服务
在虚拟场馆中模拟关键运营任务
针对赛事运营的创新型凭证数字服务
智能和交互式赛事指南
轻松管理云端背包单元的绑定直播流
通过数据加强您的营销工作
元宇宙是下一代互联网
利用生成式 AI 加速创新,创造新的业务佳绩
阿里云高性能开源大模型
借助AI轻松解锁和提炼文档中的知识
通过AI驱动的语音转文本服务获取洞察
探索阿里云人工智能和数据智能的所有功能、新优惠和最新产品
该体验中心提供广泛的用例和产品帮助文档,助您开始使用阿里云 AI 产品和浏览您的业务数据。
利用阿里云 GPU 技术,为 AI 驱动型业务以及 AI 模型训练和推理加速
元宇宙是下一代互联网
构建发现服务,帮助客户找到最合适的内容
全渠道内置 AI 驱动、拟人化、多语言对话的聊天机器人
加速迁移您的数据到阿里云
在阿里云上建立一个安全且易扩容的环境,助力高效率且高成本效益的上云旅程
迁移到完全托管的云数据库
将 Oracle 数据库顺利迁移到云原生数据库
自带公网 IP 地址上云
利用阿里云强大的安全工具集,保障业务安全、应用程序安全、数据安全、基础设施安全和帐户安全
保护、备份和还原您的云端数据资产
MLPS 2.0 一站式合规解决方案
快速高效地将您的业务扩展到中国,同时遵守适用的当地法规
实现对 CloudOps、DevOps、SecOps、AIOps 和 FinOps 的高效、安全和透明的管理
构建您的原生云环境并高效管理集群
快速、安全地最大限度提高您的DevOps优势
实施细粒度安全控制
提供运维效率和总体系统安全性
实时分析您的云消耗并实现节约
实时存储、管理和分析各种规模和类型的数据
登录到带有智能化日志管理解决方案的 AIOps 环境
帮助企业实现数据现代化并规划其数字化未来
帮助零售商快速规划数字化之旅
将全球知名的 CRM 平台引入中国
在线存储、共享和管理照片与文件
构建、部署和管理高可用、高可靠、高弹性的应用程序
快速、安全地最大限度提高您的DevOps优势
将您的采购和销售置于同一企业级全渠道数字平台上
企业内大数据建设、管理和应用的一站式解决方案
帮助企业简化 IT 架构、实现商业价值、加速数字化转型的步伐
快速高效地将您的业务扩展到中国,同时遵守适用的当地法规
快速搜集、处理、分析联网设备产生的数据
0.0.201
本文为您介绍OSS存储卷常见问题的处理方法。
类型 | 问题 |
类型 | 问题 |
挂载问题 | |
使用问题 | |
卸载问题 | |
控制台检测失败问题 | |
其他 |
OSS存储卷挂载时间延长。
同时满足以下配置,kubelet在存储卷挂载过程中将执行chmod或chown操作,导致挂载时间延长。
在PV及PVC模板中配置的参数AccessModes值为ReadWriteOnce。
在应用模板中配置了securityContext.fsgroup参数。
ossfs挂载工具支持通过参数修改其挂载点下文件所属的UID、GID以及文件的mode。
参数 | 说明 |
参数 | 说明 |
uid | 指定挂载目录下子目录及文件归属用户的用户UID。 |
gid | 指定挂载目录下子目录及文件归属用户的用户GID。 |
umask | 用于设定挂载目录下子目录及文件的权限掩码。使用方式与mp_umask类似,但无需依赖allow_other配置项。 |
配置后,请删除securityContext下的fsgroup参数。
对于1.20及之后版本的Kubernetes集群,除了上述解决方法外,也可通过将fsGroupChangePolicy配置为OnRootMismatch,这时只有在首次启动时才会执行chmod
或chown
操作,导致存在挂载时间延长的问题,后续挂载OSS存储卷时挂载时间将恢复正常。关于fsGroupChangePolicy参数的更多信息,请参见为Pod或容器配置安全性上下文。
当您在以下几种场景中进行操作时,出现错误提示Permission Denied。
问题原因
OSS默认使用Linux的root用户进行挂载,权限为700。当容器进程以非root用户运行时,权限不足。
解决方案
通过增加配置项修改挂载根目录的权限。
参数 | 说明 |
参数 | 说明 |
allow_other | 设置挂载目录的权限为777。 |
mp_umask | 用于设定挂载目录的权限掩码,只有当
|
问题原因
通过其他方式上传的文件在ossfs中默认权限为640。当容器进程以非root用户运行时,权限不足。
解决方案
以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。
问题原因
在ossfs中创建的普通文件默认权限为644。配置securityContext
中的fsGroup
字段,或创建后chmod、chown文件,都可能导致权限或所有者的变更。当另一个容器进程以其他用户操作文件时,可能会出现权限不足的问题。
解决方案
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
。
nodePublishSecretRef
字段指定Secret。因为AK轮转等原因撤销了原AK,Secret中AccessKey信息修改后不生效问题原因
OSS数据卷是使用ossfs文件进行挂载的FUSE文件系统,挂载成功后无法更新AccessKey信息,已经挂载了OSS存储卷的应用仍然使用原AK向OSS Server端发送请求。
解决方案
切换Secret中新的AccessKey信息后重新挂载。非容器化版本或开启了独享挂载方式的容器化版本,您只需要重启应用Pod触发ossfs重启。具体操作,请参见共享挂载方式下,如何重启ossfs进程?。
问题原因
OSS存储卷不支持硬链接操作。在早期的CSI版本中,硬链接操作返回的报错为Operation not permitted。
解决方案
改造业务,使用OSS存储卷时,应避免硬链接操作。若您的业务必须使用硬链接操作,建议您更换存储。
问题原因
非root用户运行的业务容器没有/path/subpath/in/oss/
目录下文件的权限(默认为640)。subpath方式挂载OSS存储卷时,ossfs在OSS服务端实际的挂载目录为PV中定义的path目录,即上述示例中的/path
,而非/path/subpath/in/oss/
。配置allow_other或mp_umask挂载项仅对/path
目录生效,/path/subpath/in/oss/
目录作为子目录仍默认为640。
解决方案
通过umask配置项修改子目录默认权限,例如-o umask=000
将默认权限修改为777。
OSS存储卷挂载失败,Pod无法启动,Event提示FailedMount。
原因1:ossfs早期的版本不支持挂载到Bucket中不存在的目录中,原挂载目录不存在导致挂载失败。
OSS控制台中可见的子路径在Server端不一定真实存在,以ossutil或OSS API的返回为准。例如,直接创建/a/b/c/
目录,/a/b/c/
为单独的目录对象,而/a/
或/a/b/
目录对象实际并不存在。同理,如上传/a/*
文件,/a/b
、/a/c
等为单独的文件对象,/a/
目录对象不存在。
原因2:AccessKey或RRSA使用的角色信息填写错误或权限不足导致挂载失败。
原因3:CSI版本在1.30.4及以上时,OSSFS所在的Pod运行在ack-csi-fuse
命名空间中。挂载时CSI将先拉起OSSFS所在的Pod,再通过RPC请求实际启动Pod中的OSSFS进程。若Event的内容中包含FailedMount /run/fuse.ossfs/xxxxxx/mounter.sock: connect: no such file or directory
,则挂载失败是因为OSSFS所在Pod未正常拉起或被意外删除。
原因4:若Event的内容中包含Failed to find executable /usr/local/bin/ossfs: No such file or directory
,则挂载失败是因为OSSFS在节点上安装失败。
原因5:若Event的内容中包含error while loading shared libraries: xxxxx: cannot open shared object file: No such file or directory
,挂载失败的原因为当前CSI版本ossfs直接运行在节点上,且操作系统缺乏部分ossfs运行所需的动态库。以下情况都可能导致该报错:
手动在节点安装过其他版本的ossfs工具,且适配的操作系统与当前节点不一致。
节点操作系统版本升级导致OpenSSL默认版本变更,例如Alibaba Cloud Linux 2升级至Alibaba Cloud Linux 3。
ossfs运行在节点上时,不支持CentOS、Alibaba Cloud Linux、ContainerOS和龙蜥以外的操作系统。
在符合操作系统要求的节点上删除过默认的FUSE、cURL、xml2等ossfs运行需要的动态库,或变更过OpenSSL的默认版本。
原因6:挂载OSS Bucket的子目录时,AccessKey或RRSA使用的角色仅授权了子目录范围的权限,挂载失败。ossfs Pod日志中同时包含403 AccessDenied
和404 NoSuchKey
报错。
ossfs在启动时将自动对OSS Bucket进行权限校验与连通性检测。挂载目标为OSS子目录时,1.91.5以下版本的ossfs将先尝试访问Bucket根目录;若访问失败,则重新尝试访问子目录。对Bucket有完整只读权限时,新版本ossfs允许挂载OSS Bucket中不存在的子目录。
因此,对若AccessKey或RRSA使用的角色仅授权了子目录范围的权限,将在初次验证时报403 AccessDenied
错误;若该子目录不存在,则继续报404 NoSuchKey
错误并异常退出,导致挂载失败。
原因7:Bucket配置了镜像回源,挂载目录未从源站同步。
原因8:Bucket配置了静态网站托管,ossfs检查OSS端挂载目录时,请求转发到index.html等文件中。
原因1解决方案:
检查子路径在OSS Server端是否存在。
假设PV的挂载路径为sub/path/
,您可以使用stat(查看Bucket和Object信息)查询objectname
为sub/path/
的对象,或使用openapi HeadObject查询key
为sub/path/
的对象。若返回为404,确认Server端不存在该子路径。
您可以通过ossutil、SDK、OSS控制台等工具手动创建缺失的Bucket或子目录,然后重新挂载。
ossfs1.91+版本不强制要求挂载目录存在,您也可以通过升级ossfs版本解决该问题。更多信息,请参见ossfs 1.91及以上版本新功能介绍及性能压测。若升级后挂载仍出现问题,请参见本问题原因6。
原因2解决方案:
确认挂载使用的RAM用户或RAM角色的策略权限包括步骤二:为demo-role-for-rrsa角色授权中列举的权限。
确认挂载点根路径及subpath路径的文件系统权限,详情请参考OSS存储挂载权限问题中的场景1和场景6。
对于通过RAM用户AccessKey鉴权方式挂载的存储卷,确认挂载时使用的AccessKey是否被禁用或已轮转,详情请参考OSS存储挂载权限问题中的场景4.
对于通过RRSA鉴权方式挂载的存储卷,确认是否为RAM角色配置正确的信任策略。信任策略的配置请参考步骤一:创建RAM角色。默认情况下,信任的ServiceAccount为ack-csi-fuse命名空间下的csi-fuse-ossfs,而非业务使用的ServiceAccount。
RRSA鉴权方式挂载仅支持1.26及以上版本的集群,即ACK托管集群、ACK Serverless集群,且集群使用的CSI组件为1.30.4及以上版本。若您在1.30.4之前的版本中使用了RRSA功能,请及时参见【产品变更】CSI ossfs版本升级与挂载流程优化增加RAM角色授权配置。
原因3解决方案:
执行以下命令,确认OSSFS所在Pod存在。其中PV_NAME
为挂载的OSS PV名称,NODE_NAME
为需挂载存储卷的业务Pod所在的节点名称。
kubectl -n ack-csi-fuse get pod -l csi.alibabacloud.com/volume-id=<PV_NAME> -owide | grep <NODE_NAME>
若Pod存在且状态异常,请排查Pod的异常原因,确保Pod正常Running后重启业务Pod触发重新挂载。若Pod不存在,请按后续步骤继续排查。
(可选)通过查询审计日志等方式确认Pod是否被意外删除,常见的意外删除原因包括业务脚本清理、节点排水、节点自愈等。建议您做相关调整,避免问题重现。
确认CSI provisioner与CSI plugin均升级到1.30.4及以上后:
执行以下步骤,确认是否残留VolumeAttachment资源
kubectl get volumeattachment | grep <PV_NAME> | grep <NODE_NAME>
若有,请删除该VolumeAttachment资源。
重启业务Pod触发重新挂载,并确认OSSFS Pod有正常创建流程。
原因4解决方案:
建议您将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包,请提交工单处理。
原因5解决方案:
若您手动安装过ossfs工具,请检查适配的操作系统与节点是否一致。
若您升级过集群的节点操作系统,可以执行以下指令重启csi-plugin,更新ossfs版本后再尝试挂载。
kubectl -n kube-system delete pod -l app=csi-plugin
建议您升级CSI至1.28或以上版本,挂载OSS存储卷时ossfs以容器的方式运行在集群中,对节点操作系统无要求。
若您的集群无法升级CSI版本,可以切换至符合要求的OS或手动安装缺少的动态库,以Ubuntu节点为例:
使用which指令,查询当前ossfs的安装位置(默认安装路径为/usr/local/bin/ossfs
)。
which ossfs
使用ldd指令,查询ossfs缺失的动态库文件。
ldd /usr/local/bin/ossfs
使用apt-file指令,查询缺失的动态库文件(如libcrypto.so.10)所属的Package。
apt-get install apt-file
apt-file update
apt-file search libcrypto.so.10
使用apt-get指令安装对应Package(如libssl.1.0.0)。
apt-get install libssl1.0.0
原因6解决方案:
推荐方案:升级CSI版本至v1.32.1-35c87ee-aliyun以上。
其他方案1:参考本问题原因1,确认子目录是否存在。
其他方案2:若业务长期需要挂载子目录,建议将权限范围扩大到整个Bucket。
原因7解决方案:
您需要同步源站数据后,再进行挂载。更多信息,请参见回源。
原因8解决方案:
您需要关闭或调整静态网站托管的配置,再进行挂载。更多信息,请参见静态网站托管。
OSS存储卷通过ossfs工具将OSS的某个路径以文件系统的形式挂载到Pod中,ossfs本身并不支持挂载文件。若您希望在Pod中仅能看到OSS中的某个文件,可通过subPath的方式实现:
假设需要挂载的OSS中bucket:/subpath下的a.txt和b.txt文件到两个不同的Pod中,在Pod中的存放路径分别为/path/to/file/,可参考以下YAML创建对应的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
volumeAttributes:
bucket: bucket
path: subpath #subpath为a.txt与b.txt的父路径
url: "oss-cn-hangzhou.aliyuncs.com"
创建对应的PVC后,Pod中挂载PVC相应的VolumeMounts配置为:
volumeMounts:
- mountPath: /path/to/file # bucket:/subpath对应Pod中的挂载路径
name: oss-pvc # 与Volumes中的名称一致
subPath: a.txt # 或者b.txt,bucket:/subpath中文件的相对路径
挂载后,Pod中访问a.txt的完整路径为/path/to/file/a.txt
,实际访问的是bucket:/subpath/a.txt。
OSS存储卷的基本使用说明请参考使用OSS静态存储卷。
以上示例中,ossfs在节点上的挂载点对应的实际OSS路径为bucket:/subpath,对于节点上的文件扫描等进程,或以非subPath形式挂载的Pod而言,可见的内容仍为bucket:/subpath。
对于非root用户运行的容器需要注意subPath的权限配置,详情请参考使用subpath或subpathExpr方式挂载OSS存储卷异常
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。
在OSS静态卷PV的otherOpts
字段中增加-o listobjectsv2
来解决。
原因3解决方案:
您需要修改存储类型或者解冻文件。
容器内挂载OSS数据卷时,在文件中写入数据,但在OSS控制台看到文件大小为0。
容器使用ossfs挂载OSS,即基于FUSE方式挂载OSS的Bucket,只有在文件执行close或者flush时,文件内容才会上传至OSS的服务端。
使用lsof+文件名称的方式,查看当前文件是否被其他进程占用,关闭相应进程,释放文件fd。关于lsof更多信息,请参见lsof。
容器内挂载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静态卷解决问题。
在容器内挂载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类型,导致浏览器或其他客户端未能够正确识别和处理这些文件。
未指定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存储卷生效。更多信息,请参见常见问题。
集群级别配置:该方式对集群所有新挂载的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存储卷。
通过RRSA方式的OSS存储卷鉴权时,无法满足例如使用第三方OIDC身份提供商、使用非默认ServiceAccount等需求。
此时,您只需要在PV中通过roleName配置项指定RAM角色名称,即可由CSI存储插件获取默认的Role ARN及OIDC Provider ARN。若您需要实现定制化的RRSA鉴权,则需要更改PV的配置信息如下:
其中,roleArn
与oidcProviderArn
需要一起配置,配置后无需再配置roleName
。
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: "csi-fuse-<service-account-name>"
参数 | 说明 |
参数 | 说明 |
oidcProviderArn | OidcProviderArn需要在创建OIDC身份提供商后获取。更多信息,请参见管理OIDC身份提供商。 |
roleArn | RoleArn需要在创建可信实体为上述OIDC身份提供商的RAM角色后获取。更多信息,请参见使用OIDC进行角色SSO的示例。 |
serviceAccountName | 可选,ossfs容器所在的Pod使用ServiceAccount名称,需要预先创建。 配置为空时,使用CSI维护的默认ServiceAccount。 重要 ServiceAccount名称必须以csi-fuse-开头。 |
创建硬链接时返回错误Operation not supported或Operation not permitted。
OSS存储卷不支持硬链接操作,将返回Operation not supported错误。在早期的CSI版本中,硬链接操作返回的报错为Operation not permitted。
改造业务,在使用OSS存储卷时,应避免硬链接操作。若您的业务必须使用硬链接操作,建议您更换存储。
OSS静态卷卸载失败,Pod一直处于Terminating状态。
Pod删除时卡在Terminating的原因较多,可先借助kubelet日志定位。导致OSS存储卷卸载失败的常见原因如下:
原因1:对应挂载点在节点上被占用,CSI存储插件无法正常unmount挂载点。
原因2:PV中指定的OSS bucket或目录(path)被删除,无法判断当前挂载点状态。
原因1解决方案
在集群中执行以下命令,获取Pod的UID。
替换以下<ns-name>和<pod-name>为您的业务实际值。
kubectl -n <ns-name> get pod <pod-name> -ogo-template --template='{{.metadata.uid}}'
预期输出:
5fe0408b-e34a-497f-a302-f77049****
登录Terminating的Pod所在的节点。
在节点上执行以下命令,查询当前是否有进程占用挂载点。
lsof /var/lib/kubelet/pods/<pod-uid>/volumes/kubernetes.io~csi/<pv-name>/mount/
若有输出,请确认并清理相关进程。
原因2解决方案
登录OSS管理控制台。
查询Bucket或目录是否被删除,若您使用了subpath方式挂载OSS存储卷,还需要确认subpath挂载目录是否被删除。
确认上由于删除目录导致的卸载失败,请参考以下操作处理。
在集群中执行以下命令,获取Pod的UID。
替换以下<ns-name>和<pod-name>为您的业务实际值。
kubectl -n <ns-name> get pod <pod-name> -ogo-template --template='{{.metadata.uid}}'
预期输出:
5fe0408b-e34a-497f-a302-f77049****
登录Terminating的Pod所在的节点,在节点上执行以下命令,查询Pod相关的挂载点。
mount | grep <pod-uid> | grep fuse.ossfs
预期输出:
ossfs on /var/lib/kubelet/pods/<pod-uid>/volumes/kubernetes.io~csi/<pv-name>/mount type fuse.ossfs (ro,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other)
ossfs on /var/lib/kubelet/pods/<pod-uid>/volume-subpaths/<pv-name>/<container-name>/0 type fuse.ossfs (ro,relatime,user_id=0,group_id=0,allow_other)
其中ossfs on
与type
之间路径为节点上的实际挂载点。
手动umount挂载点。
umount /var/lib/kubelet/pods/<pod-uid>/volumes/kubernetes.io~csi/<pv-name>/mount
umount /var/lib/kubelet/pods/<pod-uid>/volume-subpaths/<pv-name>/<container-name>/0
等待kubelet重试时正常回收,或者直接通过--force
删除Pod。
其他卸载失败问题,请提交工单咨询。
检测长期卡住,或失败无信息透出,或显示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>
如果您的相关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。
访问OSS Bucket超时,可能的超时原因如下
选择的Bucket与集群不在同一地域时,选择私有域名,导致访问不通。
选择公有域名,但集群无公网访问能力,导致访问不通。
重建PV,并选择公有域名。
若您的集群与Bucket在同一地域,可重建PV并选择私有域名。否则,您可以检查安全组、网络等相关配置,修复后再重建PV。
错误信息为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的读权限。
错误信息为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端不一定真实存在,以ossutil或OSS API的返回为准。例如,直接创建/a/b/c/
目录,/a/b/c/
为单独的目录对象,而/a/
或/a/b/
目录对象实际并不存在。同理,如上传/a/*
文件,/a/b
、/a/c
等为单独的文件对象,/a/
目录对象不存在。
通过ossutil、SDK、OSS控制台等工具手动创建缺失的Bucket或子目录,然后重建PV。
错误信息为service returned error: StatusCode=xxx
。
当访问OSS出现错误时,OSS会返回StatusCode、ErrorCode、ErrorMessage等信息,方便您定位并解决问题。
当您遇到其他OSS的StatusCode或ErrorCode时,请参见HTTP错误码解决。
同一节点上挂载了相同OSS存储卷的多个Pod共享挂载点。
ossfs容器化前,默认使用独享方式挂载,即每个挂载OSS存储卷的Pod,都将在对应节点上为该存储卷拉起ossfs进程。不同ossfs进程对应的挂载点之间完全独立,即对于挂载了同一OSS存储卷的不同Pod在读写时互不影响。
ossfs容器化后,ossfs进程将以容器的方式运行在集群的Pod中,具体为kube-system
或ack-csi-fuse
命名空间的csi-fuse-ossfs-*
Pod。在多挂载的场景下,独享方式挂载将在集群中拉起大量Pod,进而导致弹性网卡不足等问题。因此,容器化后将默认使用共享方式挂载,即同一节点上挂载了相同OSS存储卷的多个Pod共享挂载点,均对应同一个csi-fuse-ossfs-*
Pod,实际由同一ossfs进程实现挂载。
1.30.4及以上版本CSI不再支持开启独享挂载模式,如果您需要重启或变更ossfs的相关配置,可以参考共享挂载方式下,如何重启ossfs进程?如果您有其他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进程(容器化版本后,即为kube-system
或ack-csi-fuse
命名空间下的csi-fuse-ossfs-*
Pod)与对应的应用Pod,造成业务中断。因此,默认情况下CSI不会对已经运行的ossfs进行变更。
正常使用流程中,ossfs的部署与删除均由CSI完成。手动删除ossfs进程所在的Pod,无法触发CSI的部署流程。
重启ossfs进程的流程中需要重启挂载对应OSS存储卷的业务Pod,请谨慎操作。
若您使用的是非容器化的CSI版本,或开启了独享挂载,可以直接重启对应的应用Pod。容器化版本后,默认使用共享挂载方式,即每个节点上挂载同一OSS存储卷的所有应用Pod共用ossfs进程实现挂载。
确认当前FUSE Pod被哪些应用Pod使用。
执行以下命令,确认需要变更的csi-fuse-ossfs-*
Pod。
其中<pv-name>
为PV名称,<node-name>
为节点名称。
CSI版本小于1.30.4时,执行以下操作:
kubectl -n kube-system get pod -lcsi.alibabacloud.com/volume-id=<pv-name> -owide | grep <node-name>
CSI版本大于等于1.30.4时,执行以下操作
kubectl -n ack-csi-fuse 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 cn-beijing.192.168.XX.XX
预期输出:
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能同时被删除(如删除Deployment, StatefulSet, DaemonSet管理的Pod均会立即触发重启),或Pod能容忍OSS读写失败:
CSI版本小于1.30.4时,您可以直接删除csi-fuse-ossfs-xxxx
Pod,此时应用Pod内读写OSS将返回disconnected error
。
CSI版本大于等于1.30.4时,您可以执行以下操作:
kubectl get volumeattachment | grep <pv-name> | grep cn-beijing.192.168.XX.XX
预期输出:
csi-bd463c719189f858c2394608da7feb5af8f181704b77a46bbc219b********** ossplugin.csi.alibabacloud.com <pv-name> cn-beijing.192.168.XX.XX true 12m
直接删除该VolumeAttachment,此时应用Pod内读写OSS将返回disconnected error
。
然后,逐个重启业务Pod,重启后的Pod将通过CSI新建的csi-fuse-ossfs-yyyy
Pod恢复OSS读写。
调用OSS的操作记录统一在OSS管理控制台查看,且要求已开通OSS的日志查询功能。关于开通日志查询的操作,请参见开通实时日志查询。
登录OSS管理控制台。
单击Bucket 列表,然后单击目标Bucket名称。
在左侧导航栏,选择日志管理 > 实时查询。
在实时查询页签下,根据查询语法和分析语法,输入查询和分析语句,对OSS日志进行分析。您可以通过user_agent和client_ip字段定位日志是否来源于ACK。
定位由ACK发送的OSS操作请求时,您需要选择user_agent字段,展开后看到user_agent里包含ossfs的都可以选择。
user-agent字段的取值与ossfs版本有关,ossfs版本不同,user-agent字段的值也不一样,但均以aliyun-sdk-http/1.0()/ossfs
开头。
如果您在ECS上也通过ossfs挂载,相关日志也会被耦合到这里。
如需定位到某个ECS实例或集群,您还可以选择client_ip字段,然后选择对应的IP。
结合以上两个字段选择,查询到的日志示例如下图所示。
使用subpath或subpathExpr方式挂载OSS存储卷时,出现以下异常:
挂载失败:挂载OSS存储卷的Pod创建后,一直处在CreateContainerConfigError状态,并且出现如下类似Event。
Warning Failed 10s (x8 over 97s) kubelet Error: failed to create subPath directory for volumeMount "pvc-oss" of container "nginx"
读写异常:挂载OSS存储卷进行OSS读写操作时,出现权限不足的报错提示Operation not permitted
或Permission denied
。
卸载失败:删除挂载了OSS存储卷的Pod时,一直处在Terminating状态。
为方便阐述原因及解决方案,假设:
PV的相关配置为:
...
volumeAttributes:
bucket: bucket-name
path: /path
...
Pod的相关配置为:
...
volumeMounts:
- mountPath: /path/in/container
name: oss-pvc
subPath: subpath/in/oss
...
则OSS服务端subpath挂载目录为Bucket中的/path/subpath/in/oss/
。
原因1:OSS服务端不存在挂载目录/path/subpath/in/oss/
,且OSS存储卷使用的用户或角色未被授权PutObject权限(例如只读场景中仅配置了OSS ReadOnly权限)。
kubelet尝试在OSS服务端创建/path/subpath/in/oss/
目录时因权限不足失败。
原因2:非root用户运行的业务容器没有/path/subpath/in/oss/
目录下文件的权限(默认为640)。subpath方式挂载OSS存储卷时,ossfs在OSS服务端实际的挂载目录为PV中定义的path目录,即上述示例中的/path
,而非/path/subpath/in/oss/
。配置allow_other或mp_umask挂载项仅对/path
目录生效,/path/subpath/in/oss/
目录作为子目录仍默认为640。
原因3:OSS服务端中/path/subpath/in/oss/
挂载目录被删除,阻塞kubelet回收subpath路径,导致卸载失败。
原因1解决方案:
在OSS服务端预先创建/path/subpath/in/oss/
目录,提供kubelet挂载subpath路径。
若需要创建的目录较多(例如通过subpathExpr方式挂载OSS存储卷),无法全部预先创建时,可为OSS存储卷使用的用户或角色增加putObject权限授权。
原因2解决方案:通过umask配置项修改子目录默认权限,例如-o umask=000
将默认权限修改为777。
原因3解决方案:请参见OSS静态卷卸载失败,Pod一直处于Terminating状态中的原因2解决方案。
OSS本身不限制Bucket或子路径的容量,也未提供容量限额功能。因此pv.spec.capacity
与pvc.spec.resources.requests.storage
配置均不起作用。您只需保证需要绑定PV、PVC配置的容量相等即可。
实际存储超出此配置时,不影响正常使用,也无需扩容存储卷。