-
Feature
-
Resolution: Unresolved
-
Major
-
None
-
None
-
None
-
False
-
False
-
Not Selected
-
0% To Do, 0% In Progress, 100% Done
Since prometheus-adapter wasn't chosen as the project responsible for autoscaling based on custom metrics, we should move to projects that are solely focusing on the resource metrics API instead of having to support the 3 metrics API upstream. Metrics-server would be a great fit for that, it is lightweight and allows very fast autoscaling since it solely focuses on cpu/memory usage-based autoscaling. Also, one reoccurring problem with prometheus-adapter is that it is very tedious to maintain and the project would require a complete rewrite. We won't have such an issue with metrics-server since the project is very often updated and has a very active community.
Benefits:
- More lightweight
- Faster autoscaling
- Reduce the load on Prometheus
- Active community
Current limitation:
metrics-server doesn't support autoscaling on windows nodes yet. This is currently being worked on upstream as part of KEP-2371 which is an initiative driven by Red Hat.(metrics-server supports Windows since Kubernetes 1.14)- will increase kubelet CPU usage which is already alarmingly high: https://github.com/kubernetes/kubernetes/issues/104459. This would require the implementation of https://github.com/prometheus/client_golang/discussions/917 in client_golang
- blocks
-
OBSDA-242 Make Cluster Monitoring Operator optional
- To Do
- incorporates
-
MON-2085 [spike] Document pros and cons of replacing prometheus-adapter with metrics-server
- Closed
- is duplicated by
-
OBSDA-216 Replace prometheus-adapter with metric-server
- Closed
- is triggering
-
MON-3153 Switch to metrics-server
- Closed