Container Service for Kubernetes:Mount a static OSS volume using ossfs 1.0

RRSA

AccessKey

Use RRSA

1. Create a file named pv-oss-rrsa.yaml.

   apiVersion: v1
   kind: PersistentVolume
   metadata:
     # The PV name.
     name: pv-oss   
     # The PV labels.
     labels:    
       alicloud-pvname: pv-oss
   spec:
     capacity:
       # The capacity of the persistent volume.
       storage: 10Gi  
     # The access mode.
     accessModes:  
       - ReadOnlyMany
     persistentVolumeReclaimPolicy: Retain
     csi:
       driver: ossplugin.csi.alibabacloud.com
       # Must be the same as the PV name (metadata.name).
       volumeHandle: pv-oss  
       volumeAttributes:
         # Replace with your bucket name.
         bucket: "your-bucket-name"  
         # The root directory or a subdirectory of the bucket to mount.
         path: /  
         # The endpoint of the region where the bucket is located.
         url: "http://oss-cn-hangzhou-internal.aliyuncs.com"  
         otherOpts: "-o umask=022 -o max_stat_cache_size=100000 -o allow_other"
         authType: "rrsa"
         # The RAM role that you previously created or modified.
         roleName: "demo-role-for-rrsa"
         # The signature version for OSS requests.
         sigVersion: "v4"  

   Parameter	Description
   storage	The capacity of the OSS persistent volume. This value is used only to match the PV with a PVC.
   accessModes	Specifies the access mode. Valid values include ReadOnlyMany and ReadWriteMany. If you set this parameter to ReadOnlyMany, ossfs mounts the OSS bucket in read-only mode.
   persistentVolumeReclaimPolicy	The reclaim policy of the PV. OSS persistent volumes support only Retain. This means that when a PVC is deleted, the PV and the data in the OSS bucket are retained.
   driver	The driver type. When you use the Alibaba Cloud OSS CSI plugin, set this field to ossplugin.csi.alibabacloud.com.
   volumeHandle	Must be the same as the PV name specified in metadata.name.
   bucket	The OSS bucket to mount.
   path	The version of the CSI component must be v1.14.8.32-c77e277b-aliyun or later. The mount path relative to the root directory of the bucket. The default value is /, which mounts the entire bucket. If the ossfs version is earlier than 1.91, the specified path must exist in the OSS bucket. For more information, see New features in ossfs 1.91 and later.
   url	The access endpoint for the OSS bucket. Use an internal endpoint if your cluster nodes and the bucket are in the same region, or if a Virtual Private Cloud (VPC) connection is established. Use a public endpoint if the mount node and the bucket are in different regions. The following are common formats for different access endpoints: Internal: http://oss-{{regionName}}-internal.aliyuncs.com or https://oss-{{regionName}}-internal.aliyuncs.com. Note The internal access endpoint format vpc100-oss-{{regionName}}.aliyuncs.com is deprecated. Switch to the new format as soon as possible. Public: http://oss-{{regionName}}.aliyuncs.com or https://oss-{{regionName}}.aliyuncs.com.
   otherOpts	Custom parameters for the OSS persistent volume, in the format of -o *** -o ***. For example: -o umask=022 -o max_stat_cache_size=100000 -o allow_other. Expand for details umask: Sets the permission mask for files and directories. For example, umask=022 changes the file permissions to 755. This resolves the permission issue for files that are uploaded by using other methods, such as SDKs or the OSS console, which have a default permission of 640. We recommend that you configure this parameter for read/write splitting or multi-user access. max_stat_cache_size: Sets the upper limit of metadata cache entries, for example, 100000. Metadata is cached in memory to improve the performance of operations such as ls and stat. However, this cache cannot immediately detect file modifications made through the OSS console, SDKs, or ossutil. This may cause applications to read inconsistent data. If you have strict data consistency requirements, set this parameter to 0 to disable the cache, or reduce the cache expiration time by using the stat_cache_expire parameter. This, however, may reduce read performance. allow_other: Allows users other than the user who mounted the volume to access files and directories in the mount path. This is suitable for multi-user shared environments where non-mounting users also need to access data. For more information about optional parameters, see Mount options and Best practices for configuring ossfs 1.0.
   authType	Set this parameter to rrsa to use RRSA for authentication.
   roleName	The RAM role that you previously created or modified. To configure different permissions for different PVs, you can create different RAM roles and specify different roleName values in the PVs.
   sigVersion	The signature version for requests sent to the OSS server. "v1" (Default): Uses OSS Signature Version 1. "v4" (Recommended): Uses OSS Signature Version 4.

   If the default RRSA authentication does not meet your requirements (for example, if you use a non-default ServiceAccount or a third-party OIDC), you can modify the PV configuration to specify a specific ARN or ServiceAccount. For more information, see How do I use specified ARNs or ServiceAccounts with RRSA authentication?.

2. Create the PV.

   kubectl create -f pv-oss-rrsa.yaml

Use an AccessKey

kubectl

1. Create a file named pvc-oss.yaml.

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     # The name of the PVC.
     name: pvc-oss
     namespace: default
   spec:
     # Configure the access mode. ReadOnlyMany indicates that ossfs mounts the OSS bucket in read-only mode.
     accessModes:
       - ReadOnlyMany
     resources:
       requests:
         # The requested storage capacity. This value cannot exceed the capacity of the PersistentVolume.
         storage: 10Gi
     # Add this line to explicitly specify that no StorageClass is used.
     storageClassName: ""   
     selector:
       matchLabels:
         # Match the PV by its label.
         alicloud-pvname: pv-oss

2. Create the PVC.

   kubectl create -f pvc-oss.yaml

3. Check the status of the PVC.

   kubectl get pvc pvc-oss

   The output confirms that the PVC is bound to the PV.

   NAME      STATUS   VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS   VOLUMEATTRIBUTESCLASS   AGE
   pvc-oss   Bound    pv-oss   10Gi       ROX                           <unset>                 6s

Console

1. On the ACK Clusters page, click the name of your cluster. In the left navigation pane, click Volumes > Persistent Volume Claims.

2. On the Persistent Volume Claims page, click Create, select OSS as the PVC Type, and follow the on-screen instructions to configure the parameters and submit the request.

   The following table describes the key parameters.

   Parameter	Description
   Allocation Mode	Select Use Existing PersistentVolume. If you have not created a persistent volume, you can set the Allocation Mode to Create PV and configure the parameters for the new volume.
   Total capacity	The storage capacity of the PVC, which cannot exceed the capacity of the PersistentVolume.

kubectl

1. Create an oss-workload.yaml file.

   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:
             # The mount path in the container.
             - name: pvc-oss
               mountPath: "/data"
           # Configure a health check.
           livenessProbe:
             exec:
               command:
               - ls
               - /data
             initialDelaySeconds: 30
             periodSeconds: 30
         volumes:
           - name: pvc-oss
             persistentVolumeClaim:
               # Reference the PVC that you created.
               claimName: pvc-oss

2. Create the application.

   kubectl create -f oss-workload.yaml

3. Verify the mount.

   • Confirm that the Pods are running.

     kubectl get pod -l app=nginx

   • Access a Pod and check the mount point.

     kubectl exec -it <pod-name> -- ls /data

     The output should list the files in the OSS mount path.

Console