Couchbase Autonomous Operator 2.2 is a significant release that adds new features to the Autonomous Operator 2.0 series. The changes in this release enable several advancements in how you can manage, monitor, and deploy Couchbase clusters.
Take a look at the release notes for a more detailed and complete list of changes in this release, including known and fixed issues.
The Autonomous Operator now supports Couchbase cluster auto-scaling for all Couchbase services. This means that Couchbase cluster server class configurations containing stateful services like Data and Index can now be configured to automatically scale in response to observed metrics. (Previously, only stateless deployments of the Query Service were supported.)
The Autonomous Operator provides the necessary facilities for Couchbase clusters to be automatically scaled based on usage metrics. This capability is provided through an integration with the Kubernetes Horizontal Pod Autoscaler (HPA). Thresholds can be set for native Kubernetes metrics (such as pod CPU utilization) as well as Couchbase metrics (such as bucket memory utilization) that, once exceeded, trigger horizontal scaling of individual server classes. Auto-scaling doesn’t incur any cluster downtime, and allows for each Couchbase Service to be scaled independently based on different metrics.
To help users get started in production, an auto-scaling best practices guide has been provided. This guide discusses relevant metrics for scaling individual Couchbase Services, and includes recommended settings based on internal benchmark testing performed by Couchbase.
For more information, refer to Couchbase Cluster Auto-scaling.
The Autonomous Operator now supports log forwarding through the optional deployment of a third party log processor that can read Couchbase log files and forward them to standard console output and other configurable destinations. This feature is powered by a Couchbase-supplied log processor image (based on Fluent Bit) which has also been made available as an open source project on Github.
The Autonomous Operator now optionally allows for the expansion of persistent volumes that are already in use by Couchbase clusters, thus removing the need for a rolling upgrade of cluster pods.
For additional information and requirements, refer to Online Volume Expansion.
With the release of Autonomous Operator 2.2, the
operator-backup container image has been enhanced to support a wider range of Couchbase Server and Autonomous Operator versions.
As part of this update, the
operator-backup image has switched to semantic versioning which is no longer based on Couchbase Server version.
While not a replacement for a properly implemented monitoring solution, it may be beneficial to have your backup storage grow with your requirements. To this end, the Autonomous Operator now supports online resizing of backup volumes.
In addition to supporting manual resizing, the Autonomous Operator can also automatically resize backup volumes while also keeping backups to the minimum size necessary to operate, thus reducing cost while also supporting future expansion. Note that in order to use these resize capabilities, the underlying StorageClass associated with the backup volume must be configured to allow volume expansion.
By default, backup and restore operations execute with only a single thread of execution, which can sometimes lead to poor performance.
To mitigate thread-related performance issues,
couchbasebackuprestores.spec.threads can now be specified to configure the number of concurrent
cbbackupmgr clients to use when backing up or restoring data.
This release also introduces filters that allow you to control exactly what is restored from a backup. In previous releases, restore operations were fairly inflexible in that the only option was to restore all data from a backup. Now you can choose to include or exclude specific buckets, restore data for a particular service, and even restore to a different bucket name when restoring documents.
Refer to Additional Restore Options for more information.
The latest version of the Couchbase Prometheus Exporter allows for certain customizations to exported metrics. The following customizations are currently supported:
Change the namespace, subsystem, name, and help text for each metric.
Enable and disable whether a metric is exported to Prometheus.
For more information, refer to Customizing Metrics.
Prior to version 2.2, the Autonomous Operator allowed two types of upgrade — a one pod at a time rolling upgrade, and a whole cluster upgrade.
This release adds the
couchbaseclusters.spec.rollingUpgrade parameter, which allows rolling upgrades to be extended to upgrade either a fixed number of pods, or a percentage of the cluster size.
Refer to Couchbase Upgrades for more information.
The Autonomous Operator now provides the ability to automatically manage pod CPU and memory resource requests with the
When in use, pods will have their resource requests automatically populated depending on the services enabled on that pod, and the individual Couchbase service quotas.
The Couchbase Server default minimum TLS version is 1.0.
This is insecure and easily compromised if a client downgrades to a version less than 1.2.
Autonomous Operator 2.2 makes TLS 1.2 the minimum by default, and will automatically update the TLS minimum version unless it is explicitly specified with the
You can prevent this change from occurring when upgrading the Operator on existing clusters by setting
TLS1.0 after upgrading the CRDs, and before restarting the Operator.
Couchbase Server requires that the TLS resources be called
chain.pem, however the majority of 3rd-party certificate managers generate
This format is governed by the Kubernetes
kubernetes.io/tls secret type.
To provide integration with 3rd-party providers, and to maintain backward compatibility with existing clusters, the Operator now provides secret shadowing.
A new TLS source —
couchbaseclusters.spec.networking.tls.secretSource — allows you to use
kubernetes.io/tls type secrets to configure Couchbase Server.
When using this new TLS source, a shadow copy of the TLS secret is created, with the key names changed to those hard coded in Couchbase Server.
The shadow secret can then be mounted and used inside Couchbase Server pods.
As the secret is shadowed, the Operator can reformat private keys, and therefore now supports PKCS#8 formatted private keys.
3rd-party certificate managers can be used with clusters that are configured with this new TLS source. Refer to the tutorial Using a Certificate Manager for an example.
For existing clusters using the legacy
couchbaseclusters.spec.networking.tls.static source, the Autonomous Operator works as before — directly mounting and consuming the TLS secret without a shadow secret.