Configure Persistent Volumes
Configure and manage persistent volumes for a Couchbase cluster.
Ensure you have read the storage classes documentation, created any necessary storage classes for your platform, and setup file system groups for your platform.
Once storage classes are provisioned correctly, you can start provisioning persistent volume claims by modifying the
apiVersion: couchbase.com/v2 kind: CouchbaseCluster spec: servers: - size: 1 name: data_services services: - data volumeMounts: default: couchbase (1) volumeClaimTemplates: (2) - metadata: name: couchbase (3) spec: storageClassName: standard (4) resources: (5) requests: storage: 1Gi
You can expand or contract persistent storage by modifying the
apiVersion: couchbase.com/v2 kind: CouchbaseCluster metadata: name: cb-example spec: volumeClaimTemplates: - metadata: name: couchbase spec: storageClassName: standard resources: requests: storage: 1Gi (1)
|1||You can resize the persistent storage of any pods that reference the modified persistent volume claim template.
For example, to allocate more space per-pod, update the specification from
apiVersion: couchbase.com/v2 kind: CouchbaseCluster metadata: name: cb-example spec: volumeClaimTemplates: - metadata: name: couchbase spec: storageClassName: standard resources: requests: storage: 2Gi (1)
|1||The modification will trigger the Operator to detect that existing persistent volume claims do not match the intended size. The Operator triggers a rolling upgrade of the affected pods.|
You can also modify the storage class and the Operator will detect and upgrade the cluster to use it.
Normally, the Couchbase cluster must undergo a rolling upgrade whenever the volume size is modified. However, persistent volumes that are already in use by Couchbase clusters can optionally be expanded in-place without needing to perform an upgrade on the underlying storage subsystem. The Autonomous Operator achieves this by working in conjunction with Kubernetes Persistent Volume Expansion to claim additional storage for running pods without any downtime.
apiVersion: couchbase.com/v2 kind: CouchbaseCluster metadata: name: cb-example spec: enableOnlineVolumeExpansion: true (1) volumeClaimTemplates: - metadata: name: couchbase spec: storageClassName: standard resources: requests: storage: 2Gi (2)
|2||Modifying the storage size will trigger the Autonomous Operator to detect that existing persistent volume claims do not match the intended size (as it normally would). However, if the new value is larger than the previous value, the Autonomous Operator will attempt an online expansion of the volume.|
You can verify the status of the volume expansion task by checking events on the
$ kubectl describe couchbasecluster expand-couchbase-cluster
If the volume expansion was successful, you should expect output similar to the following:
Normal ExpandVolumeStarted 46s Expanding Volume cb-example-0003-data-01 from 1Gi to 2Gi (1) Normal ExpandVolumeSucceeded 41s Successfully expanded volume cb-example-0002-default-01 Normal ExpandVolumeStarted 18s Expanding Volume cb-example-0004-data-01 from 1Gi to 2Gi (1) Normal ExpandVolumeSucceeded 6s Successfully expanded volume cb-example-0002-default-01
|1||In this example, the persistent volume on each of the Couchbase
It may take some time for online volume expansion to complete, especially since some cloud vendors impose rate limits on storage creation.
There is no timeout for volume expansion tasks.
Volumes will remain at their current size until the underlying infrastructure provides larger volumes or reports a failure.
Unfortunately, the request cannot be rolled back since the request can only be increased.
Therefore, the only way to abort a suspended expansion task is to set
Refer to Volume Expansion Lifecycle for a description of volume expansion events.
It’s important to note that setting
true does not guarantee that volumes will be expanded online.
Please review the following notes before attempting online volume expansion:
StorageClassmust be capable of performing volume expansions (
The Autonomous Operator has no way of detecting if the underlying storage class supports volume expansion. Therefore, it is important that you confirm that your volume type supports volume expansion before enabling online volume expansion in the
In general, block storage volume types such as
AWS-EBS, A`zure Disk`,
Ceph RBDtypically require a full file system expansion, whereas network attached file systems like
Azure Filecan always be expanded online.
Volume size can only be increased.
Kubernetes does not currently support online reductions in volume size.
New storage sizes can only be specified in
volumeClaimTemplates.spec.resources.requests.storage, and must be a larger value than the current size (values smaller than the current size will be blocked by the dynamic admission controller). Note that persistent volumes are fully managed by the Autonomous Operator, therefore any manual changes to the PersistentVolumeClaim size made outside of the
CouchbaseClusterspec will be reverted.
To reduce volume size, set
falseand proceed with traditional resizing (which requires rolling upgrade).
If online volume expansion fails for some reason, the Autonomous Operator will fall back to a traditional rolling upgrade as a means to expand volumes.
The Autonomous Operator cannot detect if resizing in-use PersistentVolumeClaims (
ExpandInUsePersistentVolumes) is enabled on the current Kubernetes cluster.