apiVersion: keda.sh/v1alpha1
kind: KedaController
metadata:
name: keda
namespace: keda
spec:
## Namespace that should be watched by KEDA Controller,
# omit or set empty to watch all namespaces (default setting)
watchNamespace: ""
## Logging level for KEDA Operator
# allowed values: 'debug', 'info', 'error', or an integer value greater than 0, specified as string
# default value: info
logLevel: info
## Logging format for KEDA Operator
# allowed values are json and console
# default value: console
logEncoder: console
## Logging level for Metrics Server
# allowed values: "0" for info, "4" for debug, or an integer value greater than 0, specified as string
# default value: "0"
logLevelMetrics: "0"
## Node selector for pod scheduling - both KEDA Operator and Metrics Server
# https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/
nodeSelector:
beta.kubernetes.io/os: linux
...
It would be better from UX point of veiw to refactor it to contain separate sections for operator and metricsServer, something like this:
apiVersion: keda.sh/v1alpha1
kind: KedaController
metadata:
name: keda
namespace: keda
spec:
## Namespace that should be watched by KEDA Controller,
# omit or set empty to watch all namespaces (default setting)
watchNamespace: ""
## KEDA Operator related config:
operator:
logLevel: info
logEncoder: console
nodeSelector:
beta.kubernetes.io/os: linux
## KEDA Metrics Server related config:
metricsServer:
logLevel: "0"
nodeSelector:
beta.kubernetes.io/os: linux
...
This way we can add a similar section for serviceAccount or any other resources.
To make the breaking change pleasant for users, temporarily we can support both options, with a warning message printed if a deprecated field is being used.
Currently the CR looks like this:
It would be better from UX point of veiw to refactor it to contain separate sections for
operator
andmetricsServer
, something like this:This way we can add a similar section for
serviceAccount
or any other resources.To make the breaking change pleasant for users, temporarily we can support both options, with a warning message printed if a deprecated field is being used.