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

Introduction

      +

      The Couchbase Autonomous Operator provides native integration of Couchbase Server with open source Kubernetes and Red Hat OpenShift. It enables you to automate the management of common Couchbase tasks such as the configuration, creation, scaling, and recovery of Couchbase clusters. By reducing the complexity of running a Couchbase cluster, it lets you focus on the desired configuration and not worry about the details of manual deployment and life-cycle management.

      What Does it Support?

      The Operator can deploy and manage:

      • Couchbase Server Enterprise Edition

      The Operator is certified on the following platforms:

      For more information on supported platforms and versions see the system requirements documentation.

      How Does it Work?

      The Operator extends Kubernetes by defining types that represent Couchbase clusters and resources. These types are declarative; they define what the cluster should look like. The Operator monitors Kubernetes for Couchbase resources, creating or updating Couchbase clusters to match the declarative specification.

      For more information on what the Operator does, its behavior and its architecture see the Operator architecture concepts documentation.

      What Features Does it Provide?

      The goal of the Operator is to fully manage one or more Couchbase deployments so that you don’t need to worry about the operational complexities of running Couchbase. The following is a list of the management tasks that are currently supported:

      Essential Reading

      Kubernetes and the Operator are complex systems — you shouldn’t go in unprepared. The following is a selection of documentation that should be read and understood fully before continuing:

      Getting Started

      Once you have read the essential guides, you are ready to install the Operator and create your first Couchbase cluster.

      Finding Your Way Around

      The documentation is organized into easy to navigate sections that are targeted to specific users. The sections are defined as follows:

      Getting Started

      Important platform information and best practice guidelines must be read before proceeding. This section is also the home of quick-start installation guides.

      Learn

      High level architectural documentation and feature descriptions. This section should be read if you wish to correctly plan and size your Couchbase clusters before deployment.

      Manage

      Simple how-to guides. This section documents how to configure your Couchbase cluster resources with simple copy and paste style tutorials.

      Reference

      Detailed resource and component guides. This section details low-level functionality of all the resources and fields exposed to the user, their formats and constraints. Individual Operator containers and tools are fully documented with detailed command line argument manuals.

      Tutorials

      How to integrate with and configure 3rd party components. The Operator itself can provision and manage simple clusters for most use cases. In more complex situations that involve complex networking or interaction with other, external services, we need to provide guidance on how to integrate. These tutorial are provided as-is and may become inaccurate as 3rd party dependencies evolve.

      Conventions

      Resource Names

      Kubernetes resources names, such as Service or CouchbaseCluster, will be rendered verbatim. These are distinguished by the use of bumpy-capitals, or camel-case, with an upper case first character. These are the names of resources when specified as kind in a resource’s YAML definition.

      Attribute Paths

      Resources contain attributes, such as spec.security.authSecret will be rendered verbatim. These are distinguished by the use of bumpy-capitals, or camel-case, with a lower case first character. Paths are based on the JSON path specification, and consecutive elements are separated by periods (.).

      Where attribute paths are used in the documentation, they have been prefixed with the resource name, and can be used directly with kubectl explain to access online documentation.

      Further Reading