ObjectScale
Kubernetes Objects
Bucket Class
Installation of ObjectScale COSI driver does not create BucketClass resource. BucketClass represents a class of Bucket resources with similar characteristics.
Dell COSI Driver is a multi-backend driver, meaning that for every platform the specific BucketClass should be created. The BucketClass resource should contain the name of multi-backend driver and parameters.id for specific Object Storage Platform.
The default sample is shown below:
apiVersion: objectstorage.k8s.io/v1alpha1
kind: BucketClass
metadata:
name: my-bucketclass
driverName: cosi.dellemc.com
deletionPolicy: Delete
parameters:
id: "my.objectscale"
deletionPolicy
⚠ WARNING: this field is case sensitive, and the bucket deletion will fail if policy is not set exactly to Delete or Retain.
deletionPolicy in BucketClass resource is used to specify how COSI should handle deletion of the bucket. There are two possible values:
- Retain: Indicates that the bucket should not be deleted from the object store. The underlying bucket is not cleaned up when the Bucket object is deleted. With this option, the bucket is unreachable from Kubernetes level.
- Delete: Indicates that the bucket should be permanently deleted from the object store once all the workloads accessing this bucket are done. The underlying bucket is cleaned up when the Bucket object is deleted.
emptyBucket
emptyBucket field is set in config YAML file passed to the chart during COSI driver installation. If it is set to true, then the bucket will be emptied before deletion. If it is set to false, then ObjectScale cannot delete the bucket since it is not empty, and it will return an error.
emptyBucket has no effect when Deletion Policy is set to Retain.
Bucket
Bucket represents a Bucket or its equivalent in the storage backend. Generally, it should be created only in the brownfield provisioning scenario. The following is a sample manifest of Bucket resource:
apiVersion: objectstorage.k8s.io/v1alpha1
kind: Bucket
metadata:
name: my-bucket
spec:
driverName: cosi.dellemc.com
bucketClassName: my-bucket-class
bucketClaim:
name: "my-bucket-claim"
namespace: "default"
deletionPolicy: Delete
protocols:
- S3
parameters:
id: "my.objectscale"
spec.existingBucketID
existingBucketID is an optional field that contains the unique id of the bucket in the ObjectScale. This field should be used to specify a bucket that has been created outside of COSI.
Due to the fact that the driver supports multiple arrays and multiple ObjectStores from one instance, the existingBucketID needs to have a format of: <Configuration ID>-<Existing Bucket ID>, e.g. my.objectscale-existing-bucket.
Bucket Claim
BucketClaim represents a claim to provision a Bucket. The following is a sample manifest for creating a BucketClaim resource:
apiVersion: objectstorage.k8s.io/v1alpha1
kind: BucketClaim
metadata:
name: my-bucketclaim
namespace: my-namespace
spec:
bucketClassName: my-bucketclass
protocols: [ 'S3' ]
Unsupported options
spec.protocols=[Azure,GCS]- Protocols are the set of data API this bucket is required to support. From protocols specified by COSI (v1alpha1), Dell ObjectScale platform only supports the S3 protocol. ProtocolsAzureandGCSMUST NOT be used.
Bucket Access Class
Installation of ObjectScale COSI driver does not create BucketAccessClass resource. BucketAccessClass represents a class of BucketAccess resources with similar characteristics.
Dell COSI Driver is a multi-backend driver, meaning that for every platform the specific BucketAccessClass should be created. The BucketAccessClass resource should contain the name of multi-backend driver and parameters.id for specific Object Storage Platform.
The default sample is shown below:
apiVersion: objectstorage.k8s.io/v1alpha1
kind: BucketAccessClass
metadata:
name: my-bucketaccessclass
driverName: cosi.dellemc.com
authenticationType: Key
parameters:
id: "my.objectscale"
authenticationType
⚠ NOTE:
authenticationTypedenotes the style of authentication. The only supported option for COSI Driver isKey.
Bucket Access
BucketAccess resource represents a access request to generate a Secret, that will allow you to access ObjectStorage . The following is a sample manifest for creating a BucketClaim resource:
apiVersion: objectstorage.k8s.io/v1alpha1
kind: BucketAccess
metadata:
name: my-bucketaccess
namespace: my-namespace
spec:
bucketClaimName: my-bucketclaim
protocol: S3
bucketAccessClassName: my-bucketaccessclass
credentialsSecretName: my-s3-secret
spec.protocol
⚠ WARNING: this field is case sensitive, and the provisioning will fail if protocol is not set exactly to S3.
spec.protocol is the name of the Protocol that this access credential is supposed to support.
Provisioning Buckets
Each bucket is created using the default configuration settings. While there are a few optional parameters available for customization, they are not mandatory for provisioning. If needed, these parameters can be defined and managed within the associated BucketClass.
| Name | Parameter | Details |
|---|---|---|
| Replication Group | replicationGroup | Name of the replication group to use when creating the bucket. Not required if default Replication Group is set on the namespace. |
| Quota Limit | quotaLimit | Block size in GB. Cannot be less than 1GB or use decimal values. Can be set to -1 to indicate quota value not defined. |
| Quota Warn | quotaWarn | Notification size in GB. Cannot be less than 1GB or use decimal values. Can be set to -1 to indicate quota value not defined. |
| Default Retention | defaultRetention | Default retention period in seconds |
apiVersion: objectstorage.k8s.io/v1alpha1
kind: BucketClass
metadata:
name: my-bucketclass
driverName: cosi.dellemc.com
deletionPolicy: Delete
parameters:
id: "my.objectscale"
replicationGroup: "rg1"
quotaLimit: "100"
quotaWarn: "80"
defaultRetention: "2592000"
Kubernetes Administrator Steps
The first step before you can start provisioning object storage, is to create a BucketClass. The BucketClass is an object that defines the provisioning and management characteristics of Bucket resources. It acts as an abstraction layer between users (such as applications or pods) and the underlying object storage infrastructure. BucketClass allows you to dynamically provision and manage Buckets in a consistent and automated manner.
The following example shows how to create a BucketClass:
cat <<EOF | kubectl create --filename -
apiVersion: objectstorage.k8s.io/v1alpha1
kind: BucketClass
metadata:
name: my-bucketclass
driverName: cosi.dellemc.com
deletionPolicy: Delete
parameters:
id: "my.objectscale"
EOF
End-user Steps
Greenfield Provisioning
Greenfield Provisioning means creating a new bucket from scratch, without any existing data.
The following example shows how to create a BucketClaim for greenfield provisioning.
cat <<EOF | kubectl create --namespace=my-namespace --filename -
apiVersion: objectstorage.k8s.io/v1alpha1
kind: BucketClaim
metadata:
name: my-bucketclaim
spec:
bucketClassName: my-bucketclass
protocols: [ 'S3' ]
EOF
ℹ️ NOTE: remember to replace my-namespace, my-bucketclass and my-bucketclaim with actual values.
Brownfield Provisioning
Brownfield Provisioning means using an existing bucket, that can already contain the data. This differs slightly from Greenfield Provisioning, as we need to create both Bucket and BucketClaim manually.
The following example shows how to create Bucket and BucketClaim for brownfield provisioning.
cat <<EOF | kubectl create --namespace=my-namespace --filename -
apiVersion: objectstorage.k8s.io/v1alpha1
kind: Bucket
metadata:
name: my-brownfield-bucket
spec:
bucketClaim: {}
bucketClassName: my-bucketclass
deletionPolicy: Retain
driverName: cosi.dellemc.com
existingBucketID: my.objectscale-my-existing-bucket
parameters:
id: my.objectscale
protocols: [ 'S3' ]
---
apiVersion: objectstorage.k8s.io/v1alpha1
kind: BucketClaim
metadata:
name: my-brownfield-bucketclaim
spec:
existingBucketName: my-brownfield-bucket
protocols: [ 'S3' ]
EOF
ℹ️ NOTE: remember to replace my-namespace, existing-bucket-name and my-bucketclaim with actual values.
Deleting Buckets
There are a few crucial details regarding bucket deletion. The first one is deletionPolicy which is used to specify how COSI should handle deletion of a bucket. It is found in BucketClass resource and can be set to Delete and Retain. The second crucial detail is emptyBucket field in the Helm Chart configuration.
The following example shows how to delete a BucketClaim.
kubectl --namespace=my-namespace delete bucketclaim my-bucketclaim
ℹ️ NOTE: remember to replace my-namespace and my-bucketclaim with actual values.
Granting Access
Kubernetes Administrator Steps
The first step before you start granting access to the object storage for your application, is to create a BucketAccessClass. The BucketAccessClass is an object that defines the access management characteristics of Bucket resources. It acts as an abstraction layer between users (such as applications or pods) and the underlying object storage infrastructure. BucketAccessClass allows you to dynamically grant access to Buckets in a consistent and automated manner.
The following example shows how to create a BucketAccessClass:
cat <<EOF | kubectl create --filename -
apiVersion: objectstorage.k8s.io/v1alpha1
kind: BucketAccessClass
metadata:
name: my-bucketaccessclass
driverName: cosi.dellemc.com
authenticationType: Key
parameters:
id: "my.objectscale"
EOF
End-user Steps
⚠ WARNING: only full access granting is supported.
The underlying workflow for granting access to the object storage primitive is:
- user is added to particular account in the ObjectScale;
- bucket policy is modified to reflect that user has gained permissions for a bucket;
- access key for the user is added to ObjectScale.
The following example shows how to grant an access using BucketAccess resource:
cat <<EOF | kubectl create --namespace=my-namespace --filename -
apiVersion: objectstorage.k8s.io/v1alpha1
kind: BucketAccess
metadata:
name: my-bucketaccess
spec:
bucketAccessClassName: my-bucketaccessclass
bucketClaimName: my-bucketclaim
credentialsSecretName: my-s3-secret
protocol: S3
EOF
ℹ️ NOTE: remember to replace my-namespace, my-bucketaccessclass, my-bucketclaim, my-s3-secret and my-bucketaccess with actual values.
Revoking Access
This feature revokes a user’s previously granted access to a particular bucket.
When resource of BucketAccess kind is removed from Kubernetes it triggers the process:
- access key is removed from ObjectScale;
- bucket policy is modified to reflect that user has lost permissions for a bucket;
- user is removed from ObjectScale.
The following example shows how to revoke a BucketAccess:
kubectl --namespace=my-namespace delete bucketaccess my-bucketaccess
ℹ️ NOTE: remember to replace my-namespace and my-bucketaccess with actual values.