Release Notes for Couchbase Autonomous Operator 2.3
Couchbase Autonomous Operator 2.3 is a significant release that expands support for Couchbase Server 7, providing full support for scope and collections.
Take a look at the What’s New page for a list of new features and improvements that are available in this release.
The necessary steps needed to upgrade to this release depend on which version of the Autonomous Operator you are upgrading from.
There is no direct upgrade path from versions prior to 2.0.x. To upgrade from a 1.x.x release, you must first upgrade to 2.0.x, paying particular attention to supported Kubernetes platforms and Couchbase Server versions. Refer to the 2.0.x upgrade steps if upgrading from a 1.x.x release.
Additional steps and considerations are required when upgrading from version 2.0.x. Please refer to Upgrading from Version 2.0.x.
There are no additional upgrade steps or considerations when upgrading from this version. You may follow standard upgrade process.
First, ensure that you are running compatible versions of Kubernetes and Couchbase Server before upgrading.
If you are not utilizing TLS, you can skip this section.
The TLS requirements have been modified as of Autonomous Operator 2.1. In order to ease the migration from legacy client bootstrap (CCCP) to the newest version (GCCCP), the Autonomous Operator requires Couchbase cluster subject alternative names (SANs) to be updated. Consult the TLS tutorial for a full list of all the required SANs, and the TLS rotation guide in order to prepare for upgrade. Failure to perform this step will result in errors from the dynamic admission controller (DAC) once upgraded.
When upgrading from version 2.0.x, Couchbase clusters will undergo a mandatory upgrade cycle.
Pod readiness checks were previously driven by an
exec based readiness probe.
This was a security concern because it granted the Autonomous Operator
pods/exec privileges, which may not be acceptable in highly regulated environments.
As of Autonomous Operator 2.1, readiness checks are performed using readiness gates that use the Kubernetes API exclusively.
You can use the
couchbaseclusters.spec.rollingUpgrade configuration parameter to speed up this upgrade.
To enable this feature while upgrading the Autonomous Operator, stop the old Operator, replace the CRDs, edit the
couchbaseclusters.spec.rollingUpgrade field to enable bulk upgrades, then start the new Operator.
Refer to Upgrade the Operator for further details.
Couchbase Autonomous Operator 2.3.0-beta1 was released in October 2021.
The new default image for logging is
This image features functional and security updates.
Existing clusters will continue to use the logging version they were provisioned with. Should you wish to update existing Couchbase clusters to make use of this new image, then they will undergo a rolling upgrade to facilitate the update. You should plan a maintenance window accordingly.
The Operator now has the ability to fully manage scopes and collections within a bucket. Scopes and collections provide fine grained access control and replication, and improved scalability.
For further information consult the Scopes and Collections Concepts documentation.
Due to interface changes introduced in Couchbase Server 7.0, a new backup image (1.2.0) is the only supported version that will run with Operator 2.3. It continues to support operation with Couchbase Server version 6.5 and 6.6.
Ensure that any backup jobs are upgraded to use the new image when moving to Operator 2.3.
Backup 1.2.0 fully supports operation with Couchbase scopes and collections. Additional improvements include support for filtering of backup source data — thus minimizing backup size and improving performance, and the addition of new options for filtering restore data — such as with document key and value regular expressions.
Prior to this release, the dynamic admission controller was utilized to provide some defaults to Couchbase custom resources. The vast majority of these defaults have already been migrated to native CRD defaulting. Mutation has now been fully removed to provide out-of-the-box compatibility with platforms like GKE Autopilot where mutation is prohibited.
Some defaults were not able to be migrated so have been removed entirely:
Default file system groups for persistent volumes (does not affect Red Hat OCP). When using Couchbase with PVCs, the operator tries to reuse data where possible. In order for an old volume to be used by a new pod, the data needs to be read and written by the same group across all pods. Clusters that use backups are also affected, as these reuse PVCs across backup jobs.
Previously the DAC provided dynamic defaults depending on the platform (Kubernetes/Red Hat OCP). While OCP should work without specifying the file system group, Kubernetes users will need to explicitly specify the group when using persistent volumes. Follow the existing persistent volume concepts documentation for guidance on configuration.
Backup and Prometheus images. These were dynamically populated by the DAC for ease of use, depending on platform. These fields are now marked as required to be provided by the end user. Up to date images can be found on Docker hub and the Red Hat container catalog. See the prerequisites documentation for compatible image versions.
Previous releases came bundled with
cbopinfo binaries to aid installation and support requests respectively.
While these binaries are still part of the distribution, the new
cao binary features all the existing functionality of these tools, and extends the feature set to allow self-service platform certification.
cbopinfo binaries are now deprecated and will be removed in a later release.
You should update any tooling to use
cao, or you can alias existing commands to use the new binary:
$ alias cbopcfg='cao' $ alias cbopinfo='cao collect-logs'
Summary: When recovering a pod and using persistent volume storage, there is the possibly of a race condition when running the Couchbase Server pod’s initialization container. This occurs when the underlying storage provider returns an error, rather than a definitive answer a to whether a file exists. The error appears as if the file doesn’t exist, and so the container erroneously reinitializes its persistent storage and resets configuration, particularly storage path locations. This fix removes the condition check, and replaces with a non-destructive copy instead.
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.
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.