Please use the form below to provide your feedback. Because your feedback is valuable to us, the information you submit in this form is recorded in our issue tracking system (JIRA), which is publicly available. You can track the status of your feedback using the ticket number displayed in the dialog once you submit the form.

A newer version of this documentation is available.

View Latest

CouchbaseBucket Resource

      +

      The Couchbase Autonomous Operator operates on CouchbaseCluster objects. Buckets are decoupled from this configuration and are selected for inclusion within a cluster with configurable label selectors.

      CouchbaseBucket resources provide highly available, persistent data. They may be used for cross data center replication (XDCR).

      The following YAML shows all possible fields that may be configured for a CouchbaseBucket. This configuration may not be valid and is only for illustrative purposes.

      All available CouchbaseBucket configuration parameters
      apiVersion: couchbase.com/v2
kind: CouchbaseBucket
metadata:
  name: my-bucket
  labels:
    cluster: my-cluster
spec:
  name: Non_DNS_name
  memoryQuota: 100Mi
  replicas: 2
  ioPriority: low
  evictionPolicy: valueOnly
  conflictResolution: lww
  enableFlush: false
  enableIndexReplica: true
  compressionMode: passive
  minimumDurability: none
  maxTTL: 720h

      Top-Level Definitions

      The following are relevant generic parameters that can be defined:

      apiVersion: couchbase.com/v2
kind: CouchbaseBucket
metadata:
  name: my-bucket
  labels:
    cluster: my-cluster

      apiVersion

      The API version defines which version of the resource this configuration refers to.

      Field rules: This field is required and must be set to couchbase.com/v2

      kind

      The kind defines the type of resource this configuration refers to.

      Field rules: This field is required and must be set to CouchbaseBucket

      metadata.name

      The metadata name defines the name of the resource, and is used as the bucket name by default. The name must be unique for the kind defined. Furthermore the name must be unique for all bucket kinds defined and used by the cluster. For example you cannot have a CouchbaseBucket named "default" and a CouchbaseEphemeralBucket also named "default".

      Like other Kubernetes resource names, the metadata name is restricted to the character limits of DNS label names. This means that this field cannot accept the full character set that Couchbase supports for bucket names. If you wish to use a bucket name that would otherwise be supported by Couchbase, but contains characters that are outside of the limits for DNS label names, then you can use the spec.name field to override the metadata name becoming the bucket name.

      Field rules: This field is required and must be unique as described above.

      metadata.labels

      The metadata labels allow the resource to be tagged so that it is only selected by specific CouchbaseCluster resources. Further details about resource selection can be found on the Couchbase Resources and RBAC page.

      Field rules: This field is optional and must be a map of string key/value pairs.

      spec

      The following are parameters that may be set on the bucket:

      spec:
  name: Non_DNS_name
  memoryQuota: 100Mi
  replicas: 2
  ioPriority: low
  evictionPolicy: valueOnly
  conflictResolution: lww
  enableFlush: false
  enableIndexReplica: true
  compressionMode: passive
  minimumDurability: none
  maxTTL: 720h

      spec.name

      This field allows the name of a bucket to be overridden. By default, the bucket name will be that which is specified as the resource name in metadata.name. This has limitations in that the metadata name is limited to the character set of DNS label names. Couchbase Server allows characters outside of the DNS label character set. By specifying this field you may use any character that Couchbase Server supports. You may also use this field to allow multiple buckets in the same namespace — whose resource names differ as they must be unique — to have the same actual bucket name in Couchbase.

      Field rules: This field is optional and must be a string containing a maximum of 100 of the following characters a-zA-Z0-9-_%..

      spec.memoryQuota

      This field specifies the amount of memory to allocate to this bucket per-node. It is deducted from the per-node spec.cluster.dataServiceMemoryQuota parameter in a related CouchbaseCluster resource. The total quota allocated for all buckets must not exceed the spec.cluster.dataServiceMemoryQuota parameter in a related CouchbaseCluster resource. The minimum size is 100Mi. If not specified this field will default to 100Mi.

      Field rules: This field is optional and must be a Kubernetes resource quantity greater than or equal to 100Mi.

      spec.replicas

      This field specifies the number of replicas that should be created for this bucket. This value may be set between 0 and 3 inclusive. If not specified this field will default to 1. Modification of this field will cause data to rebalanced across the cluster.

      Field rules: This field is optional and must be an integer between 0 and 3.

      spec.ioPriority

      This field sets the IO priority of background threads for this bucket. If not specified this field will default to low.

      Field rules: This field is optional and must be either low or high.

      spec.evictionPolicy

      This field sets the in-memory cache eviction policy for this bucket. Couchbase buckets support either valueOnly or fullEviction.

      Specifying the valueOnly policy means that each key stored in this bucket must be kept in memory. This is the default policy; using this policy improves the performance of key-value operations, but limits the maximum size of the bucket.

      Specifying the fullEviction policy means that the performance is impacted for key-value operations, but the maximum size of the bucket is unbounded.

      Field rules: This field is optional and must be either valueOnly or fullEviction.

      spec.conflictResolution

      This field specifies the bucket’s conflict resolution mechanism which is to be used if a conflict occurs during cross data center replication (XDCR). There are two supported mechanisms: sequence-based and timestamp-based.

      The sequence-based conflict resolution mechanism — seqno — selects the document that has been updated the greatest number of times since the last sync. For example, if one cluster has updated a document twice since the last sync, and the other cluster has updated the document three times, the document updated three times is selected regardless of the specific times at which these updates took place.

      The timestamp-based conflict resolution mechanism — lww — selects the document with the most recent timestamp. This is only supported when all of the clocks on all of the nodes are fully synchronized.

      If not specified this field will default to seqno

      Field rules: This field is optional and must be either seqno or lww.

      spec.enableFlush

      This field specifies whether or not to enable the flush command on this bucket. This parameter defaults to false if it is not specified.

      Field rules: This field is optional and must be a boolean.

      spec.enableIndexReplica

      This field specifies whether or not to enable view index replicas for this bucket. This parameter defaults to false if it is not specified.

      Field rules: This field is optional and must be a boolean.

      spec.compressionMode

      This field sets the compression mode for the specified bucket. This parameter defaults to passive if not specified.

      Field rules: This field is optional and must be either "off", passive or active. Note that Kubernetes uses the YAML 1.1 specification, so off must be in quotes ("off") in order to be interpreted as a string, not a Boolean.

      spec.minimumDurability

      This field defines how durable a document write is by default, and can be made more durable by the client. This feature enables ACID transactions.

      When none, Couchbase server will respond when the document is in memory, it will become eventually consistent across the cluster. When majority, Couchbase server will respond when the document is replicated to at least half of the pods running the data service in the cluster. When majorityAndPersistActive, Couchbase server will respond when the document is replicated to at least half of the pods running the data service in the cluster and the document has been persisted to disk on the document master pod. When persistToMajority, Couchbase server will respond when the document is replicated and persisted to disk on at least half of the pods running the data service in the cluster.

      Field_rules: This field must be either none, majority, majorityAndPersistActive or persistToMajority, defaulting to none.

      spec.maxTTL

      This field sets the default time to live for documents contained within the bucket. When unset, or set to zero, documents will persist forever, or until deleted. This is the default behavior.

      When set to a value greater than zero, documents will be purged when they have not been used for this duration.

      For additional information on document expiration, please consult the Couchbase Server documentation.

      Field rules: This field is optional and must be a valid duration string in the range 0-2147483648s.