Make a Helm Chart

[kinoute]

Hello,

First, thanks for your work! It's nice to see this feature available outside the Kubernetes "feature gates". Is there any chance to release a Helm chart properly to install it? I think it is missing some GitHub Pages to be able to easily add the repo to helm and install the chart.

Thanks in advance!

[kinoute]

I was able to install it by cloning the repo locally but some things I struggled with:

• The repo doesn't build a Docker image, therefore, when deployed, the image key contains only the tag (taken from Charts.yaml, like :0.10.14)
• I can't make it work when running in the cluster, the only way to make it work is by running it locally and using a kubeconfig to the remote server like go run ./cmd --kube-config dev.yaml --hpa-selector "" --development-mode=true. Otherwise it complains about kubeconfig or master flag not passed to the CLI (doesn't change a thing)
• I had trouble to make it work due to the custom.metrics.k8s.io API version not being installed apparently in my cluster. This is weird since I have external metrics, prometheus adapter & v1beta1.metrics.k8s.io installed. For now, I commented everything related to custom metrics in the Go code
• There is a lot of scaling down/scaling up of my deployments without any activity detected
• Could we respect the stabilizationWindow (or equivalent) to avoid flapping?

Thanks a lot!

[novak-oleksandr]

hey @kinoute, thanks for bringing this up.

Right now, we (as an organization) don't expose any public OCI repositories to host those artifacts, so not publishing ready-to-use artifacts was a deliberate decision. We do publish dockerfile and helm chart tho, so building everything is expected to be pretty straightforward (but you will have to store and manage those artifacts by yourself)

I can't make it work when running in the cluster

are there any errors? when kube-config is not provided - it will default to "inClusterConfig" mode to use service account from the chart. If the service account from this chart doesn't work for you - you can disable it and use your own service account here

had trouble making it work due to the custom.metrics.k8s.io

oh, I recall we had problems with this too. because of the nature of this endpoint - we can not assume that it exists, and have to discover it instead. In turn, this means that running this "discovery" procedure while prometheus-adaptor is temporarily unavailable (for example, got OOMed or not-yet-installed because of unexpected problems during cluster spinup) will lead to a situation with no custom metric endpoint discovered. In turn, scale-to-zero will pretend to work, but will keep throwing "no such endpoint" error on every attempt to check custom metrics.

when this problem was noticed - the decision was made to add an explicit check to ensure that the custom metrics endpoint exists. Here is the exact place where we do this check

can you verify that your prometheus adapter is healthy and available?

There is a lot of scaling down/scaling up of my deployments without any activity detected

hm.. this service was designed to scale things only when we are absolutely sure that scaling is required (i.e all metrics available and all metrics are 0/at least one metric is not 0). moreover, there is a strict separation between "no such metric" and"metric is 0" (which doesn't work nicely with external metrics from some sources). can you describe your scaling configuration a little bit more?

Could we respect the stabilizationWindow (or equivalent) to avoid flapping?

ugh... Yeah, right now we don't respect it, thanks for pointing this up. It's definitely worth at least to track this as a known issue
has been added in 0.12.0 by @andriyvasylyna