Feature Request: kubectl cost prices

[mattray]

While kubectl cost currently shows costs for various assets, it doesn't show the source of pricing data.

/allNodePricing from https://github.com/opencost/opencost/blob/develop/pkg/costmodel/router.go#L1757 returns JSON for on-prem similar to

{
    "code": 200,
    "status": "success",
    "data": {
        "default": {
            "CPU": "10.25",
            "RAM": "3.50",
            "GPU": ""
        },
        "default,gpu": {
            "CPU": "10.25",
            "RAM": "3.50",
            "GPU": "2.95"
        },
        "default,spot": {
            "CPU": "0.6655",
            "RAM": "0.892",
            "GPU": ""
        }
    }
}

Public clouds have more complicated responses, but this would make it easier to see prices applied (and potentially customized). Even only showing On Demand pricing would be useful.

[saif-xgrid]

Please assign this issue to me

[michaelmdresser]

Hi @saif-xgrid we welcome contributions, but I'd like to understand where you're heading with the implementation before you get too deep. Would you post a brief outline?

@mattray would you elaborate on the ask a little bit? What exactly does a user want to accomplish? Do they want to see the price-per-resource of nodes in their cluster?

[mattray]

@michaelmdresser I think the data returned from /allNodePricing makes it easier to understand node costs, especially when you're overriding costs. Presentation may be a bit difficult, but I think this is an API call that would be useful from the CLI as well. Maybe this is too ambitious, given there are 16 SKUs within the JSON returned from my 4 node cluster on AWS.

@saif-xgrid if you want to do it, maybe take a look at the /addNodePricing from an AWS or other cloud deployment and provide a mock-up of output from the returned JSON.

[michaelmdresser]

Thanks for the extra detail @mattray. If using default pricing or custom pricing, I think this makes sense as a feature to get a nicely-formatted view of configured node pricing.

However, with cloud providers I'm concerned that we won't give correct data. Kubecost does best-effort guesses for node pricing for cloud providers, but the ultimate answer is always provided by the bill, which is why we have have cloud provider integrations and reconciliation. I'm not intimately familiar with the /allNodePricing endpoint, but I'm worried that we'll give a misleading response for users running on cloud providers who are not being billed default rates due to discounts, regional variation, etc.

Again, though, I'm not super familiar with the endpoint. It may account for some of these details already. Some research is required to make sure we play well with Kubecost.

@kubecost/product how can we best coordinate with an open source volunteer here? We're in a tricky spot in which closed-source Kubecost code may influence a contribution.