In my last post about Couchbase, I covered how to run Couchbase on Oracle Cloud Infrastructure with Terraform. That’s all well and good, but now for something completely different…
At KubeCon + CloudNativeCon 2018, Oracle made lots of announcements, many about the Oracle Cloud Native Framework. This framework builds on earlier work we’ve done, joining the Cloud Native Computing Foundation (CNCF) as a Platinum member and releasing a managed Kubernetes service called Oracle Cloud Infrastructure Container Engine for Kubernetes (OKE).
Conventional wisdom is that Kubernetes is great for running stateless containers but not stateful workloads. Recommended architectures have application servers managed by Kubernetes with databases running outside on VMs or bare metal. This approach performs well, but it negates one of the biggest advantages of Kubernetes—providing a single orchestrator that can be used to manage an entire application. The result is that you must manage software both inside and outside of Kubernetes along with the connections between the two. It’s not fun.
The Kubernetes community recognized all this as a limitation and tried a number of approaches for running stateful workloads. The first was called Pet Sets, drawing on the pets/cattle analogy common in the cloud. This was later renamed to StatefulSets. That model was superseded by an approach called Sidecar, which suffered from a variety of issues, including single point of failure. All that culminated in CoreOS proposing a model called Operator, which uses a custom resource definition (CRD) to manage a stateful application inside a Kubernetes cluster.
A variety of stateful pieces of software now run with the Operator model, including Confluent, Hazelcast, and Couchbase. If you’re looking for an industry-leading NoSQL database on which to build your Kubernetes application, Couchbase is an obvious choice. Couchbase itself is a great product, with all the features you’d expect in a NoSQL database. Couchbase Autonomous Operator distinguishes it a bit further.
We’ve partnered closely with Couchbase to make it easy to deploy Operator on Container Engine for Kubernetes:
 |
“Couchbase is collaborating with Oracle to bring the benefits of the Oracle Kubernetes Engine (OKE) to applications like the Couchbase Data Platform. With Couchbase Autonomous Operator now users can easily deploy Couchbase Data Platform on OKE.” Anil Kumar, Director of Product Management, Couchbase |
Operator enables you to run your database next to the application in Kubernetes, lowering latency and simplifying administration of the application as a whole. Operator also blurs the line between enterprise software and a managed service, automating many tasks, including:
- Resizing the cluster
- Recovering from node failure
- Upgrading the database version
Because Operator relies on the CRD API, it can run on any conformant Kubernetes distribution, including, of course, Container Engine for Kubernetes. Getting started with Couchbase Autonomous Operator on Container Engine for Kubernetes takes just a few steps.
First you deploy a Container Engine for Kubernetes cluster. Instructions to do that, along with a Terraform module that automates the process, are on GitHub.
With your cluster up and running, the next step is to deploy Couchbase. We’ve created a walkthrough for that.
As always, it’s been a pleasure working with the Couchbase team to set this up. Special thanks to Tommie McAfee at Couchbase for helping with some permissions issues! If you have any questions, reach out to me at ben.lackey@oracle.com or on Twitter @benofben.