As enterprise adoption of Kubernetes is growing, we see multiple teams collaborate on a Kubernetes cluster to realize the broader organizational goals. Typically, there is one team that is offering a service that the other team is looking to consume. It can be an ISV offering a service for their data & analytics software that their customer is looking to consume or it can be a platform team offering a service for an internal application that the product team is planning to use (e.g secret management, data processing etc.). We call these teams providers and consumers in this post and discuss dynamics around their cooperation.
Provider dilemma
Typically providers have their software packaged for Kubernetes in the form of a Helm chart (optionally supported by Kubernetes Operator). Providers are looking for a way to deliver their software as-a-service to the consumers. They are looking to offer an easy interface for consumers to provision the software and also are looking to govern and monitor it behind the scene.
High level provider needs are:
- Consumer API that allows them to expose only minimum set of parameters that they want consumers to control
- Ability to troubleshoot and monitor the application instance
- Ability to track consumption of the software by different consumers
Helm charts as-a-service
KubePlus has been developed to address these provider requirements. KubePlus takes any application Helm chart and delivers it as-a-service by abstracting it under provider and consumer APIs.
Using the provider API, the provider team creates a new Kubernetes-style API (CRD / Custom Resource Definition) to register an application Helm chart. The new CRD is essentially the consumer API which the application consumers use to provision / instantiate the registered Helm chart in a self-service manner. As part of the Helm chart registration step, the provider team can define policies that should be applied to every instantiation of the registered chart. These include — how much cpu/memory should be given to the Pods in an application instance, which consumption metrics should be tracked, and isolation policies for multi-tenancy etc. KubePlus generates provider and consumer kubeconfig files with RBAC permissions scoped to the provider and consumer APIs.
KubePlus brings following advantages to provider teams:
- API-based access to Helm charts on a cluster.
- Seamless support for Namespace-based multi-tenancy where each application instance (Helm release) can be deployed in a separate namespace.
- Monitoring of application instances.
- Tracking consumption metrics (cpu, memory, storage and network) at Helm release / application instance level. (Providers can use these metrics to define consumption-based chargeback model).
Our KubePlus SaaS Manager product leverages this open source KubePlus tool and offers providers the ability to distribute their SaaS on multiple Kubernetes clusters and manage it from a central location. Number of ISVs are looking at KubePlus today to distribute their software on any Kubernetes cluster on-prem, at edge or on any public cloud. To learn more visit — https://cloudark.io/, KubePlus GitHub: https://github.com/cloud-ark/kubeplus.
