Open Service Broker for Azure (OSBA) with Azure Kubernetes Service (AKS)

How to use Open Service Broker for Azure in combination with Azure Kubernetes Service (AKS)

In case you missed it, the Azure Managed Kubernetes service (AKS) has been released today (June, 13th 2018, hoooooray 🙂 see the official announcement from Brendan Burns here) and it is now possible to run production workloads on a fully Microsoft-managed Kubernetes cluster in the Azure cloud. “Fully managed” means, that the K8s control plane and the worker nodes (infrastructure) are managed by Microsoft (API server, Docker runtime, scheduler, etcd server…), security patches are applied on a dialy basis to the underlying OS, you get Azure Active Directory integration (currently in preview) etc. And what’s really nice: you only pay for the worker nodes, the control plane is completely free!

The integration of Kubernetes into the Azure infrastructure part is really impressive, but when it comes to service integration and provisioning on the cloud platform there is still room for improvement…but it’s on its way! The Open Service Broker for Azure (currently alpha) closes the gap between Kubernetes workloads that require certain Azure services to run and the provisioning part of these services as it makes it possible e.g. to create a SQL server instance in Azure via a Kubernetes “YAML”-file during deployment of other Kubernetes objects on the fly. Sounds good? Let’s see, how this works.

Creating a Kubernetes Demo Cluster

First of all, we need a Kubernetes cluster to be able to test the Open Service Broker for Azure – we are going to use Azure CLI, therefore please make sure you have installed the latest version of it.

Okay, so let’s create an Azure resource group where we can deploy the AKS cluster to afterwards:

// resource group
az group create --name osba-demo-rg --location westeurope

// AKS cluster - version must be above 1.9 (!)
az aks create 
        --resource-group osba-demo-rg 
        --name osba-k8sdemo-cluster 
        --generate-ssh-keys  
        --kubernetes-version 1.9.6

When the deployment of the cluster has finished, download the corresponding kubeconfig file:

az aks get-credentials 
        --resource-group osba-demo-rg 
        --name osba-k8sdemo-cluster

Now we are ready to use kubectl to work with the newly created cluster. Test the connection by querying the available worker nodes of the cluster:

kubectl get nodes

You should see something like this:

nodes

Before we can install the Open Service Broker, we also need a service principal in Azure that is able to interact with the Azure Resource Manager and create resources on behalf of us (think of it as a “service account” in Linux / Windows).

az ad sp create-for-rbac --name osba-demo-principal -o table

Important: Remember “Tenant”, “Application ID” and “Password” for you will need these values when installing the OSBA now.

Installing OSBA

Cluster Installation

We are using Helm to install OSBA on our cluster, so we first need to prepare your local machine for Helm (FYI: your AKS cluster is by default ready to use Helm, so there’s no need to install anything on it – anyway, you need to install the Helm client on your workstation):

helm init

Next, we need to deploy the Service Catalog on the cluster:

helm repo add svc-cat https://svc-catalog-charts.storage.googleapis.com

helm install svc-cat/catalog --name catalog --namespace catalog \
   --set rbacEnable=false \
   --set apiserver.storage.etcd.persistence.enabled=true

Now we are ready to deploy OSBA to the cluster:

// add the Azure charts repository

helm repo add azure https://kubernetescharts.blob.core.windows.net/azure


// finally, add the service broker for Azure

helm install azure/open-service-broker-azure --name osba --namespace osba `
  --set azure.subscriptionId=<Your Subscription ID>  `
  --set azure.tenantId=<Tenant> `
  --set azure.clientId=<Service Principal Application ID> `
  --set azure.clientSecret=<Service Principal Password>

Info: In case you don’t know your Azure subscription Id, run…

az account show

…and use the value of property “id”.

You can check the status of the deployments (catalog & service broker) by querying the running pods in the namespaces catalog and osba.

pods

Service Catalog Client Tools

Service Catalog comes with its own command line interface. So you need to install it on your machine (installation instructions).

Using the OSBA for Service Provisioning

Now, we are prepared to provision / create so-called “ServiceInstances” (Azure resources) and “bind” them via “ServiceBindings” in order to be able to use them as resources/endpoints/services etc. in our pods.

In the current example, we want to provision an Azure SQL DB. So first of all, we need to create a service intance of the database. Therefore, use the following YAML definition:

As you can see, you, there are some values, you have to provide to OSBA:

  • clusterServiceClassExternalName – in our case, we want to create an Azure SQL DB. You can query the available service classes by using the following command: svcat get classes. We will be using azure-sql-12-0.
  • clusterServicePlanExternalName – the service plan name which represents the service tier in Azure. Use svcat describe classes azure-sql-12-0 to show the available service plans for class azure-sql-12-0. We will be using standard-s1.
  • resourceGroupthe Azure resource group for the server and database

 

 

classes

Show available service classes via “svcat get classes

azure-sql-12-0

Show available service plans for class “azure-sql-12-0” via “svcat describe classes azure-sql-12-0

Now, create the service via kubectl:

kubectl create -f .\service-instance.yaml

Query the service instances by using the Service Catalog CLI:

svcat get instances

The result should be (after a short amount of time) something like that:

instances

In the Azure portal, you should also see these newly created resources:

portal_resources

Now that we have created the service instance, let’s bind the instance, in order to be able to use it. Here’s the YAML file for it:

kubectl create -f service-binding.yaml

As seen with the service instance, the service binding also needs some parameters in order to work. Of course, the binding needs a reference to the service instance, it wants to use (instanceRef). The more interesting property is secretName. While creating the binding, the service broker also creates a secret in the current namespace, where important values ( like passwords, server name, database name, URIs etc.) are added. You can reference the secret / values afterwards in your K8s deployments and add them e.g. as environment variables to your pods.

Now let’s see, if the binding has been created via svcat:

bindings

That look’s good. Over to the Kubernetes dashboard, to see, if the secret has been created in the default namespace.

secret

Kubernetes secret

It seems like everything was “bound” for usage as expected and we are now ready to use the Azure SQL DB in our containers/pods!

Wrap Up

As you have seen in this example, with the Open Service Broker for Azure it is very easy to create Azure resources via Kubernetes object definitions. You simply need to install OSBA to your cluster with Helm! Afterwards, you can create and bind Azure services like Azure SQL DB. If you are curious what resource providers are supported (remember, OSBA is still in early development stage), there are currently three services, that are in preview:

…and some experimental services:

  • Azure CosmosDB
  • Azure KeyVault
  • Azure Redis Cache
  • Azure Event Hubs
  • Azure Service Bus
  • Azure Storage
  • Azure Container Instances
  • Azure Search

The up-to-date list can always be found here: https://github.com/Azure/open-service-broker-azure/tree/master/docs/modules

Have fun with it 🙂

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: