A newer version of this documentation is available.

View Latest

Release Notes for Couchbase Autonomous Operator 2.4

      +

      Couchbase Autonomous Operator 2.4 release is primarily focused on adding some key features introduced in Couchbase Server 7.1 to Autonomous Operator such as support for ARM platforms and Encrypted Certificates, as well as other improvements related to TLS Certificate Management, cloud backups, index configuration, and the Prometheus Exporter

      Take a look at the What’s New page for a list of new features and improvements that are available in this release.

      Installation

      Upgrading to Autonomous Operator 2.4

      The necessary steps needed to upgrade to this release depend on which version of the Autonomous Operator you are upgrading from.

      • Version 1.x.x

        • 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.

      • Version 2.0.x

      • Version 2.1.x

        • There are no additional upgrade steps or considerations when upgrading from this version. You may follow standard upgrade process.

      • Version 2.2.x

        • There are no additional upgrade steps or considerations when upgrading from this version. You may follow standard upgrade process.

      • Version 2.3.x

        • There are no additional upgrade steps or considerations when upgrading from this version. You may follow standard upgrade process.

      Upgrading from Version 2.0.x

      First, ensure that you are running compatible versions of Kubernetes and Couchbase Server before upgrading.

      TLS Requirements

      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.

      Mandatory Couchbase Upgrade Cycle

      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.

      Upgrading from 2.0, 2.1, 2.2, and 2.3

      Mandatory Couchbase Upgrade Cycle

      Some users will encounter a mandatory upgrade cycle when upgrading to this release.

      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.

      TLS Users

      In prior versions, Couchbase Server pod readiness checks were done over plain text port 8091. With the introduction of strict mode TLS in this release, port 8091 can be disabled to inhibit all non TLS ports. The Operator has been updated to use port 18091 — Couchbase Server’s TLS admin port — when TLS management is enabled.

      Server Groups Users

      A pod upgrade is also required for users of the server groups feature.

      When the Operator was first released, the only available Node label that was available across all platforms to allow explicit pod scheduling was failure-domain.beta.kubernetes.io/zone. This label has been deprecated since Kubernetes 1.17, in favor of topology.kubernetes.io/zone.

      To ensure correct operation of the Operator in the future, the decision has been taken to start using the new label as of Operator 2.3. This ensures that the Operator is compatible with all future Kubernetes releases in the event of the deprecated label being removed.

      Logging Users

      To control memory usage, memory buffer limits have been implemented for the logging sidecar. This change will affect all users of logging, and will require a cluster upgrade.

      Additionally a bug in the audit clean up script caused old logs to be deleted only if their age matched the specified time period exactly. This has been fixed so that logs older than or equal to the time period are cleaned.

      Release 2.4.3

      Couchbase Autonomous Operator 2.4.3 was released in January 2024.

      New Features and Behavioral Changes

      Support for New Kubernetes Platforms

      Autonomous Operator 2.4.3 adds support for Kubernetes versions 1.26, 1.27 and 1.28.

      Fixed Issues

      Issue Description

      Summary: Previously the Operator identified the eventing_admin role as a Bucket role and not a Cluster role.

      Summary: Previously the Operator would log a large JSON structure to the logs when it failed to create a Pod.

      Summary: Previously the Operator would continually update Magma Bucket settings if History Retention Annotations were missing.

      Summary: Previously the Operator would get stuck in a reconciliation loop when failing to compare two unsorted arrays.

      Summary: Previously the Operator was not including Cluster details in a number of log messages.

      Summary: Previously the Operator was logging excessive node-related 'Reconcile completed' messages at info rather than debug.

      Summary: Previously the Operator certification suite was failing on auto-scaling related tests due to a removed API.

      Summary: Previously the Operator would crash if a Backup resource was added with missing schedules.

      Summary: Previously the Operator was not correctly ignoring/discarding existing XDCR Cluster References when Managed XDCR was enabled on an already-managed Couchbase Cluster.

      Release 2.4.2

      Couchbase Autonomous Operator 2.4.2 was released in June 2023.

      New Features and Behavioral Changes

      Support for New Features in Couchbase Server 7.2.0

      With the addition of the Change History feature in Couchbase Server 7.2.0, Collections can now be modified (to enable/disable History Retention).

      Operator 2.4.2 now allows Collection objects to be mutated.

      ARM Platform Support

      Operator 2.4.0 added support for deploying on ARM platforms where available on AWS, Azure, and GCP managed Kubernetes services, as well as on open source Kubernetes distributions.

      With Operator 2.4.2 this now includes deploying on OpenShift on ARM platforms.

      Fixed Issues

      Issue Description

      Summary: Fixed issue where TestUpgradeSupportableKillStatefulPodOnCreate results were inconsistent.

      Summary: Fixed issue where TestPersistentVolumeRzaNodesKilledUnbalanced results were inconsistent.

      Summary: Fixed issues where TestMandatoryMutualTLSRotateCAExpiring results were inconsistent.

      Known Issues

      Issue Description

      Summary: TestClusterUpdateUsingRest and TestTLSScriptCreateRestRotate may cause "schema overflowed" messages.

      This may cause issues while attempting the Self-Certification process.

      Release 2.4.1

      Couchbase Autonomous Operator 2.4.1 was released in May 2023.

      New Features and Behavioral Changes

      Support for New Features in Couchbase Server 7.2.0

      Per Collection Change-History. Maintain a change history for all collections in a bucket. Changes to documents in collections are included in the change history for the bucket. A maximum size for the change history can be specified in bytes or seconds. See Change History.

      You can now configure block size for Magma storage when you create a bucket. See Creating and Editing Buckets.

      Local Persistent Volumes

      The ability to use a local storage device (such as a disk, partition, or directory) as a Persistent Volume when deploying Couchbase Server resources.

      Fixed Issues

      Issue Description

      Summary: Previously the Operator was not able to rotate an expired, self-signed Admission Controller certificate on the Mutating/Validating Webhook.

      Summary: Fixed extraneous Rebalance messages under certain Couchbase Server upgrade conditions.

      Summary: Check for existence of old persistence secret before creating a new one, and avoid reusing an existing one.

      Summary: Fixed issue where URL Encoding breaks string lists with cipherSuites.

      Summary: Fixed issue where storageBackend warnings occur after Operator upgrade.

      Known Issues

      Issue Description

      Summary: TestUpgradeSupportableKillStatefulPodOnCreate results are inconsistent.

      This may cause issues while attempting the Self-Certification process.

      Summary: TestPersistentVolumeRzaNodesKilledUnbalanced results are inconsistent.

      This may cause issues while attempting the Self-Certification process.

      Summary: TestMandatoryMutualTLSRotateCAExpiring results are inconsistent.

      This may cause issues while attempting the Self-Certification process.

      Summary: cao certify is not supported on Openshift ARM clusters.

      Full support for OpenShift on ARM will be available in a future release.

      Summary: autoFailoverMaxCount defaults to 3, which is inconsistent with the Couchbase Server default of 1.

      The workaround is to set the appropriate value for the cluster.

      Summary: It is not yet possible to mutate an existing Collection using the Operator.

      See the linked issue for details of a workaround.

      Release 2.4.0

      Couchbase Autonomous Operator 2.4.0 was released in January 2023.

      New Features and Behavioral Changes

      ARM Platform Support

      The Couchbase Autonomous Operator, and all related container images, can now be deployed on ARM platforms where available on AWS, Azure, and GCP managed Kubernetes services, as well as on open source Kubernetes distributions. Support for OpenShift on ARM will be available in a future release.

      TLS Certificate Management

      • Added support for Encrypted Private Keys

      • LDAP Server configuration can now make use of the main Root CA’s array

      • Allow multi-PEM CAs in the Server secretSource

      • Allow insecure reload of expired certificates as a last resort

      • Raise events on TLS expiration

      Fixed Issues

      Issue Description

      Summary: Previously the Operator did not correctly propagate the changes when the client certificates were updated.

      Summary: Previously the CRD was not correctly inheriting the entirety of v1.PodSpec, meaning that attributes such as affinity were not available.

      Known Issues

      Issue Description

      Summary: URL Encoding breaks string lists with cipherSuites.

      The following fails with "Invalid format. Expecting a list of ciphers.":

        tls:
          cipherSuites:
          - TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
          - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
          - TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
          - TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
          tlsMinimumVersion: TLS1.2

      As a workaround, escape the ciphers with quotation marks as shown below (the single quotes allow the double quotes to be passed through for further parsing):

        tls:
            cipherSuites:
            - '"TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256"'
            - '"TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256"'
            - '"TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384"'
            - '"TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384"'
            tlsMinimumVersion: TLS1.2

      Summary: storageBackend warnings occur after Operator upgrade

      By default before Operator 2.4.0, Bucket resources do not have storageBackend set. When Upgrading to 2.4 the Operator will send warnings if server is also < 7.1.0:

      {"level":"info","ts":1674524426.697536,"logger":"cluster","msg":"[WARN] spec.storageBackend cannot be empty for server version below 7.1.0 - default to couchstore"}

      Under normal upgrade scenarios the workaround for this is to:

      • Edit couchbaseBucket with storageBackend = couchstore

      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.