The Banzai Cloud Cloudinfo service retrieves product and pricing information from cloud providers and exposes it through a RESTful API, and UI. Our Kubernetes based Pipeline platform and Telescopes recommendation engine make use of this information when they advise users on cluster layout and resourcing.
Here’s a quick primer of how and why we utilize the Cloudinfo service:
- Pipeline platform users have the option of launching clusters or deploying applications based only on resource- and SLA-requirements (price, IO, memory, CPU, GPU, etc.)
- Telescopes turns these resource requirements into Kubernetes cluster layout recommendations
- The Cloudinfo service supplies information on available cloud resources and cost, and other relevant metadata.
- Hollowtrees ensures that SLAs are met even if a cluster contains spot or preemptible instances. When necessary, machine instances are automatically replaced with ones with better cost or stability scores.
- Pipeline collects all relevant information and applies it to pod autoscalers using the Banzai Cloud Kubernetes operators.
As providers continuously improve their products and introduce new services, our product information needs to keep track of changes and provide information as accurately as possible. Having experimented with those cloud providers supported by Pipeline, we found that the accuracy of the data in Cloudinfo varied significantly between providers.
On AWS, for instance, Kubernetes support is being made available gradually, on a per region basis. On other providers, this may only be done on specific machines. Still more providers may enable the service on all regions and all instance types at the same time. For this reason Cloudinfo needs to understand the strategies of various providers, so that it can help Telescopes correctly recommend the node pools available in a requested region.
To address the above problems and to enrich the information that we expose through Cloudinfo, we enhanced the way we handle and categorize information retrieved from providers. This post presents a variety of approaches. Some of these are works in progress, others are being tested and will be available soon (if that piques your interest, you can always check our GitHub repository and try our code yourself).
Support for services 🔗︎
First, we introduced the notion of services,. The default service for every provider is the compute service. Other cloud provider specific services that are currently being implemented are:
- AWS: compute, eks
- AZURE: aks
Service-dependent product information consists of region, instance (machine) type and pricing. When recommending Kubernetes cluster layouts for a cloud provider, there may be an additional - usually fixed - service fee added to the overall cluster price. Responses returned by the Cloudinfo service will be decorated with service specific information to further help clients. Note that while the service framework is already present, the specific implementation of service support is still a work in progress.
Changed the REST URL scheme 🔗︎
We updated our API to to be more intuitive and extensible as part of our effort to provide further support for services.
The URL scheme for Productservice endpoints looks like this:
1http://[pi-host]:[pi-port]/api/v1/providers/:provider/services/:service/regions/:region/productsFor example, providers can be retrieved with the command:
1curl -L -X GET 'http://localhost:9090/api/v1/providers' | jq .The response should look like this:
1{
2 "providers": [
3 {
4 "provider": "ec2",
5 "services": [
6 {
7 "service": "compute"
8 },
9 {
10 "service": "eks"
11 }
12 ]
13 }
14 ]
15}As you can see, cloud providers expose information about themselves, namely what services they support. Other resources can also be addressed in the request path; services, regions and products also yield useful information for clients.
If you’d like to learn more about Banzai Cloud check out our other posts on this blog, the Pipeline, Hollowtrees and Bank-Vaults projects.
