How to Use the Database Operator Beta

DigitalOcean Kubernetes (DOKS) is a managed Kubernetes service that lets you deploy Kubernetes clusters without the complexities of handling the control plane and containerized infrastructure. Clusters are compatible with standard Kubernetes toolchains, integrate natively with DigitalOcean Load Balancers and volumes, and can be managed programmatically using the API and command line. For critical workloads, add the high-availability control plane to increase uptime with 99.95% SLA.

When creating a new Kubernetes cluster on DigitalOcean, you can now facilitate its integration with managed databases by adding a database operator, now available in beta. The database operator allows you to automatically link new databases to your Kubernetes cluster and manage them.

For detailed information on using the operator during its beta, see our up-to-date documentation on GitHub.

Learn the CRDs

Once you add the database operator to your Kubernetes cluster, it runs in the DigitalOcean Kubernetes control plane. So, you cannot see the operator’s deployment or configuration, only the installation of the following CRDs:

• The DatabaseCluster CRD, which allows you to manage the database cluster.
• The DatabaseClusterReference CRD, which allows you to connect to an existing database.
• The DatabaseUser CRD, which allows you to manage the database’s users.
• The DatabaseUserReference CRD, which allows you to get credentials for an existing user.

Choose an Architecture

To interface with the database operator, you must choose an architecture. This architecture defines the operator configuration that best suits your use case. We recommend one of the following:

• Managed Database Architecture, which manages your database automatically, but expects that your database be exclusively used by one Kubernetes cluster and that the data’s lifecycle matches the cluster’s – for example, with a Redis cache.

• Referenced Database Architecture, which allows for the database to interface with many Kubernetes clusters and ensures the posterity of the database, but requires separate management for the database, such as via Terraform.

Managed Database Architecture

The Managed Database Architecture is the more convenient architecture for specific use cases, such as caching. It has the following properties:

• The operator manages your database automatically.
• Your associated database can only be used by one Kubernetes cluster, limiting scalability.
• Deleting the Kubernetes cluster also deletes the database.

To best visualize the connection between your Kubernetes cluster and the database operator with this architecture, reference the following diagram while reading our beta documentation.

Referenced Database Architecture

The Referenced Database Architecture is our recommended architecture for the widest variety of use cases. It has the following properties:

• You must manage your database separately, such as via Terraform.
• Your associated database can be used by several different Kubernetes clusters, ensuring scalability.
• Deleting the Kubernetes cluster does not delete the database, ensuring the data’s posterity.

To best visualize the connection between your Kubernetes cluster and the database operator with this architecture, reference the following diagram while reading our beta documentation.