Add OpenCost support, make service port and /allocation path configurable

[michaelmdresser]

What does this PR change?

Adds support for OpenCost by making service name and allocation path configurable and by allowing currency code determination to fail gracefully (defaulting to empty string + a warning log) because OpenCost does not currently and is not guaranteed to provide a /getConfigs endpoint.

Does this PR rely on any other PRs?

• Branched off of Refactor some commands to reduce code duplication #116 (this PR will be rebased after that is merged)

How does this PR impact users? (This is the kind of thing that goes in release notes!)

• Adds support for OpenCost by introducing the new flags --allocation-path and --service-port

How was this PR tested?

Locally by using the new flags to cause an expected query failure.

Tested with OpenCost by updating my Kubecost installation to use an OpenCost-only image:

kubectl set image \
    --namespace kubecost \
    deployment/kubecost-cost-analyzer \
    cost-model="XYZ/opencost:test" # filler, I pushed an image built from kubecost/opencost@develop

For OpenCost to work in this deployment model, I had to set --allocation-path "/model/allocation/compute". I got a valid response with the expected lack of currency code information.

→ go run cmd/kubectl-cost/kubectl-cost.go namespace --allocation-path "/model/allocation/compute"
2022-06-15T16:21:47.303063842-04:00 ??? Log level set to info
+-------------+--------------------+--------------------+-----------------+
| CLUSTER     | NAMESPACE          | MONTHLY RATE (ALL) | COST EFFICIENCY |
+-------------+--------------------+--------------------+-----------------+
| cluster-one | resource-usage     |          95.005191 |        0.568842 |
|             | kube-system        |          28.342138 |        0.067743 |
|             | kubecost           |          20.188082 |        2.110994 |
|             | over-request       |          18.819788 |        0.000132 |
|             | guestbook          |           1.378470 |        0.097483 |
|             | guestbook-with-pdb |           1.288721 |        0.125827 |
+-------------+--------------------+--------------------+-----------------+
| SUMMED      |                    |         165.022389 |                 |
+-------------+--------------------+--------------------+-----------------+

Setting --log-level debug surfaces the "failed to get currency code" message, as expected.

Have you made an update to documentation?

Yes, see README updates.

[michaelmdresser]

@jessegoodier sorry to give you the run-around. This is the PR that should give us OpenCost support once merged.

[nikovacevic]

Let me know what you think about the Allocation API endpoint — I may not be grasping something. If that is so, then this is good to go.

[nikovacevic]

This will definitely work, but is (of course) not the nicest UX. Have we exhausted our options for getting these to match between OS and CS?

Ever since we restructured the cmd entry-points, I think we've been able to add endpoints in the OS that only exist there, right? (Before we had to give weird endpoint names to avoid router collisions, which panic.) So can we add /model/allocation to the OS (same behavior as existing /model/allocation/compute) and unify the endpoint?

[michaelmdresser]

I think we could add /allocation == /allocation/compute to OpenCost, but there are some wrinkles even then. /allocation exists in OpenCost and Kubecost, but Kubecost has /model/ in front of everything because of the proxy. We get in sort of a weird situation if we try to fix this:

• pure OSS usage (no Helm chart, no Kubecost frontend container) has an API at /allocation/compute. Adding /model/ in front of all OpenCost API paths works, you end up with /model/allocation/compute
• but then if you deploy OpenCost inside the Kubecost Helm chart, you currently get /model/allocation/compute. If you add /model/ in front of all OpenCost API paths, you end up with /model/model/allocation/compute

(The above is also true if you s|/allocation/compute|/allocation/g)

That is to say, I think unifying the endpoint in OpenCost (/allocation = /allocation/compute) is a good idea! But I also think that this new flag may be necessary regardless.

[nikovacevic]

Given that we can now attach endpoints in OpenCost (i.e. in pkg/cmd/costmodel/costmodel.go in func Execute) I was imagining putting /model/allocation there. Then in Kubecost, we'd still have /allocation, which thanks to nginx gets nested into /model/allocation. And thus, each will just have /model/allocation, no? And there won't be a /model/model/allocation because that cmd doesn't get executed in the closed source. Or am I misunderstanding?

[nikovacevic]

Discussed out of band.