Announcing Azure Service Operator for Kubernetes

Today, we’re announcing Azure Service Operator―an open source project we’ve been working on in collaboration with a handful of customers to expose several Microsoft Azure services as Kubernetes operators.

As we’ve seen Kubernetes adoption grow exponentially, we’ve also seen an increasing desire from customers to manage their resources exclusively through the Kubernetes control plane. Kubernetes operators make Azure services easily accessible from Kubernetes clusters in any cloud and allow developers to focus more on their applications and less on their infrastructure.

Azure Service Operator allows users to dynamically provision infrastructure, which enables developers to self-provision infrastructure or include Azure Service Operator in their pipelines. They can run anywhere Kubernetes runs―public, private, hybrid, multi-cloud, and on-premises. And for customers new to Azure or those betting on a multi-cloud strategy, Azure Service Operator abstracts the Azure-specific knowledge, so users can focus on developing with the language they’re familiar with―Kubernetes YAML.

As a part of Azure Service Operator, we’ve built a handful of Kubernetes operators for Azure services, including EventHub, Azure SQL, CosmosDB, Storage Accounts, and more. The project consists of two parts―the custom resource definitions (CRDs) for each of the supported Azure services and the Kubernetes controller that watches for requests to create Custom Resources for each of these CRDs and manages them accordingly.

Deploying Azure Service Operator: How it works

In the development of this project, we’ve also created a generic controller that helps develop new operators for Azure services currently not covered by the project.

With the launch of the Azure Service Operators project, we will no longer be maintaining the Open Service Broker for Azure (OSBA). OSBA was an experimental project that similarly enabled customers to provision and bind Azure services to their Kubernetes cluster by leveraging the Open Service Broker API by Cloud Foundry. As we’ve seen momentum shifting from Open Service Broker to operators, we have decided to shift and consolidate our investments to support Azure services through operators instead, to provide more robust support and functionality for users.

Check out more details on how to get started in the project repository here.

Other feedback or questions? Let us know in the comments below.

Sakthi Vetrivel

Program Manager, Azure Kubernetes Service

See more articles from this author