Damien Grisonnet

@SuperQ it was recently brought to my attention that we can't get node-level information from the kubelet `/metrics/resource` endpoint, we would have to rely on either node-exporter metrics, Prometheus k8s...

I got confused and forgot that we could rely on `node_cpu_usage_seconds_total` and `node_memory_working_set_bytes` that are coming from kubelet. Going forward that is what we will be going and it should...

There was multiple PoCs written overtime. but this issue hasn't moved much since the KEP was closed. As a path forward I would be happy to sponsor the metrics router...

Makes sense @Pluies, thank you for the feedback! :) I totally agree that Keda is a good alternative in most cases considering the sheer amount of scalers that it supports.

Sadly not, there is no easy migration process today because you can't have two different source of external metrics. The safest way today is to manually scale all the HPA...

Looking at the code from the Kubernetes library this seems to be expected: https://github.com/kubernetes/utils/blob/3b25d923346b/trace/trace.go#L202-L204 The traces are expected to be written not matter what if the request takes longer than...

We had an agreement in https://github.com/kubernetes/kubernetes/issues/115993 to make the traces log level 2. I will try to implement the fix this week.

On it. Sorry I didn't follow-up on it after we wrapped up the discussion upstream.

I lost track of this one, the PR has been up for a while, I'll try to ping some people on slack to have a look at it https://github.com/kubernetes/utils/pull/301

> I got the issue. KSM was relabelling the metric name deplEnv to label_depl_env. I am only able too see this label on metric kube_pod_labels and not on any other...