Bug was introduced trying to solved the following issue:
> When scenarios where two HPAs reference the same object but have
different metric calculation (e.g. ingresses with different weights),
kube-metrics-adapter calculates the two metrics but always overrides
one of the metrics when saving it to the store.
This commit fixes a issue where without the added `return` the system
was continuing in an invalid states where `labels2metric` wasn't
properly initialized, causing the system to panic.
Signed-off-by: Katyanna Moura <amelie.kn@gmail.com>
Having the test filename prefix exactly as the tested file name helps systems
to identify the correlation.
Signed-off-by: Katyanna Moura <amelie.kn@gmail.com>
The metrics store, both the custom and external one, make heavy usage of
maps of strings to strings. This leads to a presumable confusing or at
least hard to read codebase.
This commit tries to increase readability and maintainability of the
metric stores by using custom types. This commit has no effect in
performance or functionality, it's pure aesthetics.
Co-authored-by: Jonathan Juares Beber <jonathanbeber@gmail.com>
Signed-off-by: Katyanna Moura <amelie.kn@gmail.com>
The current implementation of the metrics store for custom metrics uses
just the object name as key. When scenarios where two HPAs reference the
same object but have different metric calculation (e.g. ingresses with
different weights), kube-metrics-adapter calculates the two metrics but
always overrides one of the metrics when saving it to the store.
This commit implements the use of a labels hash in the custom metrics
store. This way, metrics are identified not just by the referenced
object, but also by its selectors.
Co-authored-by: Katyanna Moura <amelie.kn@gmail.com>
Signed-off-by: Jonathan Juares Beber <jonathanbeber@gmail.com>
This commit upgrades all the Kubernetes dependencies to 1.21.5. It
includes regenerated clients and specs.
Signed-off-by: Jonathan Juares Beber <jonathanbeber@gmail.com>
In #371 we introduced steps to make the scaling up possible even when
the HPA forces a 10% change. The problem is that 10% might not be
sufficient for some specific scaling scenarios.
For example, a an application targeting 12 pods and using a
ScalingSchedule with the value of 10000 to achieve that, will require a
target of 833. With 10 ramp steps the 90% bucket will return a metric of
9000 and the HPA calculates (9000/833) 10.8 pods, rounding to 11 pods.
Once the metric reaches the time to return 100% it will won't be
effective, since the change of the current number of pods (11) and the
desired one (12) is less than 10%.
This commit does not try to tackle this problem completely, since the
10% rule is not fixed, might change among different clusters and is also
dependent on the value given to each ScalingSchedule. Therefore, this
commit makes the number of ramp steps configurable via the
`--scaling-schedule-ramp-steps` config flag, defaulting to 10.
Signed-off-by: Jonathan Juares Beber <jonathanbeber@gmail.com>
The HPA has a feature to do not scale up and down when the change in the
metric is less than 10%:
> We'll skip scaling if the ratio is sufficiently close to 1.0 (within a
> globally-configurable tolerance, from the
> `--horizontal-pod-autoscaler-tolerance` flag, which defaults to 0.1.
It could lead to pods scaling up to 10% less than the target for
ScalingSchedules and then not scaling to the actual value if the metric
calculated before was less than 10% of the target.
This commit uses 10 fixed buckets for scaling, this way we know the
metric returned during a scaling event is at least 10% more than a
previous one calculated during the period of ramp up. The same is valid
for the scaling down during a ramp-down
Signed-off-by: Jonathan Juares Beber <jonathanbeber@gmail.com>
this commit updates the k8s dependencies from v0.20.5 to v0.20.9. It
also bundles other dependencies updates.
Signed-off-by: Jonathan Juares Beber <jonathanbeber@gmail.com>
This commit add tests to the ZMON package when handling the key used on
the metrics query.
Signed-off-by: Jonathan Juares Beber <jonathanbeber@gmail.com>
The `Date` and `Period` fields inside the `Schedule` type of the
`[Cluster]ScalingSchedule` CRDs are optional, but in its current
configuration the generated clients can't update or create these
resources since the empty fields do not pass the validation.
This commit updates the `[Cluster]ScalingSchedule.Schedule[*]` `Date`
and `Period` field to pointers, this way a null value is not validated
and the clients are able to update and create resources. It also updates
the collector code and tests to reflect the change.
Signed-off-by: Jonathan Juares Beber <jonathanbeber@gmail.com>
This commit removes the logic that checks for an identifier label in the
http collector config. It also removes the documentation on the README
that mentions that the metric has to be in an old format, removed in
the #219.
Fixes#331
Signed-off-by: Jonathan Juares Beber <jonathanbeber@gmail.com>
During #284 we set the ClusterScalingSchedule scope as `Cluster` but
just for kubebuilder. This flag has no effect in the generated clients.
It means the generated clients expect a namespace argument when handling
ClusterScalingSchedule resources. It works fine to list all of the
resources but makes it impossible to request a specific resource
defining its name.
This commit sets the `+genclient:nonNamespaced` flag for the CRD and
adds the regenerated clients. It does not affect any of the usage of the
clients in this codebase so far.
Signed-off-by: Jonathan Juares Beber <jonathanbeber@gmail.com>
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>
# Learn more about CodeQL language support at https://aka.ms/codeql-docs/language-support
steps:
- name:Checkout repository
uses:actions/checkout@v3
# Initializes the CodeQL tools for scanning.
- name:Initialize CodeQL
uses:github/codeql-action/init@v2
with:
languages:${{ matrix.language }}
# If you wish to specify custom queries, you can do so here or in a config file.
# By default, queries listed here will override any specified in a config file.
# Prefix the list here with "+" to use these queries and those in the config file.
# Details on CodeQL's query packs refer to : https://docs.github.com/en/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/configuring-code-scanning#using-queries-in-ql-packs
# queries: security-extended,security-and-quality
# Autobuild attempts to build any compiled languages (C/C++, C#, or Java).
# If this step fails, then you should remove it and run the build manually (see below)
- name:Autobuild
uses:github/codeql-action/autobuild@v2
# ℹ️ Command-line programs to run using the OS shell.
# 📚 See https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepsrun
# If the Autobuild fails above, remove it and uncomment the following three lines.
# modify them (or add more) to build your code if your project, please refer to the EXAMPLE below for guidance.
description:ClusterScalingSchedule describes a cluster scoped time based
metric to be used in autoscaling operations.
properties:
apiVersion:
description:'APIVersion defines the versioned schema of this representation
of an object. Servers should convert recognized schemas to the latest
internal value, and may reject unrecognized values. More info:https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources'
type:string
kind:
description:'Kind is a string value representing the REST resource this
object represents. Servers may infer this from the endpoint the client
submits requests to. Cannot be updated. In CamelCase. More info:https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds'
type:string
metadata:
type:object
spec:
description:ScalingScheduleSpec is the spec part of the ScalingSchedule.
properties:
schedules:
description:Schedules is the list of schedules for this ScalingSchedule
resource. All the schedules defined here will result on the value
to the same metric. New metrics require a new ScalingSchedule resource.
items:
description:Schedule is the schedule details to be used inside
a ScalingSchedule.
properties:
date:
description:Defines the starting date of a OneTime schedule.
It has to be a RFC3339 formated date.
format:date-time
type:string
durationMinutes:
description:The duration in minutes that the configured value
will be returned for the defined schedule.
type:integer
period:
description:Defines the details of a Repeating schedule.
properties:
days:
description:The days that this schedule will be active.
items:
description:ScheduleDay represents the valid inputs for
days in a SchedulePeriod.
enum:
- Sun
- Mon
- Tue
- Wed
- Thu
- Fri
- Sat
type:string
type:array
startTime:
description:The startTime has the format HH:MM
pattern:(([0-1][0-9])|([2][0-3])):([0-5][0-9])
type:string
timezone:
description:The location name corresponding to a file in
the IANA Time Zone database, like Europe/Berlin.
type:string
required:
- days
- startTime
- timezone
type:object
type:
description:Defines if the schedule is a OneTime schedule or
Repeating one. If OneTime, date has to be defined. If Repeating,
Period has to be defined.
enum:
- OneTime
- Repeating
type:string
value:
description:The metric value that will be returned for the
description:ScalingSchedule describes a namespaced time based metric to be
used in autoscaling operations.
properties:
apiVersion:
description:'APIVersion defines the versioned schema of this representation
of an object. Servers should convert recognized schemas to the latest
internal value, and may reject unrecognized values. More info:https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources'
type:string
kind:
description:'Kind is a string value representing the REST resource this
object represents. Servers may infer this from the endpoint the client
submits requests to. Cannot be updated. In CamelCase. More info:https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds'
type:string
metadata:
type:object
spec:
description:ScalingScheduleSpec is the spec part of the ScalingSchedule.
properties:
schedules:
description:Schedules is the list of schedules for this ScalingSchedule
resource. All the schedules defined here will result on the value
to the same metric. New metrics require a new ScalingSchedule resource.
items:
description:Schedule is the schedule details to be used inside
a ScalingSchedule.
properties:
date:
description:Defines the starting date of a OneTime schedule.
It has to be a RFC3339 formated date.
format:date-time
type:string
durationMinutes:
description:The duration in minutes that the configured value
will be returned for the defined schedule.
type:integer
period:
description:Defines the details of a Repeating schedule.
properties:
days:
description:The days that this schedule will be active.
items:
description:ScheduleDay represents the valid inputs for
days in a SchedulePeriod.
enum:
- Sun
- Mon
- Tue
- Wed
- Thu
- Fri
- Sat
type:string
type:array
startTime:
description:The startTime has the format HH:MM
pattern:(([0-1][0-9])|([2][0-3])):([0-5][0-9])
type:string
timezone:
description:The location name corresponding to a file in
the IANA Time Zone database, like Europe/Berlin.
type:string
required:
- days
- startTime
- timezone
type:object
type:
description:Defines if the schedule is a OneTime schedule or
Repeating one. If OneTime, date has to be defined. If Repeating,
Period has to be defined.
enum:
- OneTime
- Repeating
type:string
value:
description:The metric value that will be returned for the
File diff suppressed because it is too large
Load Diff
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
