We were discussing the use of a log service broker in Kubernetes. Although any log index store can suffice, a specific log index store may make web registrations a breeze while providing the ability to view eye-candy charts and graphs with the analysis made over the logs. A log store may also offer full-service for the logs such that the automation to send alerts and notifications based on queries over the logs, may not require any code. 

Some of the public clouds also facilitate the use of their services by providing their respective service brokers in the cloud. This enables the public cloud services to use which expand well beyond the cluster. 

The Service broker implements the Open Service Broker API specification for consistency and implementing best practice so that the individual development teams are not left to do it on their own. A typical example of a public cloud service broker usage is one where an S3 bucket is provisioned and connected to the Kubernetes application.  This example allows data to be stored in the public cloud with the concerns alleviated from the Kubernetes cluster.  

Whether a log index store or a native S3 bucket is provisioned with a service broker, the code for the broker provisioning that instance is more or less similar and makes use of web requests to external service providers. These examples from public cloud are open source so it is easy to follow the layout for a custom implementation. Connectivity is a necessary requirement for the service broker. 

When the log index store is provisioned on a Splunk instance, the REST APIs to create and secure the log index store are easier and at the same time has options to control every aspect of the log indexing. The search operators can also make extended use of the inferred properties as well as the metadata for the logs