The implementation of a LogServiceBroker in Kubernetes:
Earlier we discussed the advantage of using a Log service broker in Kubernetes (k8s) to provision a log service that sends logs to a Log index store external to the cluster. This enables log index stores to run anywhere and work independently from the cluster. This also allows the index store to serve different Kubernetes clusters. Therefore, it is a helpful addition to any Kubernetes cluster.
In this article, we describe the implementation specific of a k8s log service broker. A service broker facilitates the input to the log index store to be understood by Kubernetes as a custom resource within the cluster. This registration is maintained in the cluster-wide system catalog thereby ensuring only one active cluster-wide instance for all logs to be destined for the provisioned log index store.
This makes the broker registration as a boiler plate declaration where we define the Kubernetes resource as a “kind: ClusterServiceBroker” along with suitable labels and annotations. The specification of the resource includes an access url for the broker to receive requests and an authentication info represented by a reference to a Kubernetes secret. Any credential used along with the access url is traditionally kept safe with the notion of a Kubernetes secret. The service that is hosted for the url is also declared and allowed to run on the Kubernetes cluster with the help of an account and secured with role-based access control. All of these definitions for service, account and role-based access have standard declarations which is represented as yaml.
Having described the registration of the broker, we now look to implement the service accepting requests on the specified url. This service has a model and a controller that pretty much behaves like any other web service. The controller implements the ComposableServiceInstanceService class which describes the provisioning of a service instance and the ComposableServiceInstanceBindingService which describes the provisioning of a service binding for the service instance. Our notion of service instance and service binding translate to a service that setsup a channel for publishing logs to an external index store by making web requests to the index store while registering the callers who will supply the logs with service bindings to this instance. The model used with these services usually define the parameters and attributes accepted to make requests to these services. An application instance is setup with context as a SpringBootApplication if the services are implemented in Java.
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.
Earlier we discussed the advantage of using a Log service broker in Kubernetes (k8s) to provision a log service that sends logs to a Log index store external to the cluster. This enables log index stores to run anywhere and work independently from the cluster. This also allows the index store to serve different Kubernetes clusters. Therefore, it is a helpful addition to any Kubernetes cluster.
In this article, we describe the implementation specific of a k8s log service broker. A service broker facilitates the input to the log index store to be understood by Kubernetes as a custom resource within the cluster. This registration is maintained in the cluster-wide system catalog thereby ensuring only one active cluster-wide instance for all logs to be destined for the provisioned log index store.
This makes the broker registration as a boiler plate declaration where we define the Kubernetes resource as a “kind: ClusterServiceBroker” along with suitable labels and annotations. The specification of the resource includes an access url for the broker to receive requests and an authentication info represented by a reference to a Kubernetes secret. Any credential used along with the access url is traditionally kept safe with the notion of a Kubernetes secret. The service that is hosted for the url is also declared and allowed to run on the Kubernetes cluster with the help of an account and secured with role-based access control. All of these definitions for service, account and role-based access have standard declarations which is represented as yaml.
Having described the registration of the broker, we now look to implement the service accepting requests on the specified url. This service has a model and a controller that pretty much behaves like any other web service. The controller implements the ComposableServiceInstanceService class which describes the provisioning of a service instance and the ComposableServiceInstanceBindingService which describes the provisioning of a service binding for the service instance. Our notion of service instance and service binding translate to a service that setsup a channel for publishing logs to an external index store by making web requests to the index store while registering the callers who will supply the logs with service bindings to this instance. The model used with these services usually define the parameters and attributes accepted to make requests to these services. An application instance is setup with context as a SpringBootApplication if the services are implemented in Java.
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.
No comments:
Post a Comment