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:
-
Amazon EKS
-
Google GKE
-
Microsoft AKS
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:
-
Cluster life-cycle
-
Cluster auto-recovery
-
Cluster configuration
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:
-
Best practices - understand the best way to deploy Couchbase clusters
-
System requirements - understand supported platforms, software and resource requirements
-
Public cloud prerequisites - understand how to prepare public clouds to run the Operator
-
Custom resource label selection - understand how Couchbase cluster specifications are built
-
Network architectures - understand how to correctly configure networking for the best experience
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
orCouchbaseCluster
, 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 askind
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.