-
Notifications
You must be signed in to change notification settings - Fork 60
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Introduce a pure-HTTP (no K8s client) query mode for use when only API access is available (e.g. Kubecost Cloud) #128
Comments
@Adam-Stack-PM FYI. This is a feature request from a hosted customer. |
@michaelmdresser, Thanks. I have added the hosted label and will get this considered for an upcoming release cycle. If you want to help move this forward, it would be great if you could add a rough time estimate. |
2 days of my time due to familiarity. 3-4 days of someone else's time, in case it gets tricky. |
|
@teevans @kwombach12 what do you think about prioritizing this soon? With the launch of KC Cloud beta, I suspect this will be an increasingly-important ask. |
@michaelmdresser I like this idea. Lets take a look at this in 105. |
I've had similar requests for authentication on OpenCost APIs so they could be exposed similarly. |
Another user ask for this feature: |
We need same feature. |
@debMan thanks for bumping this! We are actively looking at solutions here |
Problem
Users of Kubecost's hosted product do not have cluster/
kubectl
access to the cluster in which the primary Kubecost instance is running, because Kubecost is hosting that in our internal infrastructure. This means they cannot usekubectl cost
to get cost information because the CLI currently supports two query modes: port-forward and proxy, both of which require cluster access:kubectl-cost/pkg/query/allocation.go
Lines 35 to 50 in dc741c5
Proposed solution
Implement a new query mode
http
(on top of the current proxy and port-forward) that sends requests directly to a Kubecost HTTP API endpoint without using a K8s client to execute the request.Possible additions
It would be amazing (though probably difficult) to somehow tie the current cluster in the user's Kubeconfig to a cluster ID in Kubecost, enabling intelligent filtering of Kubecost data based on the current Kubeconfig context. This is a step 2 for this request, unless it turns out to be simple. (perhaps we could see if there is a
kubecost
namespace and snag the cluster ID from env vars?)The text was updated successfully, but these errors were encountered: