Container Service for Kubernetes:Mount statically provisioned volumes with ossfs 1.0

Use RRSA

Use AccessKey

RRSA method

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

   apiVersion: v1
   kind: PersistentVolume
   metadata:
     # PV name
     name: pv-oss   
     # PV labels
     labels:    
       alicloud-pvname: pv-oss
   spec:
     capacity:
       # Define the volume capacity
       storage: 10Gi  
     # 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 the actual bucket name
         bucket: "your-bucket-name"  
         # Mount the root directory or a specified subdirectory of the bucket
         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 created or modified
         roleName: "demo-role-for-rrsa"
         # OSS request signature version
         sigVersion: "v4"  

   Parameter	Description
   storage	Defines the capacity of the OSS volume. This value is used only to match the PV with a PVC.
   accessModes	Configures the Access Mode. Supports ReadOnlyMany and ReadWriteMany. If you select ReadOnlyMany, ossfs mounts the OSS Bucket in read-only mode.
   persistentVolumeReclaimPolicy	The PV reclaim policy. OSS volumes currently only support Retain, meaning the PV and the data in the OSS Bucket are retained after the PVC is deleted.
   driver	Defines the driver type. Must be ossplugin.csi.alibabacloud.com when using the Alibaba Cloud OSS CSI plug-in.
   volumeHandle	Must be the same as the PV name (metadata.name).
   bucket	The OSS Bucket to be mounted.
   path	Requires CSI component version v1.14.8.32-c77e277b-aliyun or later. Specifies the mount path relative to the bucket's root directory. Defaults to /, which mounts the entire bucket. If the ossfs version is earlier than 1.91, the specified path must already exist in the OSS Bucket. For details, 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. 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	Enter custom parameters for the OSS volume in the format -o *** -o ***, such as -o umask=022 -o max_stat_cache_size=100000 -o allow_other. View description umask: Changes the read permissions for ossfs files. For example, umask=022 changes the permissions of ossfs files to 755. This resolves permission issues for files uploaded through other methods, such as the SDK or the OSS console, which have a default permission of 640. We recommend configuring this parameter for read/write splitting or multi-user access. max_stat_cache_size: Sets the upper limit for metadata cache entries (for example, 100000). It caches object metadata in memory to improve the performance of operations such as ls and stat. However, this cache cannot promptly detect file modifications made through the OSS console, SDK, or ossutil. This may cause the application to read inconsistent data. If you have strict data consistency requirements, set this parameter to 0 (to disable the cache) or lower the cache expiration time with the stat_cache_expire parameter. This will reduce read performance. allow_other: Allows users other than the mounting user to access files and directories in the mount target. This is suitable for multi-user shared environments where non-mounting users also need to access data. For more optional parameters, see Options supported by ossfs and ossfs 1.0 configuration best practices.
   authType	Set to rrsa to use RRSA authentication.
   roleName	Set to the RAM role that you created or modified. To configure different permissions for different PVs, create different RAM roles and specify different roleName values in the PVs.
   sigVersion	The signature version for requests 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 needs (such as 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

AccessKey method

apiVersion: v1
kind: Secret
metadata:
  name: oss-secret
  # Must be the same as the namespace where the application resides
  namespace: default
stringData:
  # Replace with the AccessKey ID you obtained
  akId: <your AccessKey ID>
  # Replace with the AccessKey secret you obtained
  akSecret: <your AccessKey Secret>

kubectl

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

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     # PVC name
     name: pvc-oss
     namespace: default
   spec:
     # Configure the access mode. ReadOnlyMany indicates that ossfs will mount the OSS Bucket in read-only mode.
     accessModes:
       - ReadOnlyMany
     resources:
       requests:
         # Declare the storage capacity. This cannot be greater than the total volume capacity.
         storage: 10Gi
     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 PVC status.

   kubectl get pvc pvc-oss

   The output shows 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 Clusters page, find the cluster you want and click its name. In the left-side pane, choose Volumes > Persistent Volume Claims.

2. On the PersistentVolumeClaims page, click Create. Select OSS as the PVC Type and configure the parameters as prompted.

   The following table lists the key parameters.

   Parameter	Description
   Provisioning Mode	Select Use Existing PersistentVolume. If you have not created a PV, you can set the Provisioning Mode to Create PersistentVolume and configure the PV parameters.
   Total Capacity	The capacity of the PVC, which cannot exceed the PV's capacity.

kubectl

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

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: oss-static
     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 you created
               claimName: pvc-oss

2. Create the application.

   kubectl create -f oss-static.yaml

3. Verify the mount result.

   • Confirm that the Pods are in the Running state.

     kubectl get pod -l app=nginx

   • Enter a Pod and inspect the mount point.

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

     The output should show the data from the OSS mount path.

Console