Release Notes for Couchbase Autonomous Operator 2.5
Autonomous Operator 2.5 release is primarily focused on platform updates, feature parity with Couchbase Server, improvements to Pod Management and Security, as well as a number of minor fixes.
Take a look at the What’s New page for a list of new features and improvements that are available in this release.
Upgrading to Autonomous Operator 2.5
The necessary steps needed to upgrade to this release depend on which version of the Autonomous Operator you are upgrading from.
Upgrading from 1.x, 2.0, 2.1
There is no direct upgrade path from versions prior to 2.2.0. To upgrade from a 1.x, 2.0.x, or 2.1.x release, you must first upgrade to 2.4.x, paying particular attention to supported Kubernetes platforms and Couchbase Server versions. Refer to the Operator 2.4 upgrade steps if upgrading from a pre-2.2 release.
Upgrading from 2.2, 2.3, and 2.4
There are no additional upgrade steps when upgrading from these versions, and you may follow the standard upgrade process. However, due to K8S-3097, all users will encounter a mandatory upgrade cycle when upgrading to this release, to expose the missing Indexer HTTPS Port (see Detailed Port Description for network port requirements).
|
An upgrade cycle is a relatively heavyweight operation that requires all pods in the cluster to be replaced, and data transferred between the old and new pods. The time taken to perform this operation is dependent on network bandwidth, disk IO and the amount of data resident in the database. For large, production databases, ensure an adequate maintenance window is scheduled as to minimize any disruption to clients and other business critical functions. For further information read the Couchbase Upgrade concepts page. |
Release 2.5.0
Couchbase Autonomous Operator 2.5.0 was released in August 2023.
New Features and Behavioral Changes
Feature Parity with Couchbase Server
The Operator now allows Data Service (memcached) AuxIO and NonIO Threads to be configured.
The CouchbaseBackup resource now has a Default Recovery Method which specifies how cbbackupmgr should recover from broken Backup/Restore attempts.
Pod Management
The Operator now parallelizes pod creation, for example during cluster creation and when performing upgrades, saving overall wall-clock time.
The Operator now adds specific labels to the PodDisruptionBudget for Cluster Member Pods, to make sure that only Cluster Members are included in the count used during a disruption. Similarly, the internal pod cache behaviour has been improved to only cache Cluster Member pods.
Pod and Container Security Contexts
From Operator 2.5, couchbaseclusters.spec.securityContext has been deprecated in favour of couchbaseclusters.spec.security.podSecurityContext and couchbaseclusters.spec.security.securityContext, to define privilege and access control settings for Pods or Containers.
Fixed Issues
| Issue | Description |
|---|---|
Summary: Previously the Operator was not correctly ignoring/discarding existing XDCR Replications when Managed XDCR was enabled on already-managed Couchbase Cluster. |
|
Summary: Previously the Operator would crash if a Backup resource was added with missing schedules. |
|
Summary: Couchbase Server allows |
|
Summary: Previously the Operator was logging excessive node-related 'Reconcile completed' messages at |
|
Summary: Previously the Operator was logging excessive RBAC-related 'Reconcile completed' messages at |
|
Summary: Previously the Indexer HTTPS Port (19102) was not being exposed by either the Couchbase Server Pod or the service. |
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.