Release Notes for Couchbase Autonomous Operator 2.0
Couchbase Autonomous Operator 2.0 is a landmark release that’s built to take advantage of the latest Kubernetes improvements in the areas of security and custom resources. The changes in this release enable several advancements in how you can manage, monitor, and deploy Couchbase clusters.
Take a look at the What’s New page for a list of new features and improvements that are available in this release.
Release 2.0.2
Couchbase Autonomous Operator 2.0.2 was released in August 2020.
Platform Support
For the latest platform support information, refer to Prerequisites and System Requirements.
Fixed Issues
| Issue | Description |
|---|---|
Summary: An issue can occur where the Autonomous Operator incorrectly populates the Prometheus sidecar’s container specification. This only applies to configurations using TLS, and causes the Prometheus exporter to be unable to start. |
|
Summary: A memory leak in a 3rd party library dependency causes the Autonomous Operator to continually allocate memory until the host system detects memory exhaustion and terminates the Autonomous Operator process. In some circumstances, this can lead to the Autonomous Operator being unable to restart due to lock contention. |
Known Issues
| Issue | Description |
|---|---|
Summary: When running applications (such as Sync Gateway) that are using DNS SRV over TLS to connect to a Couchbase Cluster in the same Kubernetes cluster, lookup may fail hostname validation checks. Workaround: Add wildcard matches to the Subject Alternate Names (SANs) in the certificate for the Kubernetes-based host names. Specifically, add |
|
Summary: When using the Autonomous Operator to upgrade Couchbase Server from version 6.5.0 to 6.5.1, the resulting deployment may still show 6.5.0 as the version, even though the individual nodes in the pods are in fact running version 6.5.1. |
|
Summary: Logging is provided by a 3rd party library. This library adds in a sampler that can cause an array out of bounds panic due to non-standard log levels, and is generally not compatible with Couchbase support processes. This library will be removed or replaced in a future release of the Autonomous Operator. |
|
Summary: Pod readiness is performed with an exec-based probe that looks for the presence of an operator-created file. This requires the "pods/exec" privilege, and is a security concern in some environments. A new readiness method will be implemented in a future release of the Autonomous Operator. |
|
Summary: CRDs are now generated directly from source using upstream tooling. As a result, some attributes in the CRD may not be compatible with older versions of Kubernetes. An error containing the following message can be ignored, and you can feel free to follow the instructions in the message. |
Release 2.0.1
Couchbase Autonomous Operator 2.0.1 was released in May 2020.
Major Behavior Changes and Enhancements
-
Support for node-to-node encryption
Starting with this release, the Autonomous Operator now supports Couchbase Server node-to-node encryption.
Node-to-node encryption can be enabled with the new
spec.networking.tls.nodeToNodeEncryptionfield in theCouchbaseClusterresource. -
Bucket name handling
In Autonomous Operator version 2.0.0, it wasn’t possible to have two clusters in a single namespace that utilized
CouchbaseBucketresources that had the samemetadata.namebut with otherwise different configurations.In version 2.0.1, this issue is resolved by the new
spec.namefield, which, if set, overrides themetadata.namefield. Thespec.namefield can be used with all supported bucket types: Couchbase, Ephemeral, and Memcached.This enhancement also resolves a related issue caused by Kubernetes metadata names having a fixed regex that does not match the regex for Couchbase buckets. One situation in which this issue would manifest was when bucket names contained an underscore. As a result, when upgrading from version 1.2.x to 2.0, it wasn’t possible to use old buckets which had underscores in their names. The
cbopconvtool now takes this into account when upgrading from 1.2.x to version 2.0.1.
Fixed Issues
| Issue | Description | ||
|---|---|---|---|
Summary: Prometheus metrics collection will fail to run on open source Kubernetes if you use the default Prometheus exporter image.
This is the result of an issue with the It’s important to note that in Autonomous Operator 2.0.0, the admission controller fills in a default value of In Autonomous Operator 2.0.1, the admission controller fills in a default value of
|
|||
Summary: A behavioral change to XDCR in Couchbase Server 6.5.1 means that the documented method for generating connection strings will not work. This applies to incoming XDCR connections that are external to the Kubernetes cluster i.e. public networking with External DNS and generic networking. |
|||
Summary: Running The previous workaround for creating backup resources is no longer required, and the documentation for configuring backups has been updated with the relevant |
|||
Summary: The current operator-backup image in the Red Hat Container Catalog has a security grade of C due to being built on an older RHEL base image. A new image will be built to resolve this security grade and the default value for this image will be reflected in the next maintenance release. The reported vulnerability, CVE-2019-13734, is low risk in this use, as the Autonomous Operator does not use the RHEL-supplied Chrome or SQLite as described in the vulnerability. |
Release 2.0.0
Couchbase Autonomous Operator 2.0.0 was released in April 2020.
Installation and Upgrade
For installation instructions, refer to Install the Operator on Kubernetes and Install the Operator on OpenShift.
For upgrade instructions, refer to Upgrade the Operator.
Platform Support
For the latest platform support information, refer to Prerequisites and System Requirements.
Major Behavior Changes
New Couchbase Custom Resource Model
As discussed on the What’s New page, this release introduces a new model for deploying and managing Couchbase custom resources.
Previously, you would deploy a cluster using a single, monolithic CouchbaseCluster resource configuration that defined everything about a cluster (e.g. nodes, buckets, XDCR, etc).
Starting with Autonomous Operator 2.0, parts of the CouchbaseCluster resource have been separated into their own custom resource types, which the Autonomous Operator aggregates together using label selection.
The available set of Couchbase custom resource types include:
Autonomous Operator 2.0 requires that all Couchbase custom resources use the new format.
Couchbase custom resources — such as CouchbaseCluster -- are not backwards compatible between Autonomous Operator versions 1 and 2.
If you’re upgrading from Autonomous Operator 1.x, a tool (cbopconv) has been provided in the standard Autonomous Operator download package to convert your existing CouchbaseCluster resources to version 2.
Read more about how to use the cbopconv tool in the upgrade documentation.
Installation Procedure
The documented installation procedures now take advantage of the cbopcfg tool for installing both the Dynamic Admission Controller and the Autonomous Operator.
This tool greatly simplifies the installation process and accommodates most environments.
Read more about the cbopcfg tool, as well as Installing on Kubernetes and Installing on OpenShift.
|
If the |
Couchbase Pod Upgrades
The Autonomous Operator can now better handle certain configuration changes that require pods to be replaced. Some of these configuration changes include:
-
Modification of environment variables
Read more about Couchbase Pod Upgrades.
Fixed Issues
| Issue | Description |
|---|---|
Summary: In releases prior to 2.0.0, removing a server class with a |
|
Summary: Helm no longer merges Exposed Feature Sets when editing. In releases prior to 2.0.0, editing the Exposed Features, such as "client" and "admin", would be merged to "clientadmin" incorrectly. This is no longer the case with Helm Charts for 2.0 and later. |
|
Summary: When deploying on Red Hat OpenShift using the Operator Lifecycle Manager (OLM), you may see the error messages |
|
Summary: In releases prior to 2.0, running |
Known Issues
| Issue | Description |
|---|---|
Summary: Prometheus metrics collection will fail to run on open source Kubernetes if you use the default Prometheus exporter image.
This is the result of an issue with the It’s important to note that the admission controller will fill in a default value of Workaround: Explicitly specify a value of |
|
Summary: Running Workaround: Until |
|
Summary: The current operator-backup image in the Red Hat Container Catalog has a security grade of C due to being built on an older RHEL base image. A new image will be built to resolve this security grade and the default value for this image will be reflected in the next maintenance release. The reported vulnerability, CVE-2019-13734, is low risk in this use, as the Autonomous Operator does not use the RHEL-supplied Chrome or SQLite as described in the vulnerability. Workaround: Ensure you do not use Chrome from backup jobs to access websites.
Edit the image tag under |
|
Summary: On macOS 10.15 (Catalina), you may see an error such as Workaround: Update the macOS security settings as outlined in the Apple article on macOS Gatekeeper. Go to System Preferences > Security & Privacy, and under the General tab, find the header “Allow apps downloaded from” and select App Store and identified developers. |
|
Summary: A behavioral change to XDCR in Couchbase Server 6.5.1 means that the documented method for generating connection strings will not work. This applies to incoming XDCR connections that are external to the Kubernetes cluster i.e. public networking with External DNS and generic networking. Workaround: We advise the use of load-balanced XDCR endpoints as they have stable names and provide high-availability. Couchbase Server 6.5.1, however, requires that the connection string exactly matches a Couchbase Server node hostname. Additional instructions are provided to allow successful configuration of XDCR connections. |
Feedback
You can have a big impact on future versions of the Operator (and its documentation) by providing Couchbase with your direct feedback and observations. Please feel free to post your questions and comments to the Couchbase Forums.
Licenses for Third-Party Components
The complete list of licenses for Couchbase products is available on the Legal Agreements page. Couchbase is thankful to all of the individuals that have created these third-party components.