Please use the form below to provide your feedback. Because your feedback is valuable to us, the information you submit in this form is recorded in our issue tracking system (JIRA), which is publicly available. You can track the status of your feedback using the ticket number displayed in the dialog once you submit the form.

A newer version of this documentation is available.

View Latest

Release Notes for Couchbase Autonomous Operator 1.1

    +

    Couchbase Autonomous Operator 1.1 introduces a number of supportability features and enhancements.

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

    Release 1.1.0

    Couchbase Autonomous Operator 1.1.0 was released in November 2018.

    Installation and Upgrade

    For installation instructions, see Installing on Kubernetes and Installing on OpenShift.

    For upgrade instructions, see Upgrading the Operator.

    Platform Support

    For the latest platform support information, see Prerequisites.

    Major Behavior Changes

    • Production clusters may now be deployed as combination of Production Stateful and Production Stateless node deployments, depending on the services running on the individual server class configurations. The default and logs mounts in the CouchbaseCluster configuration are mutually exclusive — if any server class is detected by the cluster validation to be supportable (e.g. default or logs is specified under volumeMounts), then all other server classes must also have supportable configurations in order for the validation check to pass.

      Review the best practices for more information about cluster supportability requirements.

    • Logs collected with cbopinfo are automatically redacted of sensitive information by default.

    Fixed Issues

    Table 1. Issues Fixed in Version 1.1.0
    Issue Description

    K8S-504

    Summary: Pod volumes are deleted when pods are deleted. As a result, important debugging information may not be available after a failure.

    K8S-538

    Summary: cbopinfo does not redact potentially sensitive information from all logs.

    K8S-493

    Summary: It’s not possible to attach a persistent volume to the Couchbase logs directory for deployments when Couchbase data is not written to a persistent volume. This means that important debugging information may be unavailable during failure situations.

    Workaround: You should always deploy Couchbase clusters in production with persistent volumes.

    K8S-531

    Summary: When the same event occurs on different Couchbase nodes, the event order is not reported consistently. This may affect applications that rely on the event order to be consistent when checking the status of a Couchbase cluster.

    K8S-537

    Summary: In rare cases, Kubernetes can drop events that are logged by the Operator.

    Known Issues and Limitations

    Table 2. Known Issues and Limitations
    Issue Description

    General

    Upgrading Couchbase Server using the Operator is not currently supported.

    General

    Couchbase client access is only supported locally within the Kubernetes cluster or where cluster DNS can be accessed by, or replicated to, a remote network.

    For more information, see About Kubernetes Networking and Couchbase.

    General

    The Operator manages the state of the Couchbase Server cluster. Therefore, at this time, all cluster configuration changes must be made by modifying the CouchbaseCluster configuration file and pushing it to Kubernetes. Any manual changes to the configuration that are made using the Couchbase Server Web Console, CLI, REST API, or SDK will be reverted by the Operator. This includes things like adding a node or creating a server group.

    The one exception is when disableBucketManagement is set to true in the CouchbaseCluster configuration (the default is false). If this is the case, the creation and deletion of Couchbase buckets must be done manually. Refer to the CouchbaseCluster documentation for more

    K8S-702

    Summary: When multiple Couchbase clusters are running in the same namespace, the log volume janitor process can behave improperly. The behavior can manifest in the following ways:

    • The janitor process for one Couchbase cluster (that has, for example, a 1-day retention period) may delete the log volumes of another Couchbase cluster (that has, for example, a 7-day retention period).

    • The janitor process may select volumes that don’t belong to the Operator. Nothing is deleted, but the janitor process will error continuously. This effectively stops the janitor process from working and fills the logs with errors that are similar to the following:

      time="2018-12-14T09:41:53Z" level=error msg="janitor error:path annotation missing for pvc some-other-information-volume" cluster-name=cb-example module=cluster

    These issues can only occur when multiple Couchbase clusters in the same namespace are using persistent log volumes.

    K8S-640

    Summary: The node disk storage statistic that is displayed in the Couchbase Server Web Console may appear to be inaccurate when using persistent volumes. This is because the calculation that formulates this statistic does not properly support persistent volumes.

    K8S-622

    Summary: Clusters without persistent volumes require manual failover when nodes are down and auto-failover cannot be performed. In the event that the Operator also crashes before nodes have been failed over, the Operator will require manual failover of down nodes before proceeding to reconcile any changes made to the cluster.

    K8S-556

    Summary: Only dynamic volume provisioning via storage classes is supported.

    K8S-421

    Summary: If a cluster is scaling up when not enough nodes are present, the Operator will not rebalance the cluster even if some nodes can be added.

    Workaround: You should ensure that sufficient resources are present in the Kubernetes cluster before scaling a Couchbase cluster.

    K8S-389

    Summary: Kubernetes doesn’t allow the setting of ulimit parameters on individual containers.

    Workaround: You can set ulimits on the physical machine that Kubernetes is running on; the ulimit parameters will be inherited by the containers.

    K8S-89

    Summary: If you manually increase the number of replicas of a bucket, then the Operator may rebalance the cluster before reverting the bucket’s changes.

    Workaround: You should always change the CouchbaseCluster configuration through the Operator. If you change the CouchbaseCluster configuration directly on the cluster (such as through the Couchbase Server Web Console), then the Operator will revert those changes.

    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.

    More Information