-
Spike
-
Resolution: Done
-
Undefined
-
None
-
None
-
None
-
None
-
False
-
None
-
False
-
No
-
MGDSRVS-145 - RHOSAK Enterprise Plan: RHOSAK on customer-owned OSD/ROSA/ARO
-
---
-
---
-
-
-
MK - Sprint 235
The high level goal would be:
- We would use existing or create metrics for the number (or existence) of managedkafkas total and by strimzi version. Something similar could be needed for RHOC.
- The FSO and each strimzi deployment would have a HPA with a min of 0.
- The respective HPA would scale to 1 or 2 as the max given the presence of a managedkafka, or a resource using the given kafka version.
There are actually two approaches to custom metrics, both are backed by prometheus:
1. Starting with openshift 4.11, there's KEDA - https://cloud.redhat.com/blog/custom-metrics-autoscaler-on-openshift
- this does not appear to be installed by default on our instances, the ScaledObject custom type and operator are not there. However this looks like it can integrate directly with the prometheus instance.
2. The built-in kuberentes HPA support that is available via autoscaling/v2 https://access.redhat.com/documentation/en-us/openshift_container_platform/4.7/html/monitoring/exposing-custom-application-metrics-for-autoscaling
- In this case the openshift-monitoring prometheous does have the adapter installed, so it is presumably serving the resource metrics from the metrics api endpoint. However the adapter is not installed for the managed application services prometheous. Presumably it would need to be along with the appropriate ConfigMap defining the metrics, and the necessary Service and ServiceAccounts for access.