CouchbaseCluster Resource

To use the Couchbase Autonomous Operator to deploy a Couchbase Server cluster, you need to create a CouchbaseCluster configuration file that describes how the cluster should be configured and maintained by the Operator. Like all Kubernetes configurations, Couchbase Server clusters are defined using either YAML or JSON (YAML is preferred by Kubernetes) and then pushed into Kubernetes.

The following CouchbaseCluster configuration shows all of the available parameters. (Note that this configuration is not valid and is meant for example purposes only.)

All available CouchbaseCluster configuration parameters
apiVersion: couchbase.com/v2
kind: CouchbaseCluster
metadata:
  name: cb-example
spec:
  image: couchbase/server:6.5.0
  paused: false
  antiAffinity: true
  softwareUpdateNotifications: true
  serverGroups:
  - us-east-1a
  - us-east-1b
  - us-east-1c
  securityContext:
    runAsUser: 1000
    runAsNonRoot: true
    fsGroup: 1000
  platform: aws
  cluster:
    clusterName: cb-example
    dataServiceMemoryQuota: 256Mi
    indexServiceMemoryQuota: 256Mi
    searchServiceMemoryQuota: 256Mi
    eventingServiceMemoryQuota: 256Mi
    analyticsServiceMemoryQuota: 1Gi
    indexStorageSetting: memory_optimized
    autoFailoverTimeout: 120s
    autoFailoverMaxCount: 3
    autoFailoverOnDataDiskIssues: true
    autoFailoverOnDataDiskIssuesTimePeriod: 120s
    autoFailoverServerGroup: false
    autoCompaction:
      databaseFragmentationThreshold:
        percent: 30
        size: 1Gi
      viewFragmentationThreshold:
        percent: 30
        size: 1Gi
      parallelCompaction: false
      timeWindow:
        start: 02:00
        end: 06:00
        abortCompactionOutsideWindow: true
      tombstonePurgeInterval: 72h
  security:
    adminSecret: my-secret
    rbac:
      managed: true
      selector:
        matchLabels:
          cluster: cb-example
    ldap:
      hosts:
      - ldap.example.com
      bindDN: "cn=admin,dc=example,dc=com"
      bindSecret: cb-example-auth
      userDNMapping:
        template: "uid=%s,ou=People,dc=example,dc=com"
  networking:
    exposeAdminConsole: true
    adminConsoleServices:
    - data
    adminConsoleServiceType: LoadBalancer
    exposedFeatures:
    - xdcr
    exposedFeatureServiceType: LoadBalancer
    exposedFeatureTrafficPolicy: Local
    tls:
      static:
        serverSecret: couchbase-server-tls
        operatorSecret: couchbase-operator-tls
      clientCertificatePolicy: mandatory
      clientCertificatePaths:
      - path: san.email
        prefix: ""
        delimiter: "@"
    dns:
      domain: couchbase-0.us-east-1.example.com
    serviceAnnotations:
      my-annotation: my-value
    loadBalancerSourceRanges:
    - "10.0.0.0/8"
  logging:
    logRetentionTime: 604800s
    logRetentionCount: 20
  servers:
  - size: 1
    name: all_services
    services:
    - data
    - index
    - query
    - search
    - eventing
    - analytics
    serverGroups:
    - us-east-1a
    env:
    - name: ENV1
      value: value
    envFrom:
    - secretRef:
        name: environment-secret
    resources:
      limits:
        cpu: 4
        memory: 8Gi
      requests:
        cpu: 2
        memory: 8Gi
    volumeMounts:
      default: couchbase
      data:  couchbase
      index: couchbase
      analytics:
      - couchbase
      - couchbase
    pod:
      metadata:
        labels:
          couchbase_services: all
        annotations:
          couchbase.acme.com: production
      spec:
        nodeSelector:
          instanceType: large
        tolerations:
        - key: app
          operator: Equal
          value: cbapp
          effect: NoSchedule
        priorityClassName: high-priority
        automountServiceAccountToken: false
        serviceAccountName: couchbase-pods
        imagePullSecrets:
        - name: my-pull-secret
        dnsPolicy: None
        dnsConfig:
          nameservers:
          - "10.0.0.2"
          searches:
          - cluster.local
  buckets:
    managed: true
    selector:
      matchLabels:
        cluster: cb-example
  xdcr:
    managed: true
    remoteClusters:
    - name: remote
      uuid: 611e50b21e333a56e3d6d3570309d7e3
      hostname: 10.1.0.2:31851
      authenticationSecret: my-xdcr-secret
      tls:
        secret: my-xdcr-tls-secret
      replications:
        selector:
          matchLabels:
            cluster: cb-example
  backup:
    managed: true
    image: couchbase/operator-backup:6.5.0
    serviceAccountName: couchbase-backup
    resources:
      requests:
        cpu: 100m
        memory: 100Mi
    selector:
      matchLabels:
        cluster: cb-example
  monitoring:
    prometheus:
      enabled: true
      image: couchbase/exporter:1.0.1
      authorizationSecret: cb-metrics-token
      resources:
        requests:
          cpu: 100m
          memory: 100Mi
  volumeClaimTemplates:
  - metadata:
      name: couchbase
    spec:
      storageClassName: "standard"
      resources:
        requests:
          storage: 1Gi

Top-Level Definitions

The following are the top-level parameters for a CouchbaseCluster configuration:

apiVersion: couchbase.com/v2
kind: CouchbaseCluster
metadata:
  name: cb-example
  namespace: default

apiversion

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.

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

kind

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

Field rules: This field is required and must always be set to CouchbaseCluster. The value of this field cannot be changed after the cluster is created.

metadata.name

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.

Field rules: This field must be a valid DNS hostname string.

spec

This section describes the top-level parameters related to a Couchbase cluster deployment.

spec:
  image: couchbase/server:6.5.0
  paused: false
  antiAffinity: true
  softwareUpdateNotifications: true
  serverGroups:
  - us-east-1a
  - us-east-1b
  - us-east-1c
  securityContext:
    runAsUser: 1000
    runAsNonRoot: true
    fsGroup: 1000
  platform: aws

spec.image

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.5.0. For Red Hat images for use with OCP this should be similar to registry.connect.redhat.com/couchbase/server:6.5.0-2. 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.

Field rules: The image field is required and must be a valid container image.

spec.paused

This field specifies whether or not the Operator is currently managing this cluster. This parameter should generally be set to true, but may be set to false if you decide to make manual changes to the cluster. By disabling the Operator 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.

Field rules: The paused field is optional and defaults to false if not specified.

spec.antiAffinity

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.

Field rules: The antiAffinity field is optional and defaults to false if not specified.

spec.softwareUpdateNotifications

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.

Field rules: The softwareUpdateNotifications field is optional and defaults to false if not specified. This setting can be modified at any point in the cluster life-cycle.

spec.serverGroups

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:

kubectl label nodes ip-172-16-0-10 failure-domain.beta.kubernetes.io/zone=us-east-1a

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.

Field rules: The serverGroups field is optional. If set pods will be scheduled across the specified set of server groups. The server groups must be set at cluster creation time, and currently should be assumed to be immutable.

spec.securityContext

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.

Field rules: The securityContext field is optional. If set, this will be attached to all new pods that are created by the Operator.

spec.platform

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

Field rules: The platform field is optional. The Value must be one of aws, gce or azure.

spec.cluster

This object allows configuration of global Couchbase cluster settings.

spec:
  cluster:
    clusterName: cb-example
    dataServiceMemoryQuota: 256Mi
    indexServiceMemoryQuota: 256Mi
    searchServiceMemoryQuota: 256Mi
    eventingServiceMemoryQuota: 256Mi
    analyticsServiceMemoryQuota: 1Gi
    indexStorageSetting: memory_optimized
    autoFailoverTimeout: 120s
    autoFailoverMaxCount: 3
    autoFailoverOnDataDiskIssues: true
    autoFailoverOnDataDiskIssuesTimePeriod: 120s
    autoFailoverServerGroup: false
    autoCompaction:
      databaseFragmentationThreshold:
        percent: 30
        size: 1Gi
      viewFragmentationThreshold:
        percent: 30
        size: 1Gi
      parallelCompaction: false
      timeWindow:
        start: 02:00
        end: 06:00
        abortCompactionOutsideWindow: true
      tombstonePurgeInterval: 72h

spec.cluster.clusterName

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.

field rules: This field is optional and must be a string.

spec.cluster.dataServiceMemoryQuota

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.

Field rules: This field is optional and must be a resource quantity greater than or equal to 256Mi. The sum of all memory quotas must be no more than 80% of a pod’s available memory.

spec.cluster.indexServiceMemoryQuota

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.

Field rules: This field is optional and must be a resource quantity greater than or equal to 256Mi. The sum of all memory quotas must be no more than 80% of a pod’s available memory.

spec.cluster.searchServiceMemoryQuota

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.

Field rules: This field is optional and must be a resource quantity greater than or equal to 256Mi. The sum of all memory quotas must be no more than 80% of a pod’s available memory.

spec.cluster.eventingServiceMemoryQuota

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.

Field rules: This field is optional and must be a resource quantity greater than or equal to 256Mi. The sum of all memory quotas must be no more than 80% of a pod’s available memory.

spec.cluster.analyticsServiceMemoryQuota

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.

Field rules: This field is optional and must be a resource quantity greater than or equal to 1GI. The sum of all memory quotas must be no more than 80% of a pod’s available memory.

spec.cluster.indexStorageSetting

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.

Field rules: The indexStorageSetting is optional and defaults to memory_optimized. Values allowed are plasma or memory_optimized. After the Couchbase cluster is deployed, the value of this field can only be changed if there are no Index nodes in the cluster.

spec.cluster.autoFailoverTimeout

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

Field rules: The autoFailoverTimeout is optional and must be a duration in the range 5s-3600s.

spec.cluster.autoFailoverMaxCount

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.

Field rules: The autoFailoverMaxCount is required and must be in the range 1-3.

spec.cluster.autoFailoverOnDataDiskIssues

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

Field rules: The autoFailoverOnDataDiskIssues is required and must be true or false.

spec.cluster.autoFailoverOnDataDiskIssuesTimePeriod

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

Field rules: The autoFailoverOnDataDiskIssuesTimePeriod is only required if autoFailoverOnDataDiskIssues is also set to true. It must be a duration in the range 5s-3600s.

spec.cluster.autoFailoverServerGroup

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

Field rules: The autoFailoverServerGroup is optional, defaulting to false.

spec.cluster.autoCompaction

This object allows configuration of global Couchbase auto-compaction settings.

It is far more efficient to append database updates to files rather than rewriting them. This gives rise to stale data within the database file. This is known as fragmentation.

Auto compaction is required periodically to reclaim disk space caused by fragmentation. Auto compaction occurs automatically by default in Couchbase Server.

spec:
  cluster:
    autoCompaction:
      databaseFragmentationThreshold:
        percent: 30
        size: 1Gi
      viewFragmentationThreshold:
        percent: 30
        size: 1Gi
      parallelCompaction: false
      timeWindow:
        start: 02:00
        end: 06:00
        abortCompactionOutsideWindow: true
      tombstonePurgeInterval: 72h

spec.cluster.autoCompaction.databaseFragmentationThreshold.percent

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

Field rules: This field is optional and must be an integer in the range 2-100.

spec.cluster.autoCompaction.databaseFragmentationThreshold.size

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

Field rules: This field is optional and must be a Kubernetes resource quantity.

spec.cluster.autoCompaction.viewFragmentationThreshold.percent

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

This field defaults to 30.

Field rules: This field is optional and must be an integer in the range 2-100.

spec.cluster.autoCompaction.viewFragmentationThreshold.size

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

Field rules: This field is optional and must be a Kubernetes resource quantity.

spec.cluster.autoCompaction.parallelCompaction

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.

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

spec.cluster.autoCompaction.timeWindow.start

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.

Field rules: This field is optional and must be a string in the form HH:MM where HH is in the range 0-23 and MM is in the range 0-59.

spec.cluster.autoCompaction.timeWindow.end

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.

Field rules: This field is optional and must be a string in the form HH:MM where HH is in the range 0-23 and MM is in the range 0-59.

spec.cluster.autoCompaction.timeWindow.abortCompactionOutsideWindow

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.

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

spec.cluster.autoCompaction.tombstonePurgeInterval

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.

Field rules: This field is optional and must be a valid duration in the range 1h-60d.

spec.security

This object allows configuration of global Couchbase security settings and RBAC.

spec:
  security:
    adminSecret: my-secret
    rbac:
      managed: true
      selector:
        matchLabels:
          cluster: cb-example

spec.security.adminSecret

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

Field rules: The adminSecret field is required and should reference the name of a Kubernetes Secret that already exists. The value of this field cannot be changed after the cluster is created.

spec.security.rbac

spec:
  security:
    rbac:
      managed: true
      selector:
        matchLabels:
          cluster: cb-example

spec.security.rbac.managed

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.

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

spec.security.rbac.selector

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.

Field rules: This field is optional and must be a Kubernetes LabelSelector object.

spec.security.ldap

spec:
  security:
    ldap:
      hosts:
      - ldap.example.com
      port: 389
      bindDN: "cn=admin,dc=example,dc=com"
      bindSecret: cb-example-auth
      authenticationEnabled: true
      userDNMapping:
        template: "uid=%s,ou=People,dc=example,dc=com"
      authorizationEnabled: true
      groupsQuery: "cn=users,ou=Groups,dc=example,dc=com??base?"
      nestedGroupsEnabled: true
      encryption: StartTLSExtension
      tlsSecret: ldap-secret

spec.security.ldap.hosts

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

Field rules: This field is required and must be a list of at least one hostname.

spec.security.ldap.port

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

Field rules: This field is optional and default to 389 if not specified.

spec.security.ldap.bindDN

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).

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

spec.security.ldap.bindSecret

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).

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

spec.security.ldap.authenticationEnabled

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.

Field rules: This field is optional and must be a boolean. The default value is true.

spec.security.ldap.userDNMapping.template

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.

Field rules: This field is optional and must be a string. The spec.secure.ldap.authenticationEnabled field must also be true.

spec.security.ldap.authorizationEnabled

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.

Field rules: This field is optional and must be a boolean. The default value is true.

spec.security.ldap.groupsQuery

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

Field rules: This field is optional and must be a string. The spec.secure.ldap.authorizationEnabled field must also be true.

spec.security.ldap.encryption

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.

Field rules: This field is optional and must be either None, TLS, StartTLSExtension. The default value is None (to connect without encryption — this is insecure, and therefore is not recommended).

spec.security.ldap.tlsSecret

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

Field rules: This field is optional and must be a kubernetes secret containing a certificate in PEM format.

spec.networking

This object allows configuration of network related options. These options allow you to connect to Couchbase from outside the Kubernetes cluster, and secure network traffic with transport layer security (TLS).

spec:
  networking:
    exposeAdminConsole: true
    adminConsoleServices:
    - data
    adminConsoleServiceType: LoadBalancer
    exposedFeatures:
    - xdcr
    exposedFeatureServiceType: LoadBalancer
    exposedFeatureTrafficPolicy: Local
    dns:
      domain: couchbase-0.us-east-1.example.com
    serviceAnnotations:
      my-annotation: my-value
    loadBalancerSourceRanges:
    - "10.0.0.0/8"
    tls:
      static:
        serverSecret: couchbase-server-tls
        operatorSecret: couchbase-operator-tls
      clientCertificatePolicy: mandatory
      clientCertificatePaths:
      - path: san.email
        prefix: ""
        delimiter: "@"

spec.networking.exposeAdminConsole

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.

Field rules: The exposeAdminConsole field is optional and defaults to false if not specified. If set to true the specification must also have the spec.networking.adminConsoleServices property defined.

spec.networking.adminConsoleServices

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.

Field rules: The adminConsoleServices list is optional and defaults to an empty list. Valid item names are data, index, query, search, eventing, and analytics, and must be unique. An empty list means that any node in the cluster may be chosen when connecting to the Couchbase Server Web Console.

spec.networking.adminConsoleServiceType

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.

Field rules: The adminConsoleServiceType field is optional and defaults to NodePort. Allowed values are NodePort and LoadBalancer. If this field is LoadBalancer then you must also define a spec.dns.domain.

spec.networking.exposedFeatures

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:

admin

Exposes the admin API and UI

xdcr

Exposes the ports necessary to support XDCR via L3 connectivity at the cluster network layer.

client

Exposes all client services. These include data, views, query, full text search, analytics.

Field rules: The exposedFeatures list is optional, no feature sets are exposed to the cluster network if unset.

spec.networking.exposedFeatureServiceType

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.

Field rules: The exposedFeatureServiceType field is optional and defaults to NodePort. Allowed values are NodePort and LoadBalancer. If this field is LoadBalancer then you must also define a spec.dns.domain.

spec.networking.exposedFeatureTrafficPolicy

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.

Field rules: The exposedFeatureTrafficPolicy field is optional and defaults to Local. Allowed values are Local and Cluster.

spec.networking.serviceAnnotations

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

Field rules: The serviceAnnotations field is optional. If specified it must be a map of key/value pairs conforming to Kubernetes annotation rules.

spec.networking.dns

This section describes the configuration of the dynamic domain name system [DDNS]. When exposing services to the public internet we mandate that TLS is used to protect against plain text user names, passwords and data. DDNS is used to dynamically populate the DNS with Couchbase nodes during the cluster lifecycle so they are addressable with stable names.

Given the example domain couchbase-0.us-east-1.example.com it will annotate the admin service as requiring the name console.couchbase-0.us-east-1.example.com to be added to the DNS when using the LoadBalancer service type. When a pod is created with the name couchbase-0000 it will annotate the per-pod exposed features service as requiring the name couchbase-0000.couchbase-0.us-east-1.example.com to be added to the DNS when using the LoadBalancer service type.

The user is required to use these annotations to actually create the DNS entries as the services are created, updated and modified. The recommended solution is the Kubernetes External DNS integration. As such services will be annotated with external-dns.alpha.kubernetes.io/hostname.

The DNS configuration can also be used with the NodePort external feature type. This allows the cluster to be addressed with DNS over private networks e.g. through a VPN. In this mode of operation the Operator does not enforce the use of TLS. To create A records for your individual Couchbase server nodes, map the service DNS name annotation to the associated pod’s node IP address.

The individual DNS per-pod exposed service A records should be dynamically collated into an SRV record. This provides a stable name for the cluster as nodes are added and removed during the cluster lifecycle, and service discovery. The resource name for the given examples should be _couchbases._tcp.couchbase-0.us-east-1.example.com, with equal priority and weight and a port value of 11207.
When creating your cluster TLS certificates you will need to add a wildcard entry in the subject alternate names list for your specified domain. For the given examples this would be DNS:*.couchbase-0.us-east-1.example.com.
Exposing database services to public networks is inherently dangerous. XDCR and client connectivity can also be achieved with secure IPSEC tunnels.
spec:
  dns:
    domain: couchbase-0.us-east-1.example.com

spec.networking.dns.domain

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.

Field rules: The domain field is required when either the exposedFeatureServiceType or adminConsoleServiceType fields are configured as LoadBalancer.

spec.networking.tls

This field is optional and controls whether the Operator uses TLS for communication with the cluster. It also sets the TLS certificates that are used by Couchbase clients and XDCR. Refer to the TLS documentation for more information.

spec:
  networking:
    tls:
      static:
        serverSecret: couchbase-server-tls
        operatorSecret: couchbase-operator-tls
      clientCertificatePolicy: mandatory
      clientCertificatePaths:
      - path: san.email
        prefix: ""
        delimiter: "@"

spec.networking.tls.static.serverSecret

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.

Field rules: This field is required when spec.networking.tls.static is defined and must be a string referencing a Kubernetes Secret resource.

spec.networking.tls.static.operatorSecret

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.

Field rules: This field is required when spec.networking.tls.static is defined and must be a string referencing a Kubernetes Secret resource.

spec.networking.tls.clientCertificatePolicy

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.

Field rules: This field is optional and must be either enable or mandatory.

spec.networking.tls.clientCertificatePaths[]

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

Field rules: If using client certificates this list should contain at least one item.

spec.networking.tls.clientCertificatePaths[].path

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.

Field rules: This field is required and must be either subject.cn, san.uri, san.dns or san.email.

spec.networking.tls.clientCertificatePaths[].prefix

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..

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

spec.networking.tls.clientCertificatePaths[].delimiter

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 @.

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

spec.logging

This object allows configuration of Operator logging functionality. This ensures any persistent logs do not consume excessive amounts of resource or persist for too long.

spec:
  logging:
    logRetentionTime: 604800s
    logRetentionCount: 20

spec.logging.logRetentionTime

This field is used in conjunction with the logs persistent volume mount. The value can be anything that can be parsed by the golang ParseDuration function. 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.

Field rules: The logRetentionTime field is optional and defaults to "". If specified it must contain a decimal number and a unit suffix such as s, m or h. The decimal number cannot be negative.

spec.logging.logRetentionCount

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.

Field rules: The logRetentionCount field is optional and defaults to 0. The value must be any non-negative integer.

spec.servers[]

This object allows the configuration of the Couchbase cluster topology. Servers are grouped in to server classes also known as multi-dimensional scaling (MDS) groups. You must specify at least one server class. At least one server class must contain the data service.

Modifying any field in the spec.servers object that affects the underlying pod will trigger an upgrade, as pods are immutable. Fields that do not trigger an upgrade include:

  • size — attribute modification triggers a scaling operation.

  • name — attribute modification replaces the entire server class with a new one.

  • services — attribute is immutable.

spec:
  servers:
  - size: 1
    name: all_services
    services:
    - data
    - index
    - query
    - search
    - eventing
    - analytics
    serverGroups:
    - us-east-1a
    env:
    - name: ENV1
      value: value
    envFrom:
    - secretRef:
        name: environment-secret
    resources:
      limits:
        cpu: 4
        memory: 8Gi
      requests:
        cpu: 2
        memory: 8Gi
    volumeMounts:
      default: couchbase
      data:  couchbase
      index: couchbase
      analytics:
      - couchbase
      - couchbase
    pod:
      metadata:
        labels:
          couchbase_services: all
        annotations:
          couchbase.acme.com: production
      spec:
        nodeSelector:
          instanceType: large
        tolerations:
        - key: app
          operator: Equal
          value: cbapp
          effect: NoSchedule
        priorityClassName: high-priority
        automountServiceAccountToken: false
        serviceAccountName: couchbase-pods
        imagePullSecrets:
        - name: my-pull-secret
        dnsPolicy: None
        dnsConfig:
          nameservers:
          - "10.0.0.2"
          searches:
          - cluster.local

spec.servers[].size

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 runtime, the Operator will automatically scale the cluster.

Field rules: The size is required and can be set to greater than or equal to 1.

spec.servers[].name

This field specifies a name for this group of servers.

Field rules: The name field is required and must be unique in comparison to the name field of other server definitions. The value of this field should not be changed after a server class has been defined. See spec.servers[] for more details.

spec.servers[].services

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.

Field rules: The services list is required and must contain at least one service. Valid values for services are data, index, query, search, eventing and analytics. The values of this list cannot be changed after a server has been defined.

spec.servers[].serverGroups

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.

spec.servers[].env

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.

Field rules: This field must be a map of key-value pairs where both are strings.

spec.servers[].envFrom

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.

Field rules: The value of this field must be an array of Kubernetes EnvFromSource types. This field is optional.

spec.servers[].resources

spec:
  servers:
  - resources:
      limits:
        cpu: 2
        memory: 8Gi
      requests:
        cpu: 1.5
        memory: 8Gi
limits

This field lets you reserve resources on a specific node. It defines the maximum amount of CPU and memory the pods created in this node specification can allocate. Exceeding these limits will cause the offending pod to be terminated.

requests

This field lets you reserve resources on a specific node. The requests section defines the minimum amount of CPU and memory the pods created in this node specification will reserve.

In general, CPU limits are specified as the number of threads required on physical hardware (vCPUs if in the cloud), and memory is specified in bytes. Refer to the Kubernetes documentation for more information about managing compute resources.

spec.servers[].volumeMounts

spec:
  servers:
  - volumeMounts:
      default: couchbase
      data:  couchbase
      index: couchbase
      analytics:
        - couchbase
        - couchbase

The VolumeMounts configuration specifies the claims to use for the storage that is used by the Couchbase Server cluster.

spec.servers[].volumeMounts.default

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.

Field rules: The default volume mount may be specified for production clusters or those that require support. Please consult the best practices guide for more information. It must be specified with server classes running any of the data, index or analytics services. It may however, be used with any service. It cannot be specified at the same time as the logs volume mount for a specific server configuration.

spec.servers[].volumeMounts.data

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.

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

spec.servers[].volumeMounts.index

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.

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

spec.servers[].volumeMounts.analytics[]

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.

spec.servers[].volumeMounts.logs

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.

Field rules: The logs volume mount may be specified for production clusters that require support. Please consult the best practices guide for more information. It may only be specified with server classes not running any of the data, index or analytics services. It cannot be specified at the same time as the default volume mount a specific server configuration.

spec.servers[].pod

The pod attribute is based on the Kubernetes PodTemplateSpec structure and allows all supported configuration parameters to be modified. The Operator will override the following fields, therefore must not be explicitly set by the user:

The following parameters are modified by the Operator to merge configuration required to function, and caution should be used when setting these parameters as they may be overwritten:

spec:
  servers:
   - pod:
      metadata:
        labels:
          couchbase_services: all
        annotations:
          couchbase.acme.com: production
      spec:
        nodeSelector:
          instanceType: large
        tolerations:
        - key: app
          operator: Equal
          value: cbapp
          effect: NoSchedule
        priorityClassName: high-priority
        automountServiceAccountToken: false
        serviceAccountName: couchbase-pods
        imagePullSecrets:
        - name: my-pull-secret
        dnsPolicy: None
        dnsConfig:
          nameservers:
          - "10.0.0.2"
          searches:
          - cluster.local

spec.servers[].pod.metadata.labels

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.

Field rules: The value of this field cannot be changed after a server has been defined.

spec.servers[].pod.metadata.annotations

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.

Field rules: The value of this field must be a map of key value pairs. This field is optional and immutable.

spec.servers[].pod.spec.nodeSelector

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.

Field rules: This field is optional and must be a Kubernetes node selector object.

spec.servers[].pod.spec.tolerations

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.

Field rules: This field is optional and must be a list of Kubernetes toleration objects.

spec.servers[].pod.spec.priorityClassName

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.

Field rules: This field is optional and must be the name of an existing PriorityClass resource.

spec.servers[].pod.spec.imagePullSecrets

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:

  • Associating an image pull secret with the default service account. This may be a security risk as it will automatically apply to any containers created in the namespace.

  • Using the spec.servers[].pod.spec.imagePullSecrets attribute to explicitly specify secrets that are used for credentials.

  • Using the spec.servers[].pod.spec.serviceAccountName attribute to run the pods as a specified service account. This service account may implicitly be associated with secrets that are used for credentials.

For additional information, see the Kubernetes documentation.

Field rules: The value of this field is optional and must be a Kubernetes image pull secrets list.

spec.servers[].pod.spec.automountServiceAccountToken

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.

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

spec.servers[].pod.spec.serviceAccountName

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:

  • Associating an image pull secret with the default service account. This may be a security risk as it will automatically apply to any containers created in the namespace.

  • Using the spec.servers[].pod.spec.imagePullSecrets attribute to explicitly specify secrets that are used for credentials.

  • Using the spec.servers[].pod.spec.serviceAccountName attribute to run the pods as a specified service account. This service account may implicitly be associated with secrets that are used for credentials.

For additional information, see the Kubernetes documentation.

Field rules: The serviceAccountName field is optional and must be string.

spec.servers[].pod.spec.dnsPolicy

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.

Field rules: The dnsPolicy field is optional and must be a string.

spec.servers[].pod.spec.dnsConfig

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 nameserver 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.

Field rules: The dnsConfig field is optional and must be a valid Kubernetes DNS configuration object.

spec.buckets

This object defines whether to manage buckets and how to select which bucket resources to use.

spec:
  buckets:
    managed: true
    selector:
      matchLabels:
        cluster: cb-example

spec.buckets.managed

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.

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

spec.buckets.selector

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.

Field rules: This field is optional and must be a Kubernetes LabelSelector object.

spec.xdcr

This object defines whether to manage XDCR, any remote clusters and replications to them.

As the Couchbase Server API does not expose XDCR passwords or TLS certificates these cannot be automatically rotated by the Operator. In order to rotate these either manually update or delete and recreate the remote cluster.

spec:
  xdcr:
    managed: true
    remoteClusters:
    - name: remote
      uuid: 611e50b21e333a56e3d6d3570309d7e3
      hostname: 10.1.0.2:31851
      authenticationSecret: my-xdcr-secret
      tls:
        secret: my-xdcr-tls-secret
      replications:
        selector:
          matchLabels:
            cluster: cb-example

spec.xdcr.managed

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.

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

spec.xdcr.remoteClusters[]

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

spec.xdcr.remoteClusters[].name

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

Field rules: This field is required and must be a string.

spec.xdcr.remoteClusters[].uuid

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.

Field rules: This field is required and must be a Couchbase UUID string.

spec.xdcr.remoteClusters[].hostname

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

Field rules: This field is required and must be a valid DNS domain name and admin port (either plain text or TLS).

spec.xdcr.remoteClusters[].authenticationSecret

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).

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

spec.xdcr.remoteClusters[].tls.secret

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.

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

spec.xdcr.remoteClusters[].replications[]

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

spec.xdcr.remoteClusters[].replications[].selector

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

Field rules: This field is optional and must be a Kubernetes label selector.

spec.backup

This object defines parameters and variables for automated backup.

spec:
  backup:
    managed: true
    image: couchbase/operator-backup:6.5.0
    serviceAccountName: couchbase-backup
    resources:
      requests:
        cpu: 100m
        memory: 100Mi
    selector:
      matchLabels:
        cluster: cb-example

spec.backup.managed

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

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

spec.backup.image

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.5.0-4 (you can refer to the catalog for the most recent images). If ImagePullSecrets 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.

Field rules: This field is optional and must be a valid path to a valid container image.

spec.backup.serviceAccountName

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, CronJobs, 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.

Field rules: This field is optional and must be the name of a valid Kubernetes Service Account.

spec.backup.resources

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.

Field rules: This field is optional and must be a valid Kubernetes resource descriptor.

spec.backup.selector

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.

Field rules: This field is optional and must be a Kubernetes label selector.

spec.monitoring

This object defines any integrations with third party monitoring software.

spec:
  monitoring:
    prometheus:
      enabled: true
      image: couchbase/exporter:1.0.1
      authorizationSecret: cb-metrics-token
      resources:
        requests:
          cpu: 100m
          memory: 100Mi

spec.monitoring.prometheus.enabled

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

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

spec.monitoring.prometheus.image

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.

Field rules: This field is optional and must be a valid path to a valid container image.

spec.monitoring.prometheus.authorizationSecret

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.

Field rules: This field is optional and must be the name of a valid Kubernetes secret, with a key of "token".

spec.monitoring.prometheus.resources

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.

Field rules: This field is optional and must be a valid Kubernetes resource descriptor.

spec.volumeClaimTemplates[]

This list defines templates of persistent volume claims. At runtime, the Operator will create a persistent volume from these templates for each pod referencing them. Claims can request volumes from various types of storage systems as identified by the storage class name.

spec:
  volumeClaimTemplates:
    - metadata:
        name: couchbase
      spec:
        storageClassName: "standard"
        resources:
          requests:
            storage: 1Gi

spec.volumeClaimTemplates[].metadata.name

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

spec.volumeClaimTemplates[].spec.storageClassName

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.

spec.volumeClaimTemplates[].spec.resources

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