Last month Usage for chargeback ( internal billing )

[NM4]

Hello,

Is there a way to get last month data for CPU, RAM and disk in term of usage or request ?

I'm wondering to use kubectl-cost with Kubecost core model to do that but for now, I don't found a way to pass information about the window range with a start and end date. Something like :

Kubectl cost --historical --start-date xxx --end-date yyy

[michaelmdresser]

Hi @NM4, this is absolutely doable and I think it's a great idea. I'll see what I can do.

[michaelmdresser]

The window flag is equivalent to the window parameter for the official APIs. I have a PR #61 now open to improve the documentation on that front.

For your specific use case, you can try --window lastmonth or, for a custom range, --window 2021-01-02T15:04:05Z,2021-02-02T15:04:05Z (see API docs).

Does that help?

[NM4]

Oh yes thank you !

Sorry I tried with last-month instead of lastmonth.

So you confirm that kubectl cost namespace --historical --windows -Agives me the cost per namespace for the last month. Right ?

In other hand, is this based on requests or real resource consumption ?

[michaelmdresser]

If you make that --window lastmonth, yes, that's correct.

This data is based on real resource consumption, which we calculate as the maximum of requests and actual usage. We have a small section in the main repo's FAQ that explains this in brief. We also have explanations of the metrics we emit (which the APIs are based on) here.

[dwbrown2]

@NM4 did that suggestion give you what you need?

@michaelmdresser i can see about updating docs if so!

[NM4]

Absolutely Yes.
Thanks for your help.

[michaelmdresser]

Glad I could help out.

@dwbrown2 I'm going to close this because #61 (which provides what I hope is a clear path to understand window) is merged.

[dwbrown2]

Sounds good, @NM4 any other valuable features that we can look at adding for you?!

[NM4]

I'm looking for the cost per namespace as asked in this thread but additionally with a label attached to namespaces that should be charge backed to teams. Something like a label "tobill=yes" that give this information.

[dwbrown2]

@NM4 we would be able to aggregate by namespace label. We apply all namespace labels to any workload running in that namespace. Example uses would be something like these:

kubectl cost label -l app
kubectl cost label -l tobill

Does that meet you need or are you looking to do something else?

[NM4]

yes something like that but with cost aggregated by namespace and only the namespaces that has the label are returned

kubectl create ns team1
kubectl label ns team1 tobill=true
....

kubectl cost namespace --historical --windows lastmonth --label tobill=true

[dwbrown2]

Ok, cool, this sounds like our concept of filtering! This is available in the backing API that the plugin uses. We would just want to think through the best way to expose on kubectl. Something like this seems to make sense to me?

kubectl cost namespace --field-filter namespace=X,label.tobill=true

Modeling after field selector syntax -- https://kubernetes.io/docs/concepts/overview/working-with-objects/field-selectors/

Let us know what you think @NM4 and @michaelmdresser! We could open a new issue if this sounds like the right direction.

[NM4]

Yes it's exactly a filtering feature.

In my case, it would be nice if the aggregated costs are displayed by namespace ( by default all namespaces that has the label)

[michaelmdresser]

I absolutely like this idea. As for the specific case (only displaying namespaces that have a certain label) I don't believe the backing Kubecost APIs actually support this, unless @dwbrown2 knows differently. We can do other kinds of filtering, like if you have a list of namespaces that you want to view a subset of:

I could imagine a world where you use a regular kubectl command to generate a list of namespaces you want to see cost data for based on the label, then you can pass that list to kubectl cost. Something like

kubectl cost namespace --whitelist $(kubectl get ns -l ns-label=value -o CSV)

AFAIK, -o CSV isn't real, but it gets the idea across I hope.

If that sounds like a good idea, I've opened #65 where we can continue discussion.