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 use kubectl cost to get cost information because the CLI currently supports two query modes: port-forward and proxy, both of which require cluster access:
|
if p.UseProxy { |
|
clientset, err := kubernetes.NewForConfig(p.RestConfig) |
|
if err != nil { |
|
return nil, fmt.Errorf("failed to create clientset for proxied query: %s", err) |
|
} |
|
|
|
bytes, err = clientset.CoreV1().Services(p.KubecostNamespace).ProxyGet("", p.ServiceName, fmt.Sprint(p.ServicePort), p.AllocationPath, p.QueryParams).DoRaw(p.Ctx) |
|
if err != nil { |
|
return nil, fmt.Errorf("failed to proxy get kubecost. err: %s; data: %s", err, bytes) |
|
} |
|
} else { |
|
bytes, err = portForwardedQueryService(p.RestConfig, p.KubecostNamespace, p.ServiceName, p.AllocationPath, p.ServicePort, p.QueryParams, p.Ctx) |
|
if err != nil { |
|
return nil, fmt.Errorf("failed to port forward query: %s", err) |
|
} |
|
} |
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?)
Problem
Users of Kubecost's hosted product do not have cluster/
kubectlaccess 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 costto 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
kubecostnamespace and snag the cluster ID from env vars?)