This blog is possible because of this tweet!

Had a great #Couchbase #Kubernetes hacking session with @saturnism, learned a lot, look forward to some nice blogs.

— Arun Gupta (@arungupta) February 27, 2016

Kubernetes is an open source orchestration system by Google for Docker containers.  It manages containerized applications across multiple hosts and provides basic mechanisms for deployment, maintenance, and scaling of applications.

It allows the user to provide declarative primitives for the desired state, for example “need 5 Couchbase servers”. Kubernetes self-healing mechanisms, such as auto-restarting, re-scheduling, and replicating containers then ensure that this state is met. The user just define the state and Kubernetes ensures that the state is met at all times on the cluster.

Key Concepts of Kubernetes explains the key concepts of Kubernetes.

This multi-part blog series will show how to run Couchbase on Kubernetes in multiple ways. The first part starts with a simple setup using Vagrant.

Getting Started with Kubernetes

There are multiple ways to run Kubernetes but I found the simples (not necessarily predictable 😉 way is to run using Vagrant.

• Download the latest Kubernetes release, 1.1.8 as of this writing, and expand the archive.
• Start the Kubernetes cluster as:
  
  cd kubernetes export KUBERNETES_PROVIDER=vagrant ./cluster/kube-up.sh

  1 2 3 4 5 6

  cd kubernetes   export KUBERNETES_PROVIDER=vagrant ./cluster/kube-up.sh

  This shows the output as:
  
  kubernetes-1.1.8 > ./kubernetes/cluster/kube-up.sh ... Starting cluster using provider: vagrant ... calling verify-prereqs ... calling kube-up Bringing machine 'master' up with 'virtualbox' provider... Bringing machine 'minion-1' up with 'virtualbox' provider... ==> master: Importing base box 'kube-fedora21'... . . . Validate output: NAME STATUS MESSAGE ERROR controller-manager Healthy ok nil scheduler Healthy ok nil etcd-0 Healthy {"health": "true"} nil etcd-1 Healthy {"health": "true"} nil Cluster validation succeeded Done, listing cluster services: Kubernetes master is running at https://10.245.1.2 Heapster is running at https://10.245.1.2/api/v1/proxy/namespaces/kube-system/services/heapster KubeDNS is running at https://10.245.1.2/api/v1/proxy/namespaces/kube-system/services/kube-dns KubeUI is running at https://10.245.1.2/api/v1/proxy/namespaces/kube-system/services/kube-ui Grafana is running at https://10.245.1.2/api/v1/proxy/namespaces/kube-system/services/monitoring-grafana InfluxDB is running at https://10.245.1.2/api/v1/proxy/namespaces/kube-system/services/monitoring-influxdb

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

  kubernetes-1.1.8 > ./kubernetes/cluster/kube-up.sh ... Starting cluster using provider: vagrant ... calling verify-prereqs ... calling kube-up Bringing machine 'master' up with 'virtualbox' provider... Bringing machine 'minion-1' up with 'virtualbox' provider... ==> master: Importing base box 'kube-fedora21'...   . . .   Validate output: NAME                 STATUS    MESSAGE              ERROR controller-manager   Healthy   ok                   nil scheduler            Healthy   ok                   nil etcd-0               Healthy   {"health": "true"}   nil etcd-1               Healthy   {"health": "true"}   nil Cluster validation succeeded Done, listing cluster services:   Kubernetes master is running at https://10.245.1.2 Heapster is running at https://10.245.1.2/api/v1/proxy/namespaces/kube-system/services/heapster KubeDNS is running at https://10.245.1.2/api/v1/proxy/namespaces/kube-system/services/kube-dns KubeUI is running at https://10.245.1.2/api/v1/proxy/namespaces/kube-system/services/kube-ui Grafana is running at https://10.245.1.2/api/v1/proxy/namespaces/kube-system/services/monitoring-grafana InfluxDB is running at https://10.245.1.2/api/v1/proxy/namespaces/kube-system/services/monitoring-influxdb

Run Couchbase on Kubernetes Cluster

The easiest way to start running a Docker container in Kubernetes is using the kubectl run command.

The command usage is:

The command runs a particular image, possibly replicated. The image replication is handled by creating a Replication Controller to manage the created container(s).

Complete list of options to run this command can be seen using:

Couchbase Docker Container explains the different Docker container for Couchbase. For this blog, we’ll use arungupta/couchbase image as that is pre-configured.

This shows the output:

The output confirms that a Replication Controller is created. Lets verify it:

Now, check the pods:

Lets check the status of the pod:

Fifth line of the output says the node’s IP is 10.245.1.4. This would be used to access the Web Console later.

The last line in this output shows that the pod is now ready. Checking the status of the pod again shows:

Couchbase Web Console on Kubernetes Cluster

Now that your Couchbase container is running in Kubernetes cluster, you may like to view the Web Console.

Each pod is assigned a unique IP address, but this address is only accessible within the cluster. It can exposed using the kubectl expose command.

This command takes a Replication Controller, Service or Pod and expose it as new Kubernetes Service. This can be done by giving the command:

In this command:

• --target-port is the name or number for the port on the container that the service should direct traffic to
• --port is the port that the service should serve on
• --external-ip is the external IP address to set for the service. Note, this IP address was obtained with kubectl describe pod command earlier.

Now, you can access the Couchbase Web Console at http://10.245.1.4:8091 and looks like:

Enter the password credentials as Administrator/password. These credentials are specified during Docker image creation at github.com/arun-gupta/docker-images/blob/master/couchbase/configure-cluster.sh#L9.

Voila!

Discuss with us at StackOverflow or Couchbase Forums. You can also follow us at @couchbasedev and @couchbase.

Source: http://blog.couchbase.com/2016/couchbase-on-kubernetes

Be Sociable, Share!

• 

•