Editor’s note: today’s guest post is by Arun Gupta, Vice President Developer Relations at Couchbase, showing how to setup a Couchbase cluster with Kubernetes.
Couchbase Server is an open source, distributed NoSQL document-oriented database. It exposes a fast key-value store with managed cache for submillisecond data operations, purpose-built indexers for fast queries and a query engine for executing SQL queries. For mobile and Internet of Things (IoT) environments, Couchbase Lite runs native on-device and manages sync to Couchbase Server.
Couchbase Server 4.5 was recently announced , bringing many new features , including production certified support for Docker . Couchbase is supported on a wide variety of orchestration frameworks for Docker containers, such as Kubernetes, Docker Swarm and Mesos, for full details visit this page .
This blog post will explain how to create a Couchbase cluster using Kubernetes. This setup is tested using Kubernetes 1.3.3, Amazon Web Services, and Couchbase 4.5 Enterprise Edition.
Like all good things, this post is standing on the shoulder of giants. The design pattern used in this blog was defined in a Friday afternoon hack with @saturnism . A working version of the configuration files was contributed by @r_schmiddy .
Couchbase Cluster
A cluster of Couchbase Servers is typically deployed on commodity servers. Couchbase Server has a peer-to-peer topology where all the nodes are equal and communicate to each other on demand. There is no concept of master nodes, slave nodes, config nodes, name nodes, head nodes, etc, and all the software loaded on each node is identical. It allows the nodes to be added or removed without considering their “type”. This model works particularly well with cloud infrastructure in general. For Kubernetes, this means that we can use the exact same container image for all Couchbase nodes.
A typical Couchbase cluster creation process looks like:
Start Couchbase: Start n Couchbase servers Create cluster: Pick any server, and add all other servers to it to create the cluster Rebalance cluster: Rebalance the cluster so that data is distributed across the clusterIn order to automate using Kubernetes, the cluster creation is split into a “master” and “worker” Replication Controller (RC).
The master RC has only one replica and is also published as a Service. This provides a single reference point to start the cluster creation. By default services are visible only from inside the cluster. This service is also exposed as a load balancer. This allows the Couchbase Web Console to be accessible from outside the cluster.
The worker RC use the exact same image as master RC. This keeps the cluster homogenous which allows to scale the cluster easily.
Configuration files used in this blog are available here . Let’s create the Kubernetes resources to create the Couchbase cluster.
Create Couchbase “master” Replication Controller
Couchbase master RC can be created using the following configuration file:
apiVersion: v1kind: ReplicationController
metadata:
name: couchbase-master-rc
spec:
replicas: 1
selector:
app: couchbase-master-pod
template:
metadata:
labels:
app: couchbase-master-pod
spec:
containers:
- name: couchbase-master
image: arungupta/couchbase:k8s
env:
- name: TYPE
value: MASTER
ports:
- containerPort: 8091
----
apiVersion: v1
kind: Service
metadata:
name: couchbase-master-service
labels:
app: couchbase-master-service
spec:
ports:
- port: 8091
selector:
app: couchbase-master-pod
type: LoadBalancer
This configuration file creates a couchbase-master-rc Replication Controller. This RC has one replica of the pod created using the arungupta/couchbase:k8s image. This image is created using the Dockerfile here . This Dockerfile uses a configuration script to configure the base Couchbase Docker image. First, it uses Couchbase REST API to setup memory quota, setup index, data and query services, security credentials, and loads a sample data bucket. Then, it invokes the appropriate Couchbase CLI commands to add the Couchbase node to the cluster or add the node and rebalance the cluster. This is based upon three environment variables:
TYPE : Defines whether the joining pod is worker or master AUTO_REBALANCE