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.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.nodeToNodeEncryption field in the CouchbaseCluster resource.

    • Bucket name handling

      In Autonomous Operator version 2.0.0, it wasn’t possible to have two clusters in a single namespace that utilized CouchbaseBucket resources that had the same metadata.name but with otherwise different configurations.

      In version 2.0.1, this issue is resolved by the new spec.name field, which, if set, overrides the metadata.name field. The spec.name field 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 cbopconv tool 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 couchbase/exporter:1.0.0 image, and does not occur with the OpenShift version of the image that is found on the Red Hat Container Catalog.

    It’s important to note that in Autonomous Operator 2.0.0, the admission controller fills in a default value of couchbase/exporter:1.0.0 for spec.monitoring.prometheus.image if it is left unspecified, and therefore this issue would always occur unless you explicitly specified a value of couchbase/exporter:1.0.1.

    In Autonomous Operator 2.0.1, the admission controller fills in a default value of couchbase/exporter:1.0.2. This updated tag is already reflected in the relevant documentation.

    The couchbase/exporter:1.0.2 image is not compatible with Autonomous Operator 2.0.0. As a result, couchbase/exporter:1.0.1 is the only (and final) Prometheus exporter image that is compatible with Autonomous Operator 2.0.0. Please note that these image compatibility issues only affect the Docker Hub-hosted images that are used with Autonomous Operator deployments on open source Kubernetes. This does not affect the Red Hat-hosted images that are used with Autonomous Operator deployments on OpenShift.

    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 cbopcfg with the intention of generating backup resources will not result in the expected behavior.

    The previous workaround for creating backup resources is no longer required, and the documentation for configuring backups has been updated with the relevant cbopcfg command.

    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, see Installing on Kubernetes and Installing on OpenShift.

    For upgrade instructions, see Upgrading the Operator.

    Platform Support

    For the latest platform support information, see Prerequisites.

    New Platform Support

    This release adds support for the following platforms:

    • Open Source Kubernetes 1.15

    • Red Hat OpenShift 4.2

    Removed Platform Support:

    This release drops support for the following platforms:

    • Couchbase Server 5.5

    • Red Hat OpenShift Container Platform 3.x

    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 cbopcfg tool doesn’t suit your environment, you can still manually install the Dynamic Admission Controller and Autonomous Operator using YAML configs:

    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:

    Read more about Couchbase Pod Upgrades.

    Logging

    The Autonomous Operator and Dynamic Admission Controller now use JSON logging. This change includes some helpful enhancements, such as pod status outputs no longer spanning multiple lines, and rebalance status now being labeled with proper cluster context.

    Fixed Issues

    Issue Description

    Summary: In releases prior to 2.0.0, removing a server class with a NodePort would fail (hang indefinitely). As a workaround, it was recommended to not use NodePorts. Starting in 2.0.0, the Autonomous Operator will remove server classes correctly when using NodePorts.

    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 The field status.members is invalid or The field status.conditions is invalid. This has been corrected in the 2.0 release.

    Summary: In releases prior to 2.0, running kubectl wait on a Couchbase Cluster resource-based deployment may have resulted in errors such as error: .status.conditions accessor error. Starting in 2.0, it is possible to run kubectl wait on Couchbase Cluster defined resources to wait until Pods are ready, etc.

    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 couchbase/exporter:1.0.0 image, and does not occur with the OpenShift version of the image that is found on the Red Hat Container Catalog.

    It’s important to note that the admission controller will fill in a default value of couchbase/exporter:1.0.0 for spec.monitoring.prometheus.image if it is left unspecified, and therefore this issue will always occur unless you follow the workaround below.

    Workaround: Explicitly specify a value of couchbase/exporter:1.0.1 for the spec.monitoring.prometheus.image field. This updated tag is already reflected in the relevant documentation.

    Summary: Running cbopcfg with the intention of generating backup resources will not result in the expected behavior.

    Workaround: Until cbopcfg is fixed, a workaround for creating backup resources is provided in the documentation for configuring backups.

    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 spec.backup.image in the running CouchbaseCluster resource configuration from revision -4 to revision -5.

    Summary: On macOS 10.15 (Catalina), you may see an error such as ./cbopcfg: cannot execute binary file when trying to execute commands included in the Autonomous Operator download package.

    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.