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.

    Prerequisites

    This page details the platform and software requirements for running the Service Broker.

    Kubernetes Cluster

    The following platforms are supported:

    • Kubernetes 1.17+

    In general, any Kubernetes distribution based on a supported version should work.

    Kubernetes Service Catalog

    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.

    Couchbase Autonomous Operator

    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.

    Package Downloads

    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.

    Install Couchbase Service Broker

    After you unpack the downloaded package, the resulting directory will be titled something like couchbase-service-broker_x.x.x. Make sure to cd into this directory before you run the remaining commands in this guide.

    Install the CRD

    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

    Install a Configuration

    $ kubectl create -f servicebrokerconfig.yaml

    Install the Service Broker Service

    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 broker.yaml configuration and alter the following, depending on your environment:

    • You may need to create a Docker secret in the namespace into which you deploy the Service Broker, in order to authenticate against the Red Hat Container Registry, and pull the image. This secret needs to be added to the couchbase-service-broker service account’s image pull secrets in order to pass the privileges on to the Service Broker deployment.

    $ 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 default, you will need to manually generate TLS certificates. Your CA certificate must be installed in the couchbase-service-broker cluster service broker, defined in clusterservicebroker.yaml. Your server certificate or certificate chain, and private key, must be installed in the couchbase-service-broker secret, defined in broker.yaml. The server certificate must have a subject alternative name (SAN) valid for the service broker service.

    For example, if the service broker service is called couchbase-service-broker and it will be installed in the foo namespace, then your server certificate should have a DNS SAN valid for couchbase-service-broker.foo.svc.

    Finally, you must update any resources references to the default namespace, to foo. These can be found in the couchbase-service-broker cluster role binding defined in broker.yaml and the couchbase-service-broker cluster service broker defined in clusterservicebroker.yaml.

    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

    Register the Service Broker with the Service Catalog

    The final step is to tell the Kubernetes Service Catalog about our Service Broker.

    $ kubectl create -f clusterservicebroker.yaml

    Provision the Couchbase Cluster Service:

    $ 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.

    Bind to the Provisioned Service

    $ 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.