Use the official Couchbase Helm Chart to deploy multiple components, including the Autonomous Operator, Admission Controller, Couchbase clusters, and Sync Gateway.
Helm is a tool that streamlines the installation and management of applications on Kubernetes platforms. The official Couchbase Helm Chart can help you easily set up the Couchbase Autonomous Operator and deploy Couchbase clusters.
This page describes how to use the Couchbase Helm Chart to create various deployments of the Autonomous Operator, Admission Controller, Couchbase clusters, and Sync Gateway.
The Couchbase Helm Chart is primarily intended to make it easy to deploy with the defaults to get a working system in an empty cluster. For more complex scenarios, make sure to refer to the operator documentation as well, particularly the operator architecture and reference architecture.
A particular use case that is complex is upgrading so make sure to cover all the Autonomous Operator upgrade and Couchbase Server upgrade sections.
The recommendation, for more complex scenarios, is to manage the operator directly rather than relying on Helm to do it as the operator provides a lot more direct control and this approach simplifies the upgrade process.
The official Couchbase Helm Chart may only be used with Enterprise Edition products, such as Couchbase Server Enterprise Edition and Sync Gateway Enterprise Edition.
Helm 3.1+ is required when installing the official Couchbase Helm Chart.
Follow Helm’s official steps for installing
helm on your particular operating system.
Add the Chart Repository
Before you can start using the Couchbase Helm Chart, you’ll need to add the chart repository to your
helm repo add couchbase https://couchbase-partners.github.io/helm-charts/
Finish by updating the repository index:
helm repo update
Install the Couchbase Helm Chart
Use the following commands to install the default Couchbase Helm Chart. The default chart deploys the Autonomous Operator, the Admission Controller, and a Couchbase cluster.
helm install <my-release> --set cluster.name=<cluster-name> couchbase/couchbase-operator
Create an image pull secret for retrieving images from the Red Hat Container Catalog:
oc create secret docker-registry rh-catalog \ --docker-server=registry.connect.redhat.com \ --docker-username=<rhel-username> \ --docker-password=<rhel-password> \ --docker-email=<docker-email>
Create a file named
openshift_values.yamlwith the following custom override values:
couchbaseOperator: image: repository: registry.connect.redhat.com/couchbase/operator tag: 2.4.0 imagePullSecrets: - rh-catalog admissionController: image: repository: registry.connect.redhat.com/couchbase/admission-controller tag: 2.4.0 imagePullSecrets: - rh-catalog cluster: image: registry.connect.redhat.com/couchbase/server:7.1.3-1
Install the chart using the custom override values:
helm install <my-release> -f openshift_values.yaml couchbase/couchbase-operator
Installing the default chart provides a quick way to try out using the Autonomous Operator for managing Couchbase Server on Kubernetes platforms. However, for more involved development and production use-cases, you will need to customize the installation to better your needs.
Customize the Installation
The Couchbase Helm Chart can be installed as-is for previewing Autonomous Operator functionality. However, customizing the installation with your own configuration will be necessary for production environments.
Customizing the chart installation allows you to do two things:
Specify which components will be deployed
Configure the deployed components
The Couchbase Helm Chart is capable of installing and configuring the Autonomous Operator, Admission Controller, Couchbase cluster, and Sync Gateway.
Enabling and configuring each component is accomplished by overriding the default values in the Couchbase Helm Chart’s
There are two methods for specifying overrides during chart installation:
--values option is the preferred method because it allows you to keep your overrides in a YAML file, rather than specifying them all on the command line.
Create a YAML file and add your overrides to it.
Here’s an example called
couchbaseOperator: imagePullPolicy: Always
Specify your overrides file when you install the chart:
helm install my-release --values myvalues.yaml couchbase/couchbase-operator
The values in your overrides file (
myvalues.yaml) will override their counterparts in the chart’s
values.yamlfile. Any values in
values.yamlthat weren’t overridden will keep their defaults.
If you only need to make minor customization, you can specify them on the command line by using the
helm install my-release --set cluster.servers.default.size=5 couchbase/couchbase-operator
This would translate to the following in the
values.yaml of the chart:
cluster: servers: default: size: 5
Any values in
values.yaml that weren’t overridden will keep their defaults.
As stated above, Helm works by override-only, with the chart providing various defaults. If you want to override a whole key in the chart, or replace it with another key, then you must explicitly disable the default in addition to adding the new one.
For example, a default bucket is created unless you configure one or otherwise set
For additional information, refer to the Helm documentation on deleting a default key.
In many cases you may only want to install a single component, such as a Couchbase cluster, or an instance of Sync Gateway.
Specific components may be enabled/disabled by overriding the default values in the
install section of the chart:
# Select what to install install: # install the couchbase operator couchbaseOperator: true # install the admission controller admissionController: true # install couchbase cluster couchbaseCluster: true # install sync gateway syncGateway: false
For example, if you wanted to have a Helm release that exclusively managed the Autonomous Operator and Admission Controller, then you would override the value for
couchbaseCluster with a value of
false, leaving only
couchbaseOperator: true and
admissionController: true, and all others
Likewise, if you already had the Autonomous Operator and Admission Controller deployed in your environment, and you just wanted to deploy a Couchbase cluster, then you would override the values for
admissionController with a value of
false, leaving only
couchbaseCluster: true, and all others
Even though the Couchbase Helm Chart has full configuration parameters for each component, if a component is disabled in the
install section, then that component’s configuration parameters are ignored.
By default, when creating a custom user, the corresponding Group resource is automatically created and bound.
users: developer: # When autobind is 'true' then the user is # created and automatically bound to a group named 'developer'. autobind: true # password to use for user authentication # (alternatively use authSecret) password: password # optional secret to use containing user password authSecret: # domain of user authentication authDomain: local # roles attributed to group roles: - name: bucket_admin bucket: default
To manually configure the corresponding Group resource, set
Deploying Sync Gateway
Sync Gateway is disabled by default in the Couchbase Helm Chart. To install the chart with Sync Gateway enabled, you will need to customize the installation to include it:
helm install mobile --set install.syncGateway=true couchbase/couchbase-operator
By default, Sync Gateway is only exposed to the internal Kubernetes network with a
To change the type of service that is used to expose Sync Gateway, you can specify an override for
syncGateway.exposeServiceType during installation:
helm install mobile --set install.syncGateway=true --set syncGateway.exposeServiceType=LoadBalancer couchbase/couchbase-operator
For more information about using Sync Gateway with the Autonomous Operator, you can refer to the Sync Gateway Tutorial.
Production deployments should enable TLS to encrypt traffic between the Autonomous Operator and the Couchbase cluster. TLS certificates can be auto-generated, or provided by the user.
Install the chart with
helm install my-release --set tls.generate=true couchbase/couchbase-operator
The Autonomous Operator will create the certificates and then configure them as Kubernetes Secrets for the cluster.
There is an issue (K8S-1900) that may cause a certificate error when using the Helm chart to upgrade the Autonomous Operator:
certificate cannot be verified for zone
This issue is caused by the certificate not having the necessary subject alternative names (SANs) required by the new version of the Autonomous Operator.
To resolve this issue, start by regenerating the Secrets from the new chart version:
The Autonomous Operator should now pick up the new certificates and proceed through the upgrade process.
Bring Your Own Certificates
Create a file named
tls_values.yaml with the following custom override values for the Couchbase Helm Chart:
cluster: tls: static: operatorSecret: tls-operator-secret serverSecert: my-tls-server-secret
Install the chart using the custom override values.
helm install my-release -f tls_values.yaml couchbase/couchbase-operator
Deploying Multiple Chart Instances (Releases)
The example installation commands on this page assume the default namespace is used (these commands don’t specify the
This is important to note because the Couchbase Helm Chart deploys both the Autonomous Operator and the Admission Controller by default, and these components should not be deployed more than once in the same namespace.
The Admission Controller should only be deployed once per Kubernetes cluster as indicated in Selective Deployment and in the operator architecture.
To prevent deployment of the Admission Controller by the Couchbase Helm Chart, you can set the
install.admissionController=false parameter either in the values file or on the command line:
helm install my-release --set install.admissionController=false couchbase/couchbase-operator
If you install the default Couchbase Helm Chart multiple times in the same namespace, then you’ll end up with multiple instances of the Autonomous Operator and the Admission Controller, which will cause errors in your deployments.
In addition, the example installation commands on this page also specify
my-release as the name for the chart release.
If you plan to use Helm to install multiple instances (releases) of the Couchbase Helm Chart, you should consider giving each release a unique name to help you more easily identify the resources that are associated with each release.
If you want Helm to generate a name for you, you can run any of the example installation commands on this page using the
-g option instead of the name parameter:
helm install -g couchbase/couchbase-operator
It is not recommended to install different versions of the Couchbase Helm Chart in the same Kubernetes cluster.
helm install command will always pull the highest version of a chart.
To list the versions of the Couchbase Helm Chart that are available for installation, you can use the
helm search command:
helm search hub couchbase
NAME CHART VERSION APP VERSION DESCRIPTION https://hub.helm.sh/charts/couchbase/couchbase-... 2.1.0 2.1.0 A Helm chart to deploy the Couchbase Autonomous...
CHART VERSION is 2.1.0, and the
APP VERSION (the Autonomous Operator version) is 2.1.0.
To install a specific version of the Couchbase Helm Chart chart, include the
--version argument during installation:
helm install my-release --version 2.1.0 couchbase/couchbase-operator
If you’re having trouble finding or installing a specific version of a chart, use the