Cormac Hogan is a Director and Chief Technologist in the Office of the CTO in the Storage and Availability Business Unit (SABU) at VMware. 

Bio: I joined VMware back in April 2005, and have previously held roles in VMware’s Engineering, Technical Marketing and Technical Support organizations. I have written a number of storage related white papers and have given numerous presentations on storage best practices and vSphere storage features. I am also the co-author of the “Essential Virtual SAN” and “vSAN 6.7 Deep Dive” books.

A first look at the Couchbase Autonomous Operator

A few weeks back, I took a look at Heptio Velero, formely known as Ark. Velero provides backup and restore capabilities for cloud native applications. During that research, I used a Couchbase database as my application of choice for backup/restore. After speaking to Couchbase team regarding that blog post, they strongly recommended I try the new Couchbase Autonomous Operator rather than the StatefulSet method that I was using for the application. Couchbase talk about the advantages of the operator approach over StatefulSets here.

Now, while Couchbase provide steps on how to deploy Couchbase with their operator, they create it in the default K8s namespace. In my test, I want to put Couchbase in its own namespace. The steps provided here are provided to get you started with the new Couchbase Operator, running on vSphere and vSAN infrastructure, in its own Kubernetes namespace. I also talk about some issues with the bundled load generating tool, called pillowfight.

Couchbase provide prescriptive instructions on how to get started with their operator here. It includes all the necessary configuration files. A few things about the operator:

  • When loaded, it downloads the Operator Docker image as specified in the operator.yaml file. It uses a deployment construct so that it can restart if the pod it is running in dies.
  • It creates the CouchbaseCluster custom resource definition (CRD)
  • It starts listening for CouchbaseCluster events.

I made a few modifications to allow Couchbase to run in its own namespace:

  • I first of all created a new namespace (obviously) called couchbase.
  • When the cluster role was created, I created the service account in the new couchbase namespace and I then assigned the cluster role to that service account using a cluster role binding.
  • I modified the operator.yaml file to include a metadata.namespace=couchbase setting so that it applies to the couchbase namespace

By monitoring the logs of the couchbase operator pod, we can observe the following startup messages:

I was now ready to deploy the Couchbase cluster using the new cbopctl CLI tool. I also needed to make a few changes to the default cluster configuration file (couchbase-cluster-sc.yaml).
  • I placed it in the couchbase namespace with the  metadata.namespace entry
  • I set spec.disableBucketManagement to true which allows me to make changes to buckets via UI/CLI (otherwise I have to make all changes via edits to the YAML file)
  • I added Persistent Volumes for the default and data mounts (I had to create a new StorageClass for the volumeClaimTemplate to use for this – see below)
 Here is the full CouchbaseCluster YAML file with my changes highlighted.

I am skipping over the authentication and user requirements which are all documented on the Couchbase site. However, once the application has been deployed, you should be able to see the following in the couchbase operator pod logs:

And if everything comes up successfully, you can query the pods, persistent volumes and services as they initialize.

So, to recap, the steps are:
  1. Follow the documented steps to set up the couchbase ClusterRole
  2. Create the couchbase namespace – kubectl create ns couchbase
  3. Create the couchbase operator service account in the couchbase namespace – kubectl create serviceaccount couchbase-operator –namespace couchbase
  4. Create the operator (modified for the couchbase namespace) – kubectl create -f operator.yaml
  5. Create the necessary secrets (modified for the couchbase namespac) – kubectl create -f secret.yaml
  6. Create the couchbase cluster using cbopctl – cbopctl create -f couchbase-cluster-sc.yaml
In the last output, the services, we have the port mappings for the Couchbase UI, both for http and https. If we connect to any of the K8s slave nodes with those ports, we should be able to access our Couchbase deployment, using the Administrator/password credential provided in our configuration.
Initially there are no buckets created. There is one defined in the cluster configuration but we overrode it with the advanced setting. We can quickly remedy that by creating a few temp ones. I will add two – the first is called default and the second is called cormac. At the moment there are no items in either bucket.
Couchbase also bundle a utility called pillowfight which is a very useful way of populating the buckets. For some reason, I had some issues with the bundled “sequioatools” version of pillowfight. Once I reverted to using the “couchbaseutils” version, all was good. You will need to set up the appropriated user credentials to do this, but once again this is all documented on the main Couchbase operator site. Here are my sample YAML files for populating the default bucket:

The only difference for the cormac bucket is the command syntax is slightly different:

More importantly, if we take a look at the Couchbase UI, we see that we now have 1,000 items in each bucket:

 

And that’s it. You are up and running with your Couchbase operator. And to close, this was provisioned in a K8s cluster on top of VMware PKS, vSphere and vSAN infrastructure. BTW, the issue with pillowfight was reported here (issue is resolved). 

Author

Posted by Anil Kumar, Director Product Management, Couchbase Cloud-Native Database

Anil Kumar is the Director of Product Management at Couchbase. Anil’s career spans more than 19+ years of building software products across various domains, including enterprise software and cloud services. He is a hands-on product leader responsible for Couchbase Server, Couchbase Cloud, and Kubernetes product lines, including evangelizing the product strategy and vision with customers, partners, developers, and analysts. Before joining Couchbase, Anil spent several years working at Microsoft Redmond. Anil holds a master’s degree in computer science from the University of Toronto (Canada) and a bachelor’s in information technology from Visvesvaraya Technological University (India).

Leave a reply