An essay on a message broker for Kubernetes:

Kubernetes is an open-source cluster manager that is developed by Google and donated to Cloud Native Compute Foundation. Kubernetes provides automation for deployment scaling management of containerized applications. It does with the help of activities on a cluster pertaining to state convergence, service addresses, health monitoring, service discovery and DNS resolution.

One of the central themes of any automation is the ability to run the same activities over and over again for different state and resources. Much automation chose the option to make all the resources declared in succinct text format and allowing the operations to reconcile these resources to a given state. Kubernetes leverages these concepts to the point where all the needs for the applications as described as resources. Then the application can scale out by repeating this across the cluster members.

Clusters comprise of pods that have bare essentials to run the containers for their respective workloads from the applications they host. These pods are typically shallow, light weight and facilitate scale-out with the help of statefulsets and replicasets.

This worked very well to containerize and isolate applications so that they can be hosted anywhere and still perform well for large workloads with little or no disruption. However, established cloud and on- premise integration was essential for bridging the old with the new.

A service broker helped bridge the gap by representing a gateway to all external services. These services conformed to a Open Service Broker API standard that let external services be represented as internal resources so that they could be instantiated and commissioned as per cluster resources.

The point of all this integration was to enable Kubernetes to expand its reach and audience. This is witnessed by the popularity of Kubernetes where the participants to the conferences on Kubernetes increased by orders of magnitude in a few years.

Storage on the other hand has always been preferred local because as the data makes its way to storage tier, it tends to gravitate and become dense and stationary, aging over time. Pods in Kubernetes shared data by relying on file storage that was mounted as local file shares in each and every pod. If the storage were to be web accessible, a storage service was provisioned via the service broker.

Yet the Kubernetes ecosystem also benefits with the same notions of compute, storage and networking that has facilitated the world outside and is equally receptive to them as applications to be hosted on its pods. A message broker, for instance, makes the case for tapping networking to streamline the data access patterns suitable for dedicated storage.

A message broker is not a new innovation for Kubernetes but the ability to designate a class of workloads specific to message broker for the purposes of removing reliance on file-system and connecting various storage tiers is an improvement to this ecosystem. Up to this point, the jargon for Kubernetes involved general purpose definitions but some special purpose designations can improve the automation capabilities of Kubernetes that expand the backend dependencies of this framework. This essay is therefore a window to a new world of possibilities where products participate not just via a

service broker sending traffic that is not necessarily regulated, conforming, dedicated or even channeled. A message broker can bring class level quality of service and various capabilities specific to networking that improves the utilization of existing storage tier products.