Service Catalog and Kubernetes

In the past few years the terms cloud-native infrastructure and cloud-native applications have been widely used to describe a new software paradigm that focuses on infrastructure and applications designed, implemented and deployed with the idea that they will be using the different technologies offered by public or private cloud providers. These applications will often follow a microservices architecture, might be packaged as containers and will use some of the managed services from these clouds, like object storage, databases or pub-sub queues. 

As more and more of these applications get packaged as containers, they get deployed to a container orchestrator. Kubernetes has quickly become one of the most popular container orchestrators in this new cloud-native world.

One reason for Kubernetes’ success is its declarative object configuration model. In this model, the developer or the cluster administrator uses Kubernetes objects descriptions to describe the state they want to see in the cluster, and Kubernetes will perform the needed actions to move from its current state to the requested state. This is done instead of sending imperative actions to the Kubernetes API to tell it what to do. This allows Kubernetes to “auto-heal” if something breaks (for example, if a pod crashes). Kubernetes will realize that its current state is not the same as the requested state and will again perform the needed actions to get back to that requested state.

However, cloud-native applications do not just live inside Kubernetes; they also benefit from using the available cloud managed services. By using cloud managed services for their applications, developers can focus on the area of their application that provides business value and leverage the required infrastructure components of the cloud vendors. When combining Kubernetes services with cloud managed services, it’s beneficial to keep the same declarative model and be able to describe your full application, including the services it depends on, as a set of Kubernetes objects.

The community has been looking for a solution to this cross-platform/cross-cloud problem since the beginning of the Kubernetes project. The Open Service Broker API with the Service Catalog is one of the solutions with a wider adoption.

Open Service Broker API and Service Catalog

The Open Service Broker API (OSBAPI) is a standard specification for cloud providers to define services and provide a common API to access and manage those services. OSBAPI was originally defined for the Cloud Foundry, but soon was backed by the Kubernetes and Openshift projects. It is currently maintained by a project committee with members from different companies. The Service Catalog is a Kubernetes API extension that implements this standard. The project is a Kubernetes incubator project and its API is currently in version v1beta1.

The API defines a set of classes to describe a service provider and the different services it provides. It also defines objects to connect Kubernetes applications to the different service instances.

• Service Broker

This object defines a service provider. The Service Catalog only defines the Kubernetes object, not the implementation of the broker itself, which will depend on the service provider. The definition of the object only requires an endpoint to talk to the broker and some authorization information to be able to connect to that URL.

• Service Class

This object abstracts the idea of a service. For example, Azure MySQL would be one of these Service Classes if the Azure broker is deployed in the cluster. A Service Broker will provide one or more of these classes for the users of the cluster.

• Service Plan

A service offered by a public cloud provider usually has several tiers. For example, tiers could include a small instance with just one CPU core and 1GB of RAM, which would be ideal for developing and testing, and a bigger instance with four cores and 16GB of RAM, which would be suited for a production environment. Each Service Class will have one or many Service Plans.

• Service Instance

When an application requires a particular service (database, object storage, etc.), it can request from the Service Broker an instance of a specific Service Plan by creating a Service Instance object. The Service Catalog controller will then talk to the Service Broker endpoint to provision a new instance of the service.

• Service Binding

This object abstracts the action of connecting an application to the Service Instance. Once a Service Binding is requested, the Service Broker will return a new Service Binding and a Kubernetes Secret with the connection information, which can be used by the application to connect to the service.

Current Status

Service Catalog is a Kubernetes incubation project, currently on version 0.1.38, with an API version v1beta1. These version numbers explain the unstable nature of the project, currently managed by a Kubernetes Special Interest Group (SIG). The project is still under heavy development and the project’s Kubernetes controller is not yet stable, crashing often and leaving the API server in a state that can’t be easily recovered.

When the Service Catalog project was started, Kubernetes didn’t have the concept of Custom Resource Definitions (CRDs), which is a way to extend the Kubernetes API without having to write your own API server. The Service Catalog, instead, implements an aggregated API server, which requires writing an API server from scratch and maintaining its code. Using CRDs would allow the Service Catalog to only own the Controller implementation and to benefit from the implementation improvements of the general API machinery and the CRDs tools. Currently, the Service Catalog SIG is discussing internally whether to migrate the project to CRDs before moving the API to a stable version.

In terms of support from the major public clouds, the Service Catalog receives contributions from Azure, IBM, Google and others. Apart from contributing to the core project, some of the major public clouds have implemented a Service Broker for their cloud services, following the Open Service Broker API:

• Azure. Azure maintains a Service Broker for Kubernetes that runs as a service directly in your Kubernetes cluster. Their Service Broker is actively maintained and well-documented. It supports several Azure services, from databases to IoT Event Hubs.
• GCP. Google also has its own implementation of a Service Broker for its GCP services. The documentation includes a set of examples to get started.
• AWS. Amazon Web Services offers an AWS Service Broker compatible with Kubernetes, Openshift and Cloud Foundry. The implementation is still fairly new and it is not yet well-documented.

Future and Alternatives

The Open Service Broker API / Service Catalog has the potential to become a well-supported standard to deploy multi-cloud services from Kubernetes following a declarative model with an extension to the Kubernetes API. The OSBAPI is governed by an independent project management committee and the Service Catalog project is governed by a SIG, part of the Kubernetes project, and gets contributions from developers from IBM, Azure, Google and others. Despite this, it has been more than a year and a half since its first release and it hasn’t been widely adopted. These are some of the reasons why and how the community is trying to overcome these limitations.

One of the reasons the Service Catalog doesn’t currently work for a true multi-cloud solution is that the way to connect to the services depends on the implementation of the Service Broker and the specific service. For example, the schema of the secret that gets created when binding an Azure MySQL instance will be different from the schema of the secret that gets created when binding a Google Cloud SQL instance. Because of these two different schemas, a developer won’t be able to write their application so it connects to a generic Service Catalog MySQL instance (and decides later which cloud to use) or to migrate easily from one cloud to another without having to rewrite their Kubernetes manifests. Acknowledging this limitation, a different SIG (called SIG Apps —  the group that defines how to deploy and manage applications in Kubernetes) has presented a Kubernetes Enhancement Proposal (KEP) called Portable Service Definitions. This KEP tries to provide a means to define a common way to request external services — for example, a MySQL database. This definition would be common to any MySQL service, without taking into account which cloud provides the service. Using this feature, a developer would be able to write their application knowing that it will require an external MySQL instance, but without needing to know beforehand which cloud will provide the service.

Another issue is the stability of the Service Catalog API server and its Controller. As discussed previously, the API server and its Controller are currently fairly unstable. The Service Catalog community is discussing moving to CRDs, which will probably delay the stable release even further as it will require almost a full rewrite. However, this will be beneficial in the long term as Kubernetes is investing more and more in CRDs and tools around those.

The different implementations of the Service Brokers, each of which is managed and owned by a different set of developers, also makes it difficult for developers to use them without having to learn each of the different brokers, with their different implementations and documentation. Some communities outside Kubernetes are creating projects with a similar goal: provide a declarative API to request and manage services outside Kubernetes. One of these projects, Crossplane, offers a common API to request services, without having to take into account the provider for that service. The developers can define their applications as requiring a type of service without needing to know which cloud is providing that service. This will be decided by the cluster administrator when deploying one or many cloud providers into the cluster.

Conclusion

The Service Catalog in Kubernetes needs to overcome some of its current limitations before being widely adopted and used safely in production. In the meantime, other projects inside and outside the Kubernetes community are being created either as complements or competitors to the Service Catalog and the Open Service Broker API.

About the Author 

Ara Pulido is an engineering manager with more than 10 years of experience working with open source companies. Currently, she manages the Kubernetes and Site Reliability Engineering (SRE) teams at Bitnami. She is a certified Kubernetes administrator.