CouchbaseCluster Resource

This field specifies the API version for the Couchbase integration. As the integration changes over time, you can change the API version whenever new features are added. For any given release, the API versions that are supported by that Operator will be specified in the documentation. It is recommended that you upgrade to the latest API version whenever possible.

This field specifies that this Kubernetes configuration will use the custom Couchbase controller to manage the cluster.

This field sets the name of the Couchbase cluster. It must be unique within the Kubernetes namespace. This name controls how Operator managed resources are named. The logical cluster name — as displayed in the Couchbase UI — may be changed with the spec.cluster.clusterName parameter.

This field specifies the image that should be used. For docker hub images for use on Kubernetes this should be similar to couchbase/server:6.6.0. For Red Hat images for use with OCP this should be similar to registry.connect.redhat.com/couchbase/server:6.6.0-1. Please check the relevant registry for the most up to date image tags. You may use a different location if, for example, you have a local container registry.

Image tags must contain a valid semantic version in order to dynamically enable/disable Operator features and control upgrade paths. For further information on upgrade constraints, please consult the upgrade documentation.

This field specifies whether or not the Operator is currently managing this cluster. This parameter may be set to true if you decide to make manual changes to the cluster. By disabling Operator management, you can change the cluster configuration without having to worry about the Operator reverting the changes. However, before re-enabling the Operator, ensure that the Kubernetes configuration matches the cluster configuration.

This field specifies whether or not two pods in this cluster can be deployed on the same Kubernetes node. In a production setting this parameter should always be set to true in order to reduce the chance of data loss in case a Kubernetes node crashes.

This field specifies whether or not software update notifications are displayed in the Couchbase UI. This provides a visual indication as to whether a software update is available and should be applied in order to increase functionality or fix defects.

This field controls how the Operator performs upgrades/modifications to pods when required.

The default value if not specified, RollingUpgrade, upgrades one pod at a time. Rolling upgrades are safer in that they limit the scope of an upgrade, and can be rolled back, however will take longer to complete.

The value ImmediateUpgrade can be used to upgrade all pods at the same time. Immediate upgrades are much faster than rolling upgrades.

This field defines whether the cluster is hibernating or not.

When set to false, the default, the cluster operates as usual or is woken up from hibernation. When set to true, as defined by spec.hibernationStrategy, the cluster is deprovisioned.

For more information, read the hibernation concept page.

This field defines how the Operator should hibernate the cluster when requested.

When Immediate, the default, the Operator will terminate all pods associated with the Couchbase cluster immediately.

For more information, read the hibernation concept page.

This field defines how the Operator should attempt to recover the cluster in the event of any pods failing, or when waking-up a hibernating cluster.

When PrioritizeDataIntegrity, the default, is set the Operator will take a cautious approach to recovery. When a pod is reported as down with this policy, the Operator will fully delegate responsibility for failing over Couchbase server instances to Couchbase server. If Couchbase server deems auto-failover dangerous, or resulting in data loss, then the Operator will loop continually until the affected pods become either active again or failed. This may require manual intervention.

When PrioritizeUptime is set, the Operator will wait for a period beyond the requested auto-failover timeout before taking action. If Couchbase server does not automatically failover pods within this time limit, the Operator will forcefully failover the pods, at which point the Operator is unblocked and becomes able to recover the cluster. This policy may cause data loss, however is useful for recovery of ephemeral clusters — where no persistent volumes exist and data is lost anyway — and hibernation where Couchbase server refuses to failover ephemeral pods.

Setting the server groups field enables automatic management of Couchbase server groups. The end user is responsible for adding labels to their Kubernetes nodes which will be used to evenly distribute nodes across server groups so the cluster is tolerant to the loss of an entire data center (or any other desired failure domain). Nodes are labeled with a key of failure-domain.beta.kubernetes.io/zone and an arbitrary name string. Multiple nodes may have the same server group to allow multiple pods to be scheduled there regardless of anti-affinity settings. An example of applying the label is as follows:

As the list of server groups to use is explicit the end user has flexibility in controlling exactly where pods will be scheduled e.g. one cluster may reside in one set of server groups, and another cluster in another set of server groups.

At present the scheduling simply stripes pods across the server groups; each new pod is run in a server group with the fewest existing cluster members. This is performed on a per-server configuration basis to ensure individual classes of servers are equally distributed for high-availability. For each class of server configuration you may choose override the set of server groups to schedule across; see the documentation under the spec.servers.serverGroups configuration key.

The server group feature also not support service redistribution at this time, so scaling the set of server groups will not result in any pods being 'moved' to make best use of the new topology or evacuated from a removed server group.

This field is a Kubernetes PodSecurityContext object which is attached to all pods that are created by the Operator. If unspecified, this will default to the couchbase user, mount attached volumes as that user, and ensure that the containers are running as non-root. You may override the default behavior if using a custom container image or for testing purposes.

For additional information, see the non-root installation how-to.

This field indicates which underlying cloud platform the Kubernetes cluster is running on and is used as a hint to correctly configure managed resources.

This field enables autoscaling for stateful server configurations and buckets. A server configuration is considered stateful if it contains one of data, index, search, eventing, or analytics. A bucket is considered stateful if it is one of CouchbaseBucket, or CouchbaseMemcachedBucket. Server configurations with stateful services or stateful buckets are only permitted to autoscale when enablePreviewScaling is true.

A server configuration is considered stateless if it contains only the query service. A bucket is considered stateless if is a CouchbaseEphemeralBucket. When enablePreviewScaling is false only stateless server configurations associated with stateless buckets are permitted to autoscale.

This field allows the cluster name — as displayed in the Couchbase UI — to be overridden. This field will be set to metadata.name if not specified. As metadata.name is required to be a valid DNS hostname, this field allows those limitations to be bypassed.

The amount of memory to assign — per-node — to the data service if it is present on a specific Couchbase node. This parameter defaults to 256Mi if it is not set.

The amount of memory to assign — per-node — to the index service if it is present on a specific Couchbase node. This parameter defaults to 256Mi if it is not set.

The amount of memory to assign — per-node — to the search service if it is present on a specific Couchbase node. This parameter defaults to 256Mi if it is not set.

The amount of memory to assign — per-node — to the eventing service if present on a specific Couchbase node in Mi. This parameter defaults to 256Mi if it is not set.

The amount of memory to assign — per-node — to the analytics service if present on a specific Couchbase node in Mi. This parameter defaults to 1Gi if it is not set.

Specifies the backend storage type to use for the index service. If the cluster already contains a Couchbase Server instance running the index service, then this parameter cannot be changed until all Couchbase instances running the index service are removed.

This field controls the number of threads allocated to the indexer. When 0, a thread will be created for each CPU. This defaults to 0.

This field controls indexer logging. Defaults to info.

This field controls how many index rollback points to maintain. This defaults to 2.

This field controls how frequently in-memory indexes should be snapshotted. This defaults to 200ms.

This field controls how frequently on-disk indexes should be snapshotted. This defaults to 5s.

This field controls the storage mode the indexer uses. The storage mode can only be modified when no server classes exist that contain the index service.

Specifies the auto-failover timeout. The Operator relies on the Couchbase cluster to auto-failover nodes before removing them, so setting this field to an appropriate value is important.

Specifies the maximum number of failover events we can tolerate before manual intervention is required. If a bucket as 2 replicas we can tolerate 2 pods failing over. Applies to entire server groups also.

Specifies whether a node will automatically fail over on data disk issues.

Specifies the time period to wait before automatically failing over a node experiencing data disk issues. This field’s units are in seconds.

Specifies whether the cluster will automatically failover an entire server group.

This field defines the relative amount of fragmentation allowed in persistent database files before triggering compaction. This field defaults to 30.

This field defines the absolute amount of fragmentation allowed in persistent database files before triggering compaction. This field is not set by default.

This field defines the relative amount of fragmentation allowed in persistent view files before triggering compaction.

This field defaults to 30.

This field defines the absolute amount of fragmentation allowed in persistent view files before triggering compaction. This field is not set by default.

This field defines whether auto-compaction should be performed in parallel.

Setting this field to true will potentially yield shorter compaction times. This comes at the expense of far greater disk IO that may compete with normal database operation. This field should only be used on storage capable of handling the greater IO requirements e.g. solid state.

This field defines when an auto-compaction may start to run.

Auto compaction comes with a cost associated with disk IO. It may be undesirable for it to run during core business hours as it competes with normal database operation. This field allows auto-compaction to be limited to a specific time window when fewer resources are required by normal database operation. This field is not set by default.

This field defines when an auto-compaction may run until.

Auto compaction comes with a cost associated with disk IO. It may be undesirable for it to run during core business hours as it competes with normal database operation. This field allows auto-compaction to be limited to a specific time window when fewer resources are required by normal database operation. This field is not set by default.

This field defines whether to stop auto-compaction after the time window end.

By default an auto-compaction will run until completion. In some situations it may be desirable to stop auto-compaction to free up resources for normal database operation. This field defaults to false if not set.

This field defines how frequently tombstones may be purged.

Couchbase Server maintains tombstones. These are records of deleted documents. Tombstones are retained so that eventually consistent consumers can observe document deletion in the event of a disconnection. This field defaults to 72h if not set.

This field specifies the name of a Kubernetes Secret that should be used as the user name and password of the Couchbase super-user.

This field specifies whether the Operator should manage Couchbase RBAC. This field defaults to false allowing the user to manually manage RBAC settings with the Couchbase web console or the Couchbase API. If set to true, the Operator will search for CouchbaseRoleBinding resources in the namespace under the control of the spec.security.rbac.selector field.

This field specifies which CouchbaseRoleBinding resources are considered when the spec.security.rbac.managed field is set to true. If not specified all CouchbaseRoleBinding resources are selected. If specified, then only CouchbaseRoleBinding resources containing the same labels as specified in the label selector are selected.

For additional information, see the Couchbase resource label selection documentation.

This field specifies list of LDAP hosts Operator should connect to for authentication.

This field specifies the port Operator should use connect when connecting to hosts.

This field specifies the Distinguished Name (DN) to bind to on the LDAP server for performing administrative tasks such as query and authentication. If not specified, the operator will attempt to connect anonymously to the specified LDAP host(s).

This field specifies the secret containing the password that the Operator should use to perform LDAP queries and authentication. If specified the secret must refer to a Kubernetes secret containing a key named password. If not specified, the operator will attempt to connect anonymously to the specified LDAP host(s).

This field specifies whether or not the Couchbase Server allows user authentication. This defaults to true and the template specified in the spec.security.ldap.userDNMapping field will be used to search for the LDAP user to authenticate as an associated Couchbase Server user.

This field specifies list of templates to use for providing username to DN mapping. The template may contain a placeholder specified as %u to represent the Couchbase user who is attempting to gain access.

This field specifies whether or not the Couchbase Server is allowed to authorize authenticated LDAP users. If set to true, the value of spec.security.ldap.groupsQuery will be used to check the LDAP group membership of a user in order to authorize them.

This field specifies the Distinguished Name (DN) of the LDAP group containing users which can be authorized.

This field specifies the type of encryption to use for connection with the LDAP server. If this value is set to TLS or StartTLSExtension, and a certificate is not specified for spec.security.ldap.tlsSecret, then the Couchbase server will attempt to use its own certificate for encryption.

This field specifies the Certificate to use for connecting with LDAP server when spec.security.ldap.encryption is either TLS or StartTLSExtension.

This field specifies whether or not the Couchbase Server Web Console should be exposed externally. Exposing the web console is done using a NodePort service and the port for the service can be found in the describe output when describing this cluster. This parameter may be changed while the cluster is running and the Operator will create/destroy the NodePort service as appropriate.

When the spec.networking.exposeAdminConsole property is set, the Operator will generate a service that exposes the administrator console. This field allows the definition of a base Service resource. The Operator will merge any configuration it controls on top of this template.

This field allows the definition of annotations and labels in the template metadata, and the service type in the specification for example.

When the Couchbase Server Web Console is exposed with the spec.networking.exposeAdminConsole property, by default, opening a browser session to the Web Console will be automatically load balanced across all pods in the cluster to provide high availability. However, the Web Console will display different features based on the services that are running on the particular pod that it’s connected to.

This property allows the UI service to be constrained to pods running one or more specific services. The services that you specify are subtractive in nature — they will only identify pods running all of those services — so care must be used. For example, if the cluster is deployed with multi-dimensional scaling, the data service on one set of pods, and the analytics service on another mutually exclusive set, then specifying data and analytics as your Web Console services list would result in the Web Console not being accessible — no pods match all the constraints, i.e. no pods are running both the data and analytics services.

If you require access to a specific pod running a specific service, this can also be achieved by using the admin option of the spec.networking.exposedFeatures property. This will allow access via a node port. You must connect directly to the IP address of the node that the pod is running on. The assigned node port is available via the cluster status structure returned by kubectl describe, or via the output of kubectl get services. Refer to the services documentation for more information.

This field defines how the admin console service is exposed. By default it will use a NodePort which exposes the console on a random port on all nodes in the cluster. It is accessible only within the cluster or via an IP tunnel into the Kubernetes underlay network. If set to LoadBalancer it will expose the default admin console port to the public internet via a load balancer on platforms which support this service type. Only the TLS enabled port (18091) will be exposed to public networks.

This field specified a list of per-pod features to expose on the cluster network (as opposed to the pod network). These define sets of ports which are required to support the specified features. The supported values are as follows:

When the spec.networking.exposedFeatures property is set, the Operator will generate a service that exposes Couchbase services per-pod. This field allows the definition of a base Service resource. The Operator will merge any configuration it controls on top of this template.

This field allows the definition of annotations and labels in the template metadata, and the service type in the specification for example.

This field defines how the per Couchbase node ports are exposed. By default it will use a NodePort which exposes the exposedFeatures on random ports per service on the Kubernetes nodes running the cluster. They are accessible only within the cluster or via an IP tunnel into the Kubernetes underlay network. If set to LoadBalancer it will expose the default exposed service ports on the public internet via a load balancer on platforms which support this service type. Only the TLS enabled ports will be exposed to public networks.

This field defines how traffic ingressing into Kubernetes is handled. By default this is set to Local meaning that traffic from a public load balancer must be routed directly to the node upon which the destination Pod is resident. This enforces consistent network performance by keeping the number of hops from the edge to the pod consistent. Some environments may have external firewall rules in place that prevent the Operator from connecting to an externally advertised address to verify client connectivity before allowing data to reside on that node. This field may be set to Cluster to work around this issue, masquerading connectivity checks as normal node-to-node Kubernetes traffic, but at the expense of inconsistent network paths.

This field defines any custom annotations to be added to console and per-pod (exposed feature) services.

This field defines any IPv4 prefixes that should be added to any load balancer services managed by the Operator. This is a list of address ranges that are allowed to connect to the service.

This field defines the underlying network platform in use. Typically, this field does not need to be defined.

When Istio, this enables DNS host aliases in Couchbase server pods. Without this support, Couchbase server may connect to local services over the pod IP address, not localhost, and will be dropped by Istio when running in mTLS mode.

This field defines the DNS A records that should be dynamically added to the public DNS for console and per-pod services. It must be a valid domain name which you have ownership of and the ability to dynamically update as services are created, updated and deleted by the Operator.

This field defines the certificate and private key used by Couchbase Server services.

This field is required if any static TLS configuration is specified under spec.networking.tls.static. This field references a secret containing a key chain.pem whose value is a wildcard certificate chain signed by the cluster CA defined in spec.networking.tls.static.operatorSecret, and pkey.key whose value is a private key corresponding to the leaf certificate. The TLS documentation contains detailed information on generating valid certificates for your cluster.

This field defines the CA certificate and optionally a client certificate and private key used to authenticate the Operator.

This field is required if any static TLS configuration is specified under spec.networking.tls.static. This field references a secret containing a key ca.crt whose value is a CA certificate. The CA certificate must be the root authority for a server certificate defined in spec.networking.tls.static.member.serverSecret. The TLS documentation contains detailed information on generating valid certificates for your cluster.

If spec.networking.tls.clientCertificatePolicy is set to enable then operatorSecret may contain a client certificate and private key.

If spec.networking.tls.clientCertificatePolicy is set to mandatory then operatorSecret must contain a client certificate and private key.

When using client certificates the secret must contain a key couchbase-operator.crt whose value is a client certificate chain signed by the cluster CA defined above, and couchbase-operator.key whose value is a private key corresponding the leaf client certificate. The client certificate must resolve — with spec.networking.tls.clientCertificatePaths[] — to the administrative user name defined in spec.security.adminSecret.

This field defines the client certificate policy that Couchbase Server should use.

If not defined Couchbase Server will use basic authentication — username and password — over server side TLS.

If set to enable then Couchbase Server will request a client certificate and the clients may return one in order to authenticate. If a client certificate is not returned by the client Couchbase Server will fall back to basic authentication. If you require certificate authentication by the Operator then you may define it in spec.networking.tls.static.operatorSecret.

If set to mandatory then Couchbase Server will request a client certificate and the client must return one in order to authenticate. You must define the client certificate in spec.networking.tls.static.operatorSecret.

This list defines how Couchbase Server should parse client certificates in order to extract a valid user.

This field defines where to extract the username from. Couchbase Server currently allows usernames to be defined in the certificate subject common name (CN), or subject alternative names (SAN). Valid SANs that can be parsed are URI, DNS or EMAIL records.

This field defines whether the username is prefixed.

This allows, for example, a CN of www.example.com to be mapped to a username example.com by specifying a prefix of www..

This field defines whether the username is delimited.

This allows, for example, an EMAIL SAN of jane.doe@example.com to be mapped to the username jane.doe by specifying a delimiter of @.

This field defines whether node-to-node encryption is enabled.

When set to All, all data between Couchbase server nodes is encrypted. When set to ControlPlaneOnly, only internal Couchbase server messages are encrypted, user data is not. If not specified, data between Couchbase Server nodes is not encrypted.

As with all encryption protocols, this setting may negatively affect performance with the increased data protection.

This field is used in conjunction with the logs persistent volume mount. The value can be any valid golang duration. If specified this controls the retention period that log volumes are kept for after their associated pods have been deleted. If not specified (the default) or zero e.g. 0s, log volumes are retained indefinitely.

It is recommended to specify this field when using ephemeral server classes so that potentially sensitive information is not retained indefinitely. This allows compliance with data privacy legislation.

This field is used in conjunction with the logs persistent volume mount. If specified this controls the maximum number of log volumes that can be kept after their associated pods have been deleted. If this threshold is passed, log volumes are deleted starting with the oldest first. If not specified or zero, log volumes are retained indefinitely.

It is recommended to specify this field when using ephemeral server classes so an unlimited number of persistent volumes cannot be created. This ensures storage quotas are not exhausted or significant costs are incurred.

This field specifies the number of nodes of this type that should be in the cluster. This allows the user to scale up different parts of the cluster as necessary. If this parameter is changed at run time, the Operator will automatically scale the cluster.

This field specifies a name for this group of servers.

This field specifies a list of services that should be run on nodes of this type. Users can specify data, index, query, search, eventing and analytics in the list. At least one service must be specified and all clusters must contain at least one node specification that includes the data service.

This controls the set of server groups to schedule pods in. Functionality is identical to that defined in the top level specification, but overrides it and allows the end user to specify exactly where pods of individual server/service configuration are scheduled. See the main documentation for details.

This field defines whether Autoscale is permitted for this specific server configuration. When set to true a CouchbaseAutoscale resource is created by the operator with the name of the enabled server configuration along with the name of the cluster. For example, a server configuration named default will result in a CouchbaseAutoscale resource created named default.cb-example. This resource conforms to Kubernetes HorizontalPodAutoscaler API and can be specified as a scaleTargetRef according to the HorizontalPodAutoscalerSpec resource specification.

This field specifies the environment variables (as key-values pairs) that should be set when the pod is started. This section is optional. Specified environment variables will be available in Couchbase server containers only. The env field is defined by the Kubernetes EnvVar type.

This field specifies a reference to either a Secret or ConfigMap which is used to create environment variables when the pod is started. Specified environment variables will be available in Couchbase server containers only. The envFrom field is defined by the Kubernetes EnvFromSource type.

Pod resources are specified using a Kubernetes ResourceRequirements type:

This field is required when using persistent volumes. The value specifies the name of the volumeClaimTemplate that is used to create a persisted volume for the default path. This is always /opt/couchbase/var/lib/couchbase. The claim must match the name of a volumeClaimTemplate within the spec.

This field is the name of the volumeClaimTemplate that is used to create a persisted volume for the data path. When specified, the data path will be /mnt/data. The claim must match the name of a volumeClaimTemplate within the spec. If this field is not specified, then a volume will not be created and the data directory will be part of the "default" volume claim.

This field is the name of the volumeClaimTemplate that is used to create a persisted volume for the index path. When specified, the index path will be /mnt/index. The claim must match the name of a volumeClaimTemplate within the spec. If this field is not specified, then a volume will not be created and the data directory will be part of the "default" volume claim.

This field is the name of any volumeClaimTemplate that is used to create a persisted volume for the analytics paths. When specified, the analytics paths will be /mnt/analytics-00 (where 00 denotes the first path), with all subsequent paths having incrementing values. The claim must match the name of a volumeClaimTemplate within the spec. If this field is not specified, then a volume will not be created and the data directory will be part of the "default" volume claim.

Field rules: The analytics volume mount can only be specified when the default volume claim is also specified. The spec.servers.services field must also contain the analytics service.

This field is the name of the volumeClaimTemplate that is used to create a persisted volume for the logs path. When specified, the logs path will be /opt/couchbase/var/lib/couchbase/logs. The claim must match the name of a volumeClaimTemplate within the spec. If this field is not specified, then a volume will not be created.

Labels are key-value pairs that are attached to objects in Kubernetes. They are intended to specify identifying attributes of objects that are meaningful to the user and do not directly imply semantics to the core system. Labels can be used to organize and select subsets of objects. They do not need to be unique across multiple objects. This section is optional.

Labels added in this section will apply to all Couchbase server containers created in this cluster. Note that by default the Operator will add labels to each pod that may override those stated by this field. User supplied annotations should not use the couchbase.com key namespace.

For more information, see the Kubernetes documentation about labels.

Annotations are similar to labels but cannot be used for resource selection. User supplied annotations should not use the couchbase.com key namespace.

For more information, see the Kubernetes documentation about annotations.

This field specifies a key-value map of the constraints on node placement for pods. For a pod to be eligible to run on a node, the node must have each of the indicated key-value pairs as labels (it can have additional labels as well). If this section is not specified, then Kubernetes will place the pod on any available node.

For more information on isolating your Couchbase clusters from other workloads, see the pod scheduling concepts document. For more information on node selectors, see the Kubernetes documentation about label selectors.

This field specifies conditions — that usually prevent pod scheduling or execution — that should be tolerated when scheduling a pod. From the sample configuration file referenced in this topic, any node with a taint app=cbapp:NoSchedule would not usually allow the scheduler to start running any new pods upon it. You may wish to taint nodes — marking them as dedicated — for running Couchbase Server, where you don’t also want other application pods to be running on the same node and causing interference. In order to allow Couchbase pods to be scheduled to run on a tainted node the pod must tolerate all taints.

For more information on isolating your Couchbase clusters from other workloads, see the pod scheduling concepts document. For more information about tolerations, see the Kubernetes documentation on taints and tolerations.

This field allows Couchbase server pods to be run with an increased priority over other pods. Increased priority can evict lower priority pods from a node in order to accommodate resource requirements where a pod cannot be scheduled on any node.

For more information, see the Kubernetes documentation on priority classes and preemption.

Pods created by the Operator need to have permission to access the container images they run. Normally Kubernetes will use public images hosted on Docker hub that do not require authentication and authorization. When using private repositories — especially on Red Hat OpenShift — you will need to specify credentials to allow container image access.

This can be achieved in a number of different ways:

For additional information, see the Kubernetes documentation.

By default Kubernetes will mount a secret into all containers in a pod. This allows Kubernetes to provide a token that authenticates against the Kubernetes API from within a running container. This behavior may be disabled — for security reasons — by changing this field to false. If not specified this field will default to true.

Pods created by the Operator need to have permission to access the container images they run. Normally Kubernetes will use public images hosted on Docker hub that do not require authentication and authorization. When using private repositories — especially on Red Hat OpenShift — you will need to specify credentials to allow container image access.

This can be achieved in a number of different ways:

For additional information, see the Kubernetes documentation.

This field defines how Kubernetes populates Couchbase Server pods' DNS resolver. By default, when not specified, this will use the builtin cluster DNS server. This field allows the operator to inhibit the population of DNS configuration by Kubernetes. Valid values are None.

For additional information on using custom DNS servers, see the Couchbase networking concepts documentation. For additional information see the Kubernetes documentation.

This object defines DNS configuration in addition to that defined by Kubernetes under the control of the DNS policy. The nameservers sub-attribute is a list of DNS name server IP addresses. The searches sub-attribute is a list of DNS search domains.

For additional information on using custom DNS servers, see the Couchbase networking concepts documentation. For additional information see the Kubernetes documentation.

This field specifies whether the Operator should manage Couchbase buckets. This field defaults to false allowing the user to manually manage bucket settings with the Couchbase web console or the Couchbase API. If set to true, the Operator will search for CouchbaseBucket, CouchbaseEphemeralBucket and CouchbaseMemcachedBucket resources in the namespace under the control of the spec.buckets.selector field.

This field specifies which CouchbaseBucket, CouchbaseEphemeralBucket and CouchbaseMemcachedBucket resources are considered when the spec.buckets.managed field is set to true. If not specified all CouchbaseBucket, CouchbaseEphemeralBucket and CouchbaseMemcachedBucket resources are selected. If specified, then only CouchbaseBucket, CouchbaseEphemeralBucket and CouchbaseMemcachedBucket resources containing the same labels as specified in the label selector are selected.

For additional information, see the Couchbase resource label selection documentation.

This field defines whether the Operator should manage XDCR remote clusters and replications.

If set to true the Operator will assume full control of all XDCR primitives. Any existing XDCR remote clusters and replications will be deleted by the Operator unless matching configuration is provided. This field defaults to false if not set.

This list contains references to any remote clusters to replicate to.

This field specifies a textual name for the remote cluster. The name must be unique within the Couchbase cluster.

This field specifies the remote cluster UUID.

Every Couchbase cluster generates a unique cluster ID. The UUID of a remote cluster managed by the Operator is available in the CouchbaseCluster resource in the status.clusterId field.

This field specifies the hostname and port of the remote cluster.

This field specifies basic authentication on the remote cluster.

This field is only relevant if not using client certificate authentication. If specified the authentication secret must refer to a Kubernetes secret containing the keys username and password. The user on the remote cluster must have have the correct roles to allow XDCR to write to the target bucket(s).

This field defines any TLS configuration required to establish a connection with the remote cluster.

This field references a Kubernetes secret containing remote cluster TLS information. If replications to the remote cluster are to be encrypted then at least the CA certificate must be provided. The CA certificate is specified by the key ca.

If the remote cluster requires client certificate authentication then the certificate and key keys are used to specify the client certificate chain and client certificate’s private key respectively. Client certificate authentication cannot be used with basic authentication.

This field is a list of replications from the local cluster to the remote cluster.

This field defines a label selector to choose which CouchbaseReplication resources should be included for this remote cluster.

This field defines whether the Automated Backup feature is enabled for the cluster.

This field defines the path to the backup utility image that the Autonomous Operator will run to perform a backup or restore.

If left unspecified, the dynamic admission controller will automatically populate it with the most recent container image that was available when the installed version of the Autonomous Operator was released. The default image for open source Kubernetes comes from Docker Hub, and the default image for OpenShift comes from the Red Hat Container Catalog.

If pulling directly from the the Red Hat Container Catalog, then the path will be something similar to registry.connect.redhat.com/couchbase/operator-backup:6.6.0-1 (you can refer to the catalog for the most recent images). If image pull secrets are required to access the image, they are inherited from the Couchbase Server Pod and can be set explicitly with the spec.servers[].pod.spec.imagePullSecrets field or implicitly with a service account specified with the spec.servers[].pod.spec.serviceAccountName field.

This field specifies the name of a Kubernetes ServiceAccount that gives the backup and restore Pods the necessary permissions to read and create the required backup objects (running pods, jobs, cron jobs, events, etc).

If left unspecified, the dynamic admission controller will automatically default to the value of couchbase-backup. (This is the default name given to the ServiceAccount when you run cbopcfg as part of the automated backup setup procedure.

This field specifies the name of a Kubernetes Secret that gives the backup and restore Pods the necessary credentials to query buckets in AWS S3.

If left unspecified, CouchbaseBackup and CouchbaseBackupRestore objects that reference a S3 bucket in their specification will fail due to missing credentials.

This field defines resource requests and limits for the backup pods that performs backup operations. Some environments may require these fields to be explicitly set when using Kubernetes LimitRange resources without namespace defaults.

This field defines a label selector to choose which CouchbaseBackup and CouchbaseBackupRestore resources should be included for this cluster.

This field specifies which CouchbaseBackup and CouchbaseBackupRestore resources are considered when the spec.backup.managed field is set to true. If not specified all CouchbaseBackup and CouchbaseBackupRestore resources are selected. If specified, then only CouchbaseBackup and CouchbaseBackupRestore resources containing the same labels as specified in the label selector are selected.

For additional information, see the Couchbase resource label selection documentation.

This field defines affinity rules for the scheduling of CouchbaseBackup and CouchbaseBackupRestore resources.

This field is formatted as per the Kubernetes node selectors documentation. A node selector is a set of key/value pairs that a Kubernetes Node must be labeled with in order for backup and restore jobs to be scheduled onto.

This field defines toleration of anti-affinity for the scheduling of CouchbaseBackup and CouchbaseBackupRestore resources.

This field is formatted as per the Kubernetes taints and tolerations documentation. Taints provide anti-affinity rules, forcing all pods to be unschedulable on nodes with that taint. Tolerations allow backup and restore jobs to tolerate taints and be scheduled on these nodes that are now guaranteed to not have other pods running there.

This field defines whether Prometheus metric collection is enabled for the cluster.

This field defines the path to the Prometheus Exporter image that the Autonomous Operator will inject as a "sidecar" container in each Couchbase Server pod.

If left unspecified, the dynamic admission controller will automatically default to the most recent container image from Docker Hub (open source Kubernetes) or Red Hat Container Catalog (OpenShift) that was available when the installed version of the Autonomous Operator was released. Refer to Configure Prometheus Metrics Collection for more detailed instructions.

This field specifies the name of a Kubernetes Secret that should contain a bearer token value that clients use to gain access to the Prometheus metrics.

This field defines resource requests and limits for the Prometheus Exporter "sidecar" container. Some environments may require these fields to be explicitly set when using Kubernetes LimitRange resources without namespace defaults.

The metadata name identifies the claim template. This name is used by the volumeMounts to reference which template to fulfill the mount request.

If set, this attribute defines a set of labels to be merged into persistent volume claims generated by this template. The Operator reserves the right to overwrite any label as necessary for operation.

If set, this attribute defines a set of annotations to be merged into persistent volume claims generated by this template. The Operator reserves the right to overwrite any label as necessary for operation.

The storageClassName is optional for a claim. A storageClassName provides a way for administrators to describe the classes of storage they offer. If no storageClassName is specified, then the default storage class is used.

Refer to the Kubernetes documentation for more information about storage classes.

The minimum resources the volume should have. Only the storage requests are valid in this context.