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
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
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
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
spec.spec.containers.name fields. These fields must all have the same value.
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.
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.
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
trueon Kubernetes, and
- --log-level <string>
The Operator allows control of the logging verbosity.
Valid values are
debug. The Operator will only log messages of the specified level and higher, i.e. when set to
fatal, only messages marked
panicwill be logged. This flag defaults to
- --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
- --enable-readiness <bool>
By default the Operator constrains Kubernetes rolling upgrades with
PodDisruptionBudgetresources 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
Podfile systems to indicate it is clustered and all data is replicated. This requires the
pods/execRBAC permission. If your security policy does not allow
pods/execand 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