Open zroubalik opened 4 years ago
It's already documented: https://keda.sh/docs/2.12/faq/#kubernetes
I meant the coexistence with Datadog as mentioned in the quoted https://github.com/kedacore/keda/issues/470#issuecomment-1849759836
ah, okey. It could be, but I'm not 100% sure if we haven't written it yet
Any updates here? It has been almost 4 years. I encountered this issue (APIService already exists) in my GKE with Google-Managed Prometheus and custom-metric-stackdriver.
Error: Unable to continue with install: APIService "v1beta1.external.metrics.k8s.io" in namespace "" exists and cannot be imported into the current release: invalid ownership metadata; label validation error: missing key "app.kubernetes.io/managed-by": must be set to "Helm"; annotation validation error: missing key "meta.helm.sh/release-name": must be set to "keda"; annotation validation error: missing key "meta.helm.sh/release-namespace": must be set to "keda"
We are still blocked by Kubernetes upstream
KEDA is using metrics adapter based on custom-metrics-apiserver library. As part of the deployment, user need to specify cluster wide
APIService
object namedv1beta1.external.metrics.k8s.io
, see in the library example and in KEDA deployment .I wonder what would happen, if user has already deployed another Metrics Adapter (which is using the same
APIService
based approach) and we try to install Keda. It will probably replace the originalAPIService
definition with KEDA one, so KEDA will work, but the original stuff installed on cluster probably not. We should not break things or should make clear, that this could happen.We should investigate what are the possibilities and whether there are a better solutions on how to deal with the metrics. Or my assumptions are wrong, so please correct me in this case.