Install and Get Started with Couchbase Service Broker on Kubernetes
This section describes how to get and install the service broker and create your first service instance.
The Service Broker is just a simple web-service that creates Kubernetes resources on demand as requested by the API. This tutorial will walk you through the steps to install and get started with Couchbase Service Broker on Kubernetes.
This page details the platform and software requirements for running the Service Broker.
The following platforms are supported:
In general, any Kubernetes distribution based on a supported version should work.
The Service Broker is recommended for use with the Kubernetes Service Catalog. Installation instructions can be found in the official documentation. As the Service Broker is standards based, any version of the Service Catalog supporting the Open Service Broker API version 2.13+ is supported.
Install the Operator CRDs, dynamic admission controller and Operator as documented here. For this guide, the Operator must be deployed at the cluster scope, not the default namespaced scope.
Download Couchbase Service Broker package and unpack on the same computer where you normally run kubectl.
The Couchbase Service Broker package contains YAML configuration files and command-line tools that you will use to install the Couchbase Service Broker and Couchbase Clusters.
After you unpack the downloaded package, the resulting directory will be titled something like couchbase-service-broker_x.x.x. Make sure to
The Service Broker is configured using a Kubernetes Custom Resource that allows type checking of your configurations and must be installed first:
$ kubectl create -f crd.yaml
For users of Red Hat OpenShift, you can use the base Kubernetes download package and images. The Service Broker is a statically compiled binary, so does not need an entire Red Hat Enterprise Linux base image. It is safer to use the Kubernetes image as it contains fewer security vulnerabilities. You may be required to use the Red Hat images for policy compliance, for example.
If you choose to use the OpenShift download package may need to modify the following
$ kubectl create -f broker.yaml
The ServiceAccount the Service Broker runs as is bound to the Role we created in the previous step. A Secret contains the TLS configuration and bearer token for authentication as the Service Broker is secure by default.
If you wish to deploy the Service Broker in a namespace other than
For example, if the service broker service is called
Finally, you must update any resources references to the
The Deployment creates the Service Broker and ensures it is highly available and a Service makes it discoverable by the Kubernetes Service Catalog in the next step. Check the status of the service broker
$ kubectl get deployments NAME READY UP-TO-DATE AVAILABLE AGE couchbase-operator 1/1 1 1 33m couchbase-operator-admission 1/1 1 1 37m couchbase-service-broker 1/1 1 1 32m
$ svcat provision csb --class couchbase-osb-service --plan csb-basic --param password=password --wait
You will end up with a 3 node cluster (by default), with a Bucket, an Administrator user with the password you provided.
$ svcat bind csb Name: csb Namespace: default Status: Secret: csb Instance: csb Parameters: No parameters defined
This will create a user and allow access to the bucket. Connection string, username, password and CA certificate will be in the secret, ready to be used by a client of some variety.
$ kubectl get secrets csb NAME TYPE DATA AGE csb Opaque 5 7m58s
To access the couchbase cluster UI console:
$ kubectl port-forward couchbase-instance-winhhoku-0000 8091
Go to http://localhost:8091 and login with username as Administrator & password as password.