Spec Cost Prediction API
Predict API
POST
http://<your-kubecost-address>/model/prediction/speccost
The Predict API takes Kubernetes API objects ("workloads") as input and produces a cost impact prediction for them, including a diff if a matching existing workload can be found in the cluster.
Query Parameters
clusterID*
string
The Kubecost cluster ID of the cluster in which the workloads will be deployed. Currently, this must be the same as the cluster ID of the Kubecost installation which is serving the /speccost
endpoint. Support for multi-cluster is planned.
defaultNamespace*
string
The namespace in which namespace-scoped objects will be "deployed" to if no namespace is set in the standard metadata field of the object.
window
string
Duration of time over which to query. Accepts multiple different formats of time (see this Using the window
parameter section for more info). Default value is 2d
.
noUsage
boolean
Set to true
to ignore historical usage data (if it exists) when making the prediction. This is equivalent to making a prediction using only requests.
The API requires that workloads be passed in the request body in YAML or JSON format. If using YAML, multiple workloads can be passed via separation with the standard ---
syntax. If using JSON, multiple workloads can be passed via the standard "list" format used by Kubernetes (e.g. kubectl get deployment -A -o json
).
Currently supported workload types:
Deployments
StatefulSets
Pods
Example
Write some Kubernetes specs to a file called /tmp/testspecs.yaml
:
Call the endpoint with cURL, passing the file in the request body:
The output will be broken down into three primary categories:
costBefore
: Represents the current monthly cost. This will be0
if the deployment is not currently running.costAfter
: The monthly cost after the change is applied.costChange
: The difference between the values ofcostBefore
andcostAfter
. If the value ofcostBefore
was0
, thencostChange
should be equal tocostAfter
.
Observe how defaultNamespace
impacts the default-deployment
workload.
From that output, costChange
notices the existing kubecost-cost-analyzer
deployment in the kubecost
namespace and is producing an estimated negative cost difference because the request is being reduced. However, because historical usage is also factored in, there is no drastic cost reduction that might be initially expected from a 1m
CPU and 1Mi
memory request.
For how to use the predictions API in a use case preventing cost overruns before they occur, see the guide here.
Use cases
For an example use case on how to use predictions to achieve proactive cost control, see here.
Last updated