Operator Configuration

The Couchbase Autonomous Operator configuration is defined below. When loaded into Kubernetes, it downloads the Operator Docker image, creates the CouchbaseCluster custom resource definition (CRD), and starts listening for CouchbaseCluster events. The Operator uses a deployment so that it can restart if the pod it’s running in dies.

Most of the fields in the Operator configuration should never be changed and it is recommended that you use the configuration as is. However, there are some exceptions noted below.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: couchbase-operator
  namespace: default
spec:
  replicas: 1
  template:
    metadata:
      labels:
        name: couchbase-operator
    spec:
      containers:
      - name: couchbase-operator
        image: couchbase/operator:1.2.2
        command:
        - couchbase-operator
        args:
        - -create-crd
        env:
        - name: MY_POD_NAMESPACE
          valueFrom:
            fieldRef:
              fieldPath: metadata.namespace
        - name: MY_POD_NAME
          valueFrom:
            fieldRef:
              fieldPath: metadata.name
        ports:
          - name: readiness-port
            containerPort: 8080
        readinessProbe:
          httpGet:
            path: /readyz
            port: readiness-port
          initialDelaySeconds: 3
          periodSeconds: 3
          failureThreshold: 19
        serviceAccountName: couchbase-operator

Changing the Namespace

The Operator manages clusters in the namespace that it’s deployed in. If you want to deploy the Operator in a namespace other than the default namespace, then change the metadata.namespace field.

Changing the Operator Container Image

You shouldn’t need to change the Operator image unless you are pulling the image from somewhere other than the official Couchbase Docker repository. If you are pulling the image from somewhere else, change the spec.spec.containers[0].image field.

Changing the Name

By default, the name of the deployment that is created to maintain the Operator is called couchbase-operator. It is recommended that you use this name since it is used in all of the examples and tutorials in the Operator documentation. If you need to change it for some reason, ensure that you change the metadata.name, spec.template.metadata.labels.name, and spec.spec.containers[0].name fields. These fields must all have the same value.

Changing the Service Account

It is recommended that you use a service account named couchbase-operator, but depending on your environment you may want to use a service account with a different name. Note that this field only takes effect if your Kubernetes environment has RBAC enabled.

Changing the Replica Count

Normally deployments are used to create multiple instances of a pod in order to provide redundancy. However, when deploying the Operator, you should always set replicas to 1. This is because the Operator pod uses leader election to ensure that only one Operator is running in a specific namespace. If you start more than one Operator pod in the same namespace, only the first one will start successfully. The Operator uses deployments so that if the Operator dies, a new Operator pod gets created and picks up from where the old one left off.

Command-line Arguments

You can specify a list of command-line flags to pass on to the Operator to modify its behavior.

    spec:
      containers:
      ...
        args:
        - -create-crd=false
        - -log-level=fatal
        - -pod-create-timeout=10m
        - -enable-readiness=true

--create-crd <bool>

When given sufficient privileges, the Operator can automatically install the CRD(s).

This flag is a boolean value that defaults to true on Kubernetes, and false on OpenShift.

Example:

- "-create-crd=false"

--log-level <string>

The Operator allows control of the logging verbosity.

Valid values are panic, fatal, error, warn, info and debug. The Operator will only log messages of the specified level and higher, i.e. when set to fatal, only messages marked fatal and panic will be logged. This flag defaults to info.

Example:

- "-log-level=fatal"

--pod-create-timeout <string>

The Operator allows the timeout of pod creation to be manually configured. It is primarily intended for use on cloud platforms where the deployment of multiple volumes and pulling of a Couchbase Server container image may take a longer time than the default timeout period.

Valid values are any string that can be parsed with the golang ParseDuration function. This flag defaults to 5m.

Example:

- "-pod-create-timeout=10m"

--enable-readiness <bool>

By default the Operator constrains Kubernetes rolling upgrades with PodDisruptionBudget resources and exec based readiness checks. This ensures that data is always available (provided buckets have at least one replica). To facilitate this the Operator places a file on the Pod file systems to indicate it is clustered and all data is replicated. This requires the pods/exec RBAC permission. If your security policy does not allow pods/exec and you acknowledge that Kubernetes rolling upgrades may lead to data loss this functionality may be disabled by setting this flag to false. This flag defaults to true

Example:

- "-enable-readiness=true"