Release Notes for Couchbase Autonomous Operator 2.7
Autonomous Operator 2.7 release provides full support for Couchbase Server 7.6, and several improvements to Pod Scheduling and Networking, 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.7
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, or 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, 2.4, 2.5, or 2.6
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 from a release older than 2.5.0, to versions 2.5.0, 2.5.1, or 2.6.0 through 2.6.3, to expose the missing Indexer HTTPS Port (see Detailed Port Description for network port requirements). This behavior has changed in versions 2.5.2, 2.6.4, and 2.7.0, and there is no mandatory upgrade cycle — the missing port is added the next time there is a regular maintenance activity that involves Pod creation.
|
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.7.0
Couchbase Autonomous Operator 2.7.0 was released in August 2024.
Changes in Behaviour
Delta Recovery / In-Place Upgrades
The DeltaRecovery upgrade strategy added in Operator 2.6 has been replaced by InPlaceUpgrade, to better reflect the actual behaviour (not every Service can be Delta Recovered), and DeltaRecovery is now deprecated.
Storage Backend Migration
In Server 7.6 it is now possible to migrate between the Couchstore and Magma storage backends, as described in Migrate a Bucket’s Storage Backend. Operator will automatically start the required Rebalances if it detects an unresolved Storage backend change. Storage Backend can also be configured using annotations, see Bucket Backend Configuration for more details.
Query Service Settings
Over time, a significant gap had appeared between the Query Service settings available in Couchbase Server, and the ones exposed via the CouchbaseCluster CRD in Autonomous Operator.
This has been addressed in CAO 2.7.0, and the following cluster-wide settings are now available:
-
Server 6.5+:
queryPipelineBatch,queryPipelineCap,queryScanCap,queryTimeout,queryPreparedLimit,queryCompletedLimit,queryCompletedThreshold,queryLogLevel,queryMaxParallelism. -
Server 7.0+:
queryTxTimeout,queryMemoryQuota,queryUseCBO,queryCleanupClientAttempts,queryCleanupLostAttempts,queryCleanupWindow,queryNumAtrs. -
Server 7.6+:
queryNodeQuota,queryUseReplica,queryNodeQuotaValPercent,queryNumCpus,queryCompletedMaxPlanSize.
Note that queryNodeQuota is being exposed via the existing spec.cluster.queryServiceMemoryQuota.
For Server versions prior to 7.6, this value is used to determine Pod resource requirements, and from version 7.6 onwards will also be used to set queryNodeQuota on the Couchbase Server cluster (see K8S-3436).
Note that queryNumCpus requires a restart of the Query Service to take effect.
In practice in a Kubernetes environment, this means that this will only affect Pods started after the setting has been updated.
|
Prior to Operator 2.7.0, the above Query Service settings could still be set directly on the cluster. To avoid these being reset to default values during the CAO upgrade, any of the above settings that have been changed must be added to the Specifically, this needs to be done after updating the CRDs, and before installing the new Operator For further information see Update Existing Resources. |
Audit Log Pruning
With the addition of native pruning of rotated Audit Logs in Server 7.6, the garbageCollection sidecar is now deprecated.
Miscellaneous Changes
-
cao collect logsnow has improved handling of larger clusters (K8S-3322). -
couchbaseclusters.spec.networking.exposedFeaturesnow includesbackupas an option, allowing external access for thecbbackupmgrtool (K8S-3508). -
Any options specified at
couchbaseclusters.spec.security.securityContextare now also applied to the Operator Backup container (K8S-3417). -
It is possible to set a longer Termination Grace Period on the Cloud Native Gateway container with
terminationGracePeriodSeconds(K8S-3257). -
A number of new metrics have been added, see Prometheus Metrics Reference for details.
Fixed Issues
| Issue | Description |
|---|---|
Summary: Previously the |
|
Summary: Previously the Operator was not correctly deleting un-managed XDCR Remote Cluster References. |
|
Summary: Previously the Operator was triggering a mandatory upgrade cycle when upgrading from 2.4.x or earlier. |
|
Summary: Previously the |
Known Issues
| Issue | Description |
|---|---|
Summary: It is not currently possible to set |
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.