当应用需要持久化存储,或多Pod间共享数据时,可通过静态PV和PVC的方式,将OSS Bucket 挂载为 ossfs 2.0 存储卷。这让应用容器可以像访问本地文件系统一样,使用标准的POSIX接口读写OSS数据,适用于大数据分析、AI训练、静态资源访问等场景。
相较于ossfs 1.0,ossfs 2.0在顺序读写性能上表现优异,可以更好地利用OSS的高带宽优势。
ossfs 2.0的性能说明,请参见ossfs 2.0客户端压测性能。
流程指引
在ACK集群中挂载ossfs 2.0静态存储卷主要流程如下。
|
适用范围
集群为1.26及以上,CSI组件(csi-plugin和csi-provisioner)版本为v1.33.1及以上。如需升级集群,请参见手动升级集群;如需升级组件,请参见升级csi-plugin和csi-provisioner。
已创建OSS Bucket,且Bucket与集群属于同一阿里云账号。
如需跨账号挂载OSS Bucket,建议通过RRSA鉴权方式实现,请参见如何跨账号挂载OSS Bucket?。
步骤一:选择鉴权方式(RRSA或AccessKey)并准备访问凭证
为确保集群能够安全、合规地访问OSS Bucket资源,需先配置一种鉴权机制。
RRSA鉴权方式:为 Pod 动态授予临时、自动轮换的 RAM 角色,实现应用级别的精细化权限隔离,安全性较高。
AccessKey鉴权方式:将静态、长期的密钥存储在 Secret 中。配置简单,但安全性较低。
在1.26及以上版本的集群中,为避免因AccessKey轮转导致的ossfs重挂载和业务重启,建议使用RRSA鉴权方式。
本示例中集群与OSS Bucket处于同一阿里云账号下。如需跨账号挂载OSS Bucket,建议使用RRSA鉴权方式。
RRSA方式
1. 在集群中启用RRSA
在ACK集群列表页面,单击目标集群名称,选择集群信息。
在基本信息页签的安全与审计区域,单击RRSA OIDC右侧的开启,按照页面提示在业务低峰期完成RRSA的启用。
当集群状态由更新中变为运行中,表明RRSA已成功启用。
重要启用RRSA功能后,集群内新创建的ServiceAccount Token的最大有效期将限制为12小时。
2. 创建RAM角色并授权
创建一个供 Pod 扮演的 RAM 角色,以通过 RRSA 鉴权来访问 OSS 存储卷。
AccessKey方式
创建具有OSS访问权限的RAM用户并获取其AccessKey,使其拥有OSS Bucket的操作权限。
创建RAM用户(如有,可跳过)。
访问RAM控制台-创建用户页面,按照页面提示完成RAM用户的创建,如登录名称、密码等。
创建权限策略。
本示例遵循最小权限原则,创建一个自定义权限策略,授予访问目标OSS Bucket的权限(OSS只读权限或OSS读写权限)。
访问RAM控制台-创建权限策略页面,切换为脚本编辑,按照页面提示配置策略脚本。
OSS只读权限策略
替换
<myBucketName>为实际Bucket名称。{ "Statement": [ { "Action": [ "oss:Get*", "oss:List*" ], "Effect": "Allow", "Resource": [ "acs:oss:*:*:<myBucketName>", "acs:oss:*:*:<myBucketName>/*" ] } ], "Version": "1" }OSS读写权限策略
替换
mybucket为实际Bucket名称。{ "Statement": [ { "Action": "oss:*", "Effect": "Allow", "Resource": [ "acs:oss:*:*:<myBucketName>", "acs:oss:*:*:<myBucketName>/*" ] } ], "Version": "1" }使用控制台创建PV时,还需拥有
oss:ListBuckets权限。{ "Effect": "Allow", "Action": "oss:ListBuckets", "Resource": "*" }(可选)使用KMS托管的指定CMK ID加密OSS Object时,还需为该RAM用户配置KMS权限,详见使用KMS托管的指定CMK ID加密。
将该策略授权给RAM用户。
访问RAM控制台-用户页面,在RAM用户列表的操作列,单击目标用户对应的添加权限。
在权限策略区域,按照页面提示搜索并选择上一步创建的权限策略,并完成授权的新增。
为RAM用户创建AccessKey,以便后续将其存储为Secret,供PV使用。
访问RAM控制台-用户页面,在RAM用户列表单击目标用户,然后在AccessKey区域,单击创建 AccessKey。
按照页面提示,在对话框进行AccessKey的创建,获取并妥善保管其AccessKey ID和AccessKey Secret。
步骤二:创建PV
创建PV,在集群中“注册”已有的OSS Bucket。
RRSA方式
创建
ossfs2-pv.yaml。以下PV将名为
cnfs-oss-test的 OSS Bucket挂载为一个 20GB 的只读文件系统,供集群内的 Pod 使用。apiVersion: v1 kind: PersistentVolume metadata: # PV名称 name: pv-ossfs2 spec: capacity: # 定义存储卷容量 (此值仅用于匹配PVC) storage: 20Gi # 访问模式 accessModes: - ReadOnlyMany persistentVolumeReclaimPolicy: Retain csi: # 使用ossfs 2.0客户端时固定为此值 driver: ossplugin.csi.alibabacloud.com # 与PV名称(metadata.name)保持一致 volumeHandle: pv-ossfs2 volumeAttributes: fuseType: ossfs2 # OSS Bucket名称 bucket: oss-test # 挂载Bucket的根目录或指定子目录 path: / # OSS Bucket所在地域的Endpoint url: "http://oss-cn-hangzhou-internal.aliyuncs.com" otherOpts: "-o close_to_open=false" authType: "rrsa" # 此前创建或修改的RAM角色 roleName: "demo-role-for-rrsa"主要参数说明如下:
参数
是否必选
说明
fuseType必选
使用ossfs 2.0客户端时,固定为
ossfs2。bucket必选
待挂载的OSS Bucket。
path可选
待挂载的OSS Bucket的子目录。不填写时默认挂载Bucket根目录。
url必选
待挂载OSS的访问域名(Endpoint)。
挂载节点和Bucket处于相同地域,或已打通VPC网络时,使用内网地址。
挂载节点和Bucket不同地域时,使用外网地址。
不同访问端口的常见填写格式如下:
内网格式:
http://oss-{{regionName}}-internal.aliyuncs.com或https://oss-{{regionName}}-internal.aliyuncs.com。内网访问端口格式
vpc100-oss-{{regionName}}.aliyuncs.com已废弃,请及时切换。外网格式:
http://oss-{{regionName}}.aliyuncs.com或https://oss-{{regionName}}.aliyuncs.com。
otherOpts可选
为OSS存储卷输入定制化参数,格式为
-o *** -o ***,例如-o close_to_open=false。close_to_open:默认为关闭。开启后,每次打开文件时,系统会主动向OSS发送GetObjectMeta请求,以获取文件在OSS中的最新元数据信息,从而确保元数据的实时性。但在需要大量读取小文件的场景下,频繁的元数据查询会显著增加访问延迟。更多可选参数,请参见ossfs 2.0挂载选项说明。
authType必选
配置为
rrsa,使用RRSA方式鉴权。roleName必选
配置为此前创建或修改的RAM角色名称。
如需为不同PV配置不同权限,可创建不同的RAM角色,并在PV中配置不同的
roleName。sigVersion可选
请求OSS服务端的请求签名版本。
若默认的RRSA鉴权不满足需求(如使用非默认ServiceAccount或第三方OIDC),可通过修改PV配置来指定具体的ARN或ServiceAccount,详见如何在RRSA鉴权方式中使用指定的ARNs或ServiceAccount?。
创建PV。
kubectl create -f ossfs2-pv.yaml确认PV状态。
kubectl get pv pv-ossfs2预期输出如下,确认PV的状态为
Available。NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS VOLUMEATTRIBUTESCLASS REASON AGE pv-ossfs2 20Gi ROX Retain Available <unset> 15s
AccessKey方式
将步骤一获取的AccessKey存储为Secret,供PV使用。
将
<yourAccessKeyID>和<yourAccessKeySecret>替换为真实凭证。Secret的Namespace需要和应用Namespace一致。kubectl create -n default secret generic oss-secret --from-literal='akId=<yourAccessKeyID>' --from-literal='akSecret=<yourAccessKeySecret>'创建
ossfs2-pv.yaml。以下PV将名为
cnfs-oss-test的 OSS Bucket挂载为一个 20GiB 的只读文件系统。apiVersion: v1 kind: PersistentVolume metadata: # PV名称 name: pv-ossfs2 spec: capacity: # 定义存储卷容量 (此值仅用于匹配PVC) storage: 20Gi # 访问模式 accessModes: - ReadOnlyMany persistentVolumeReclaimPolicy: Retain csi: driver: ossplugin.csi.alibabacloud.com # 与PV名称(metadata.name)保持一致 volumeHandle: pv-ossfs2 # 使用此前创建的Secret nodePublishSecretRef: # 存储AK信息的Secret名称 name: oss-secret # 该Secret所在的命名空间 namespace: default volumeAttributes: fuseType: ossfs2 # 替换为实际Bucket名称 bucket: cnfs-oss-test # 待挂载的子目录,留空则挂载根目录 path: / # OSS Bucket所在地域的Endpoint url: "http://oss-cn-hangzhou-internal.aliyuncs.com" otherOpts: "-o close_to_open=false"nodePublishSecretRef参数说明:参数
是否必选
说明
name必选
存储AccessKey信息的Secret名称。
namespace必选
存储AccessKey信息的Secret所在的命名空间。
volumeAttributes参数说明:参数
是否必选
说明
fuseType必选
使用ossfs 2.0客户端时,固定为
ossfs2。bucket必选
待挂载的OSS Bucket。
path可选
待挂载的OSS Bucket的子目录。不填写时默认挂载Bucket根目录。
url必选
待挂载OSS的访问域名(Endpoint)。
挂载节点和Bucket处于相同地域,或已打通VPC网络时,使用内网地址。
挂载节点和Bucket不同地域时,使用外网地址。
不同访问端口的常见填写格式如下:
内网格式:
http://oss-{{regionName}}-internal.aliyuncs.com或https://oss-{{regionName}}-internal.aliyuncs.com。内网访问端口格式
vpc100-oss-{{regionName}}.aliyuncs.com已废弃,请及时切换。外网格式:
http://oss-{{regionName}}.aliyuncs.com或https://oss-{{regionName}}.aliyuncs.com。
otherOpts可选
为OSS存储卷输入定制化参数,格式为
-o *** -o ***,例如-o close_to_open=false。close_to_open:默认为关闭。开启后,每次打开文件时,系统会主动向OSS发送GetObjectMeta请求,以获取文件在OSS中的最新元数据信息,从而确保元数据的实时性。但在需要大量读取小文件的场景下,频繁的元数据查询会显著增加访问延迟。更多可选参数,请参见ossfs 2.0挂载选项说明。
创建PV。
kubectl create -f ossfs2-pv.yaml确认PV状态。
kubectl get pv pv-ossfs2预期输出如下,确认PV的状态为
Available。NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS VOLUMEATTRIBUTESCLASS REASON AGE pv-ossfs2 20Gi ROX Retain Available <unset> 15s
步骤三:创建PVC
创建PVC,为应用声明其所需的持久化存储容量。
创建
ossfs2-pvc.yaml。kind: PersistentVolumeClaim apiVersion: v1 metadata: # PVC名称 name: pvc-oss namespace: default spec: # 配置访问模式。ReadOnlyMany表明ossfs将以只读模式挂载OSS Bucket accessModes: - ReadOnlyMany resources: requests: # 声明存储容量,不能大于存储卷总量 storage: 20Gi #待绑定的PV volumeName: pv-ossfs2创建PVC。
kubectl create -f ossfs2-pvc.yaml确认PVC状态。
kubectl get pvc pvc-oss输出中,PVC已绑定(Bound)PV。
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS VOLUMEATTRIBUTESCLASS AGE pvc-oss Bound pv-ossfs2 20Gi ROX <unset> 74s
步骤四:创建应用并挂载存储卷
在应用中引用PVC,完成挂载。
(可选)为存储卷启用监控能力。
ossfs 2.0 存储卷的监控能力正在灰度发布中。如需启用监控能力,需在挂载存储卷前按如下流程启用。
此监控配置仅对新挂载的存储卷生效。如需为已挂载的存储卷启用,需重启应用 Pod,并确认ack-csi-fuse命名空间下的ossfs2 Pod已重建。
创建应用并挂载。
创建oss-workload.yaml。
apiVersion: apps/v1 kind: Deployment metadata: name: oss-workload labels: app: nginx spec: replicas: 2 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6 ports: - containerPort: 80 volumeMounts: # 容器内的挂载路径 - name: pvc-oss mountPath: "/data" # 配置健康检查 livenessProbe: exec: command: - ls - /data initialDelaySeconds: 30 periodSeconds: 30 volumes: - name: pvc-oss persistentVolumeClaim: # 引用此前创建的PVC claimName: pvc-oss创建应用。
kubectl create -f oss-workload.yaml验证挂载结果。
确认Pod处于Running状态。
kubectl get pod -l app=nginx进入Pod,查看挂载点。
kubectl exec -it <pod-name> -- ls /data输出中,可查看OSS挂载路径下的数据。
步骤五:验证共享存储和持久化存储
验证共享存储
在一个Pod中创建文件,然后在另一个Pod中查看,以验证共享存储特性。
查看Pod信息,在输出中获取Pod名称。
kubectl get pod -l app=nginx在一个Pod中创建tmpfile文件。 以名为
oss-workload-66fbb85b67-d****的Pod为例:在另一个Pod挂载路径下查看文件。
以名为
oss-workload-66fbb85b67-l****、挂载路径为data的Pod为例。kubectl exec oss-workload-66fbb85b67-l**** -- ls /data | grep tmpfile预期输出如下,Pod挂载路径下均存在此文件,表明两个Pod可共享数据。
tmpfile若无预期输出,请确认CSI组件版本是否为v1.20.7及以上版本。
验证持久化存储
删除并重建Pod,在新建的Pod中查看文件是否存在,验证数据的持久化存储。
删除一个应用Pod以触发重建。
kubectl delete pod oss-workload-66fbb85b67-d****查看Pod,等待新Pod启动并进入Running状态。
kubectl get pod -l app=nginx查看
/data路径下的文件。以名为
oss-workload-66fbb85b67-z****、挂载路径为data的Pod为例。kubectl exec oss-workload-66fbb85b67-z**** -- ls /data | grep tmpfile预期输出如下,tmpfile文件仍存在,表明数据可持久化存储。
tmpfile
功能已知影响
读写场景:ossfs 2.0 主要适用于只读和顺序追加写场景。对于需要随机写的场景,建议使用 ossfs 1.0。
数据同步与误删风险:挂载状态下,在应用Pod或宿主机上对挂载路径下的文件删除或变更操作会直接同步到OSS Bucket源文件。为避免数据误删除,建议为OSS Bucket开启版本控制。
应用健康检查:建议为使用OSS存储卷的Pod配置健康检查(Liveness Probe),例如检查挂载目录是否可用。当挂载异常时,可自动重启Pod以恢复。
碎片成本:当传输文件大于10 MB时,ossfs会将文件分片上传。若上传因业务自身重启等特殊原因意外中断,请手动删除碎片或通过生命周期规则删除碎片,避免碎片占用存储空间并产生费用。
密钥失效风险(AccessKey鉴权方式):若PV引用的AccessKey失效或权限变更,关联应用会立即失去访问权限。
恢复访问需更新Secret中的凭证,并重启应用Pod以强制重新挂载(将导致业务中断),请在维护窗口期执行。详见解决方案。
生产环境使用建议
维度 | 说明 |
安全与权限管理 |
|
性能与成本优化 |
|
运维管理 |
相关文档
如在使用ossfs 2.0存储卷时遇到挂载、扩容等使用问题,可参见ossfs 2.0存储卷FAQ排查。
关于CSI组件的变更记录,请参见csi-provisioner、csi-plugin。