Azure Service Operator  

Introduction: In the previous article, we discussed Kubernetes Open Service Broker API. We followed it up on the discussion with an introduction to Azure OSBA which is also complying with the open standard. This article is about the Azure Service Operator.  

Description: Azure Service Operator is an open-source project that exposes Azure Services as Kubernetes operators. Exposing Azure Resources on the Kubernetes control plane is desirable for several reasons and if the exponential growth in popularity of the Kubernetes infrastructure is any indication, then those reasons must hold. Azure resources are also managed in the cloud via the Azure resource manager so the concepts of resource manifest and state reconciliation are similar. Kubernetes is a portable, extensible, open-source platform for managing containerized workloads and services. It is often a strategic decision for any company because it decouples the application from the hosts so that the same application can work elsewhere with minimal disruption to its use.   

An operator is a way of automating the deployment of an application on the Kubernetes cluster. It is written with the help of template source code generated by a tool called the operator-SDK. The tool builds three components – custom resources, APIs, and controllers. The custom resources are usually the declarative definitions of Kubernetes resources required by the application and its grouping as suited for the deployment of the application. The api is for the custom service required to deploy the application and the controller watches for this service.  
Kubernetes does not limit the type of applications that are supported. It provides building blocks to the application. Containers only help isolate modules of the application into well-defined boundaries that can run in with operating system-level virtualization.  
Kubernetes exposes a set of APIs that are used internally by the command line tool called kubectl. It is also used externally by other applications. This API follows the regular REST convention and is also versioned with path qualifiers such as v1, v1alpha1, or v1beta1 – the latter is used with extensions to the APIs.  
Kubernetes supports Imperative commands, imperative object configuration, and declarative object configuration. These are different approaches to manage objects. The first approach operates on live objects and is recommended for a development environment. The latter two are configurations that operate on individual files or a set of files and these are better suited for production environments.  
Namespaces seclude names of resources. They can even be nested within one another. They provide a means to divide resources between multiple users.  
Most Kubernetes resources such as pods, services, replication, controllers, and others are in some namespaces. However, low-level resources such as nodes and persistent volumes are not in any namespace.  
Kubernetes control plane communication is bidirectional between the cluster to its master and vice-versa. The master hosts an API server that is configured to listen for remote connections. The API server reaches out to the kubelets to fetch logs, attach to running pods, and provide the port-forwarding functionality. The API server manages nodes, pods, and services.   

When Azure resources are exposed on the Kubernetes control plane, we have all the advantages of continuous state reconciliation, networking best practices, and application portability across hosts, environments, and clouds. Azure provides some of the best backend services for an application but instead of managing them directly, an application can delegate its management to the Kubernetes control plane.  

  
Conclusion: The Azure OSBA expands the service catalog and enabled Azure resources to be recognized as Kubernetes custom resources. Azure Service operators take it a step forward and enable the resources to be managed via the Kubernetes control plane.