Service Catalog & Open Service Broker: Extending Kubernetes Services

Introduction

At KubeCon Seattle 2016, the Kubernetes community unveiled the Service Catalog project and adopted the Open Service Broker API (OSBAPI). The goal: let clusters provision and bind to managed services (databases, queues, SaaS) using Kubernetes-native resources instead of bespoke scripts.

Core Concepts

Service Classes: Represent catalog entries exposed by a broker (e.g., “cleardb-mysql”, “pubsub”).
Plans: Different SKUs or tiers under each class (free, standard, enterprise).
Instances: Concrete provisioned services bound to a namespace via ServiceInstance resources.
Bindings: Deliver credentials to workloads through Secret objects referenced by ServiceBinding.

Architecture (2016 Incubator)

Service Catalog Controller Manager: Watches CRDs (ServiceClass, ServiceInstance, ServiceBinding) and talks to brokers over OSBAPI.
Service Brokers: HTTP endpoints implementing OSBAPI (Cloud Foundry brokers, vendors like Google, Red Hat, Pivotal).
kube-service-catalog: Prototype CLI and controllers hosted under the Kubernetes incubator org.
Integration: OSBAPI allowed existing Cloud Foundry brokers to plug into Kubernetes with minimal changes.

Example Workflow

apiVersion: servicecatalog.k8s.io/v1alpha1
kind: ServiceInstance
metadata:
  name: mysql-demo
spec:
  clusterServiceClassExternalName: cleardb-mysql
  clusterServicePlanExternalName: spark
---
apiVersion: servicecatalog.k8s.io/v1alpha1
kind: ServiceBinding
metadata:
  name: mysql-demo-binding
spec:
  instanceRef:
    name: mysql-demo
  secretName: mysql-demo-credentials

Use Cases

Managed Databases: Provision MySQL, PostgreSQL, or Redis instances provided by cloud vendors.
Messaging: Bind to RabbitMQ, Kafka, or Pub/Sub services without handcrafting credentials.
Third-Party SaaS: SendGrid, Twilio, and other API providers joined the OSB ecosystem.
Marketplace Model: Enterprises built internal marketplaces exposing curated services to application teams.

Limitations & Next Steps

Alpha Quality: API was v1alpha1; expect breaking changes.
Security: Credentials stored in Secrets—teams needed RBAC rules and secret management strategies.
Lifecycle: Deprovisioning semantics relied on brokers honoring OSBAPI contract; orphan mitigation was still manual.
Future Work: GA APIs, namespace-scoped brokers, async provisioning, and integration with Knative-style eventing.

Conclusion

Service Catalog and the Open Service Broker API signaled Kubernetes’ expansion beyond running workloads—it became a control plane for external managed services. The 2016 foundations set up marketplaces, platform teams, and operators to provide self-service infrastructure with Kubernetes-native workflows.

Table of Contents