Problem Statement: Custom resources in the public cloud can be defined with the help of an Azure Resource Manager manifest and the registration of an Azure Resource provider, usually a service hosted on Azure, to provide resources based on the manifest. This article investigates the role of an external resource provider for Azure where the service is not directly registered with the resource manager for a lookup but resolved indirectly.
Description: The use of resource and an orchestration framework to reconcile the desired state for the resource as described by its manifest to the actual state of the resource as visible to a resource manager is a control loop paradigm widely popular across infrastructure frameworks both in the enterprise and in the cloud. For example, the well-known Kubernetes is a container orchestration framework that designates a ‘Kube-controller-manager' that embeds the core control loops shipped with it. This non-terminating loop watches the shared state of the cluster through an ‘apiserver’ and makes changes to the resource to move it from its current state to the desired state declared in its manifest. Some examples of these controllers are replication controller, endpoint controller, namespace controller, and service accounts controller. The same applies to the Azure public cloud with the help of the Azure Resource Manager and the corresponding ARM templates for the resources provisioned in the cloud.
The difference is in the use of a service broker that allows implementations of the resource provisioning to exist outside the cluster or the cloud for Kubernetes and Azure respectively. Kubernetes service brokers allow the provisioning of services outside the cluster. This enables services to run anywhere and work independently from the cluster. They can even be deployed in the public and private cloud where they can scale across Kubernetes clusters. This is a helpful addition to any Kubernetes cluster.
The service broker architecture also enforces consistency across the provisioning of resources. This is done with the help of a standard set of APIs for all resources and their corresponding services that implement the service broker. Resources are the way in which Kubernetes recognizes every entity in the cluster. The framework of Kubernetes then takes this inventory of resources and reconciles the state of the cluster to match the definition of the resources. Anything hosted on the Kubernetes clusters can be described with the help of a custom resource.
Service brokers facilitate the resources provisioned by external services to be understood by Kubernetes as custom resources within the cluster. This bridging of external resource provisioning within-cluster representation of resources has provided significant benefits to users for the use of these resources.
Almost all provisioning of resources translates into well-known operations of creating, update, delete, get and list on the resources. Therefore, the resource operations are aligned with the usage of resources along with most workflows. This makes it handy for use of Kubernetes clusters for many applications and services.
The trend in cloud computing has shifted from service-oriented architecture towards microservices. This has helped the independent provisioning of resources, deployment, and scaling of services, and overhaul or reworking of services. The service broker makes no claim about how the services need to evolve - whether to form a structural composite pattern or a behavior maintaining pattern. This minimal enforcement has worked mutually beneficial for both the services as well as the Kubernetes cluster.
One example of the use of a resource with a service broker is logging. Logging, although available out-of-box with Kubernetes, can also be considered a service to be provisioned external to the cluster. This is easy to do with a variety of log products that provide service-like functionality. If there is no data loss, most log system users are tolerant to latency. This makes it easier for Logging to be implemented with merely a Kubernetes service broker and alleviating all concerns for logging from the cluster.
The same could apply to Azure if it could entertain cloud extenders for the customization of resources. Another convenience that comes with this approach is the use of a hierarchical namespace rather than the type definitions we have with Azure Resource Manager templates today.
Azure supports extensions but the extensions are not a replacement for the Open Service Broker API implementation. There is also a difference between the existing OSBA API and resolving of the namespaces by an existing Azure OSBA. This would be a service that performs like a DNS service.
Conclusion: This article discusses improvement possibilities that are not yet available in the public cloud.
No comments:
Post a Comment