Using Instaclustr with Kubernetes

This document will instruct you how to install the Service Catalog extension and create a service broker instance in your Kubernetes cluster.

We will complete the following steps

1. Install the Service Catalog extension
2. Set up a Secret and create a namespace
3. Create the Instaclustr Service Broker as “ClusterServiceBroker”
4. Create a Service Instance (new or existing)
5. Create an Instance Binding
6. Unbind a Service Instance
7. Deprovision a Service Instance

The Instaclustr Service Catalog is built according to the Open Service Broker specification, this article will use some of that terminology below.

1. Install Service Catalog

1.1 Install helm:

Download and Install helm on your Kubernetes cluster from script or source. Note that the helm init will install tiller while initialising. If not install tiller separately. 

More detailed install process in this article: helm

1.2 Use helm to install Service Catalog

• Using helm add the service-catalog Helm repository
• Configure Tiller to have cluster-admin access
• Install service Catalog in your Kubernetes cluster

You can run kubectl get pods -n catalog to check if catalog-api and catalog manager is running.

2. Set up a Secret and create a namespace

2.1 Set up a Secret

Detailed steps are here: Secret.

Get your Instaclustr Username and ProvisioningKey, the provisioning key can be retrieved from the Instaclustr Console. Then run the following command to generate the secret:

You can get username and provisioning key from your instaclustr console.

You can run kubectl get secret and see the new secret.

You can create secrets manually.

2.2 Create a namespace

3. Create Instaclustr Service Broker as “ClusterServiceBroker”

At this point, your K8s can create a ClusterServiceBroker and sync our catalog.

3.1 Create a ClusterServiceBroker

You will need a yaml file which looks like this:

Please note, the secretRef.name is the secret we created in the “2. Set up Secret”.

And then run:

You can run kubectl get ClusterServiceBroker (or svcat get broker my-broker or svcat describe broker my-broker) to view your service broker.

3.2 Check out the ClusterServiceClass and ClusterServicePlan

Use the following command:

The output should be similar to this:

3.3 Get details about a particular ClusterServiceClass and a particular ClusterServicePlan

Use the following command:

The output should be similar to this:

4. Create a new Service Instance

As mentioned in the previous step, the Service Catalog currently offers two plans:

1. new-cluster – create a new cluster in the Instaclustr managed service.
2. existing-cluster – link to an existing cluster in the Instaclustr managed service.

In both cases, the functionality is identical, but fields differ for creating them.

4.1a Create a new Cluster – yaml

“Provision a new cluster, deprovisioning will delete this cluster from our managed platform”

Note: these values are an indication only, the Service Catalog is built on top of our existing provisioning api, all the fields are supported in yaml format.

4.1b Connect an existing cluster – yaml

“Link an existing cluster, deprovisioning will NOT delete this cluster from our managed platform”

Note: The provisioning key setup in the kubernetes secret will be used to determine ownership of the cluster, if that account doesn’t own the cluster, the command will fail.

4.2 Create the service instance

The command you run will be:

Please note, the spec.clusterServiceClassName and spec.clusterServicePlanName is listed from step 3.3.

It will look like this:

You can run svcat describe instance my-instance -n my-namespace to check your instance. It should look something like this:

After a while when the cluster enters into the RUNNING state, the same command will produce something like this:

5. Create a Binding to the Service Instance created in Step 4

You will need a yaml file like this:

The output should look something like this:

You can run svcat describe binding my-binding -n my-namespace to check your binding. It should look something like this:

If user authentication is enabled on your newly provisioned cluster, the default superuser credentials will be returned in the Service Binding. It should look something like this:

Note: The default credentials will be automatically removed from our management system, 5 days after cluster provisioning.
It is highly recommended that as part of configuring your cluster you:

• Change the password for the default superuser.
• Create a non-superuser account for your client.
• Create a new secret on your kubernetes cluster with the new credentials.

The details of the secret data can be viewed using the following commands:

(to obtain the private addresses) :
kubectl get secret my-binding -n my-namespace -o yaml | grep node-private-address | awk -F “:” ‘{print $2}’ | base64 –decode 

(to obtain the public addresses) :
kubectl get secret my-binding -n my-namespace -o yaml | grep node-public-address | awk -F “:” ‘{print $2}’ | base64 –decode 

Note, the IP addresses shown above may vary.

6. Unbind the Service Instance

To unbind, use the command svcat unbind my-instance -n my-namespace. Note: When you unbind a Service Instance, this process will delete the connection details and credentials for Service Instance of the corresponding service (Kafka or Cassandra) from the Kubernetes environment.

To check that the binding is actually deleted, you can either use the command svcat describe binding my-binding -n my-namespace OR kubectl get secret my-binding -n my-namespace.

The output looks something like this:

7. Deprovision/Delete a Service Instance

Important note: The Instaclustr Service Catalog will only delete clusters created through the Service Catalog. If you use the “exiting cluster” plan, the cluster will not be deleted.

To deprovision/delete an instance, use the command svcat deprovision my-instance -n my-namespace.

To check that the instance is actually deleted, you can use the command svcat describe instance my-instance -n my-namespace.

The output looks something like this: