Multi-Cloud Kubernetes using Open Service Broker API & Kubernetes Service Catalog

Kubernetes Multi-Cloud Open Service Broker API & Service Catalog

Simply said, a multi-cloud strategy is the use of two or more cloud computing services. With such strategy users can choose the best services from different cloud platforms and combine them to create the best possible solution for your business. The2018 State of the Cloud Surveyshows that 81% of enterprises use multiple clouds.

Kubernetes has been widely accepted as the best way to deploy and operate containerized applications. And, one of the key value propositions of Kubernetes is that it can help normalize capabilities across cloud providers. What if a user wants to tie resources on different platforms to Kubernetes applications which will provide him with abundant advantage while not building the same on-prem? what platform do you put where to get the most value out of it in the most efficient way? Azure MysQL Service for MySQL or Amazon RDS for PostgreSQL? AWS SQS or Azures AQS? or Want to experiment with voice interfaces? Lex answers the call. You have 18 AWS services to choose from!

The Open Service Broker API is an industry-wide effort to meet the demand of consuming cloud services through a simple and secure mechanism. The project has contributors from Google, IBM, Pivotal, Red Hat, SAP and many other leading cloud companies.

The Service Catalog provides a way for developers, ISVs, and SaaS vendors to provision instances of services that can be consumed by applications in a standard way. Service Catalog is an extension API that enables applications running in Kubernetes clusters to easily use externally managed software offerings, such as a datastore service offered by a cloud provider.A Service Broker is an implementation of the open-sourceOpen Service Broker (OSB) APIwhich simplifies the delivery of cloud-platform specific services to applications that run on Kubernetes.

Using the Service Catalog architecture, an application developer has the ability to request services from a catalog without worrying about how and where they are provisioned. Once the service is available, they can bind the service to their application and consume any associated credentials. These provisioning and binding requests are made to Service Brokers (AWS-Service Broker, Azure Service Broker, GCP Service-Broker etc.), which are registered with the Service Catalog and act as the glue code between the services running on other platforms and applications.

On Kubernetes Service Catalog constitutes a catalog-apiserver and a catalog-controller-manager deployed as Kubernetes Deployment as shown below:

Assume an application developer wants to run a web-application on on-premise Kubernetes cluster and consume Azure MySQL for database and AWS S3 for storage backend and has completely no knowledge on operating the same (gluing these services together with the application), Service Broker comes into the rescue enabling a seamless integration of backend services with the application itself.

A Service Broker provides numerous Service Classes (For example, Azure MySQL would be one of these Service Classes if the Azure broker is deployed in the cluster. Something like a cloud service) and each Service Class will constitute numerous Service Plans (For example, Azure MySQL-Basic, Azure MySQL-Production_Grade etc. Something like a flavor/plan).

Compatible API server that provisions managed services in the Microsoft Azure public cloud. Microsoft has been an active contributor to the Service Catalog, which enables Kubernetes operators to leverage cloud-native services provided by Azure platform.

Information below shows a sample workflow of connecting a WordPress application running on Kubernetes on-premise cluster to Azures MySQL service using Azures OSBA

Open Service Broker for Azure is deployed as a Pod/Deployment on Kubernetes and uses Redis as a backing store for its state.

A user account with required credentials should be provided while creating the Service Broker deployment.

As shown above svcat is a command line tool for service catalog and once Azures OSBA available the same lists all the Service Classes available. As mentioned above each Service Class will comprise multiple Service Plans. For example azure-mysql Service Class will include the plans shown below:

Users can choose a plan based on the requirement. Open Service Broker for Azure uses a service principal to provision Azure resources on users behalf or in this case provides a authentic medium to deploy the services seamlessly by the broker. A Resource Group (RG) should be created which groups a collection of assets created by OSBA in logical groups for easy or even automatic provisioning.

A WordPress application is deployed which by default, utilizes Open Service Broker For Azure to provision anAzure Database for MySQLdatabase for the WordPress server to use.

Once the application is deployed which includes a ServiceInstance and ServiceBinding resources in it a MySQL resource is requested on users Azure account.

This initiates the service deployment on users Azure account as shown below:

As a RG and SP are already declared above, all the resources are grouped under the specified Resource Group as shown below:

As shown below a DB entry will be created in Azures MySQL service to be used by WordPress where all the pipelining is done seamlessly.

Verifying the connectivity by logging to the MySQL service using the Server Name from above we can see that the WordPress application running on-prem is writing the data to Azure MySQL service:

The Broker provides simple integration of AWS Services directly within the application platform integrate AWS services directly into applications running on Kubernetes.

Information below shows a sample workflow of using AWS S3 for storage by a Kubernetes pod running in a on-premise cluster. This requires Service Catalog running on Kubernetes cluster.

2. An S3 bucket to store templates used by the Broker to manage the AWS services.

3. An IAM role with permissions to interact with the DynamoDB table, the S3 bucket, and AWS CloudFormation.

All these pre-requisites can be created using a Cloud-Formation template provided by official AWS resources.

AWS Service Broker is deployed as a Kubernetes Deployment:

Once the same is deployed the catalog gets synced and users should be able to see all the Service Classes supported by the broker.

A sample web-application is deployed which by default uses S3 as storage for backend which randomly writes to a S3 Bucket.

With the creation of above application the AWS Cloudformation service starts creating S3-buckets for application using the IAM configuration done above.

As seen above a S3-Bucket and a Logging-Bucket is created seamlessly to cater application storage.

A Service Instance objected will be created on the Kubernetes namespace with the Service Class selected and the Service Catalog interacts with the Service Broker to sync the information to the local environment as shown below:

Service Instance information will be written to one of the DynamoDB tables for tracking the state:

An authentication binding to access the S3 resources created on AWS is provided by a Service Binding:

As the Secret object is not supplied to the application container created above access to the S3 resources will be barred as shown below:

All the secrets that are gathered can be supplied to the application created above using container_spec in the manifest as shown below:

Once the above credential/secrets are provided to the application, the application can write to S3 bucket on AWS. Quickly testing the connectivity:

As seen above the application on Kubernetes on-premise cluster can write to a S3-Bucket on AWS.

The Service Catalog offers powerful abstractions to make external services available in a Kubernetes cluster running in diversified environments. These services are typically third-party managed cloud offerings which are native to a specific cloud-platform, where the complete abstraction is made much easier masking the integration complexities. Service Catalog and Service Brokers are not restricted just for Public Cloud Platforms but these can be leveraged for multiple internal services. On the other hand, developers can focus on the applications without the need for managing complex services deployment.

ITNEXT is a platform for IT developers & software engineers to share knowledge, connect, collaborate, learn and experience next-gen technologies.

Software Engineer Solutions – Volterra Edge Services (ves.io)

ITNEXT is a platform for IT developers & software engineers to share knowledge, connect, collaborate, learn and experience next-gen technologies.

Welcome to a place where words matter. OnWatch

Follow all the topics you care about, and well deliver the best stories for you to your homepage and inbox.Explore

Get unlimited access to the best stories onUpgrade