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.
| Name | Required | Type | Description |
|---|---|---|---|
| clusterID | true | 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 | true | 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 | false | 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 | false | string | 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. |
| Code | Description | Example |
|---|---|---|
| 200 | OK |
|
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:
read -r -d '' WL << EndOfMessage
apiVersion: apps/v1
kind: Deployment
metadata:
name: kubecost-cost-analyzer
namespace: kubecost
labels:
app: kubecost-cost-analyzer
spec:
replicas: 3
selector:
matchLabels:
app: kubecost-cost-analyzer
template:
metadata:
labels:
app: kubecost-cost-analyzer
spec:
containers:
- name: cost-model
image: nginx:1.14.2
resources:
requests:
cpu: "1m"
memory: "1Mi"
- name: cost-analyzer-frontend
image: nginx:1.14.2
resources:
requests:
cpu: "1m"
memory: "1Mi"
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: default-deployment
labels:
app: default-deployment
spec:
replicas: 3
selector:
matchLabels:
app: default-deployment
template:
metadata:
labels:
app: default-deployment
spec:
containers:
- name: container-1
image: nginx:1.14.2
resources:
requests:
cpu: "10m"
memory: "10Mi"
EndOfMessage
echo "${WL}" > /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 be0if the deployment is not currently running. -
costAfter: The monthly cost after the change is applied. -
costChange: The difference between the values ofcostBeforeandcostAfter. If the value ofcostBeforewas0, thencostChangeshould be equal tocostAfter.
Observe how defaultNamespace impacts the default-deployment workload.
From that output, costChangenotices 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.