This commit adds two new collectors to the adapter:
- ClusterScalingScheduleCollector; and
- ScalingScheduleCollector
Also, it introduces the required collectors plugins, initialization
logic in the server startup, documentation and deployment example
(including the helm chart). A new config flag is created,
`-scaling-schedule`, and allows to enable and to disable the collection
of such metrics. It's disabled by default.
This collectors are the required logic to utilise the CRDs introduced in
the #284 pull request. It makes use of the kubernetes go-client
implementations of a [Store][0] and [Reflector][1].
[0]: https://pkg.go.dev/k8s.io/client-go/tools/cache#Store
[1]: https://pkg.go.dev/k8s.io/client-go/tools/cache#Reflector
Signed-off-by: Jonathan Juares Beber <jonathanbeber@gmail.com>
Testing indicates that metrics API v1beta2 is not a suitable drop-in replacement for v1beta1, and v1 does not exist at this time.
Signed-off-by: Henry Agnew <henryd.agnew@gmail.com>
Some cases and users actually know when their applications will have a
high workload and, therefore, autoscaling support for time based scaling
is a desired feature.
This commit creates the first version of two CRDs called
`ScalingSchedule` and `ClusterScalingSchedule`.
The CRDs describe one or multiples schedules inside them. The schedules
contains the information of when the time based scaling starts, if it
happens once or multiple times, its duration and, a configurable value
that later can be used by HPAs to scale applications.
The only difference between the two CRDs is their scope.
`ClusterScalingSchedule` aims to attend cluster wide schedules, to
multiple applications, while `ScalingSchedule` has to be deployed with
each application into the same namespace.
This commit does not creates any metric, it's a noop change that creates
just the CRD and import tools required to generate the CRD and others
required code, as `deepCopy` functions and clients.
Signed-off-by: Jonathan Juares Beber <jonathanbeber@gmail.com>
