github
/
k3s
mirror of https://github.com/k3s-io/k3s
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
k3s/pkg/controller/podautoscaler/BUILD

109 lines
4.2 KiB
Python
Raw Normal View History

autogenerated
2016-10-19 21:42:06 +00:00
package(default_visibility = ["//visibility:public"])
licenses(["notice"])
load(
"@io_bazel_rules_go//go:def.bzl",
"go_library",
"go_test",
)
go_library(
name = "go_default_library",
srcs = [
"doc.go",
"horizontal.go",
Rate limit HPA controller to sync period Since the HPA controller pulls information from an external source that makes no guarantees about consistency, it's possible for the HPA to get into an infinite update loop -- if the metrics change with every query, the HPA controller will run it's normal reconcilation, post a status update, see that status update itself, fetch new metrics, and if those metrics are different, post another status update, and repeat. This can lead to continuously updating a single HPA. By rate-limiting each HPA to once per sync interval, we prevent this from happening.
2017-03-08 07:02:34 +00:00
"rate_limitters.go",
HPA: Consider unready pods and missing metrics Currently, the HPA considers unready pods the same as ready pods when looking at their CPU and custom metric usage. However, pods frequently use extra CPU during initialization, so we want to consider them separately. This commit causes the HPA to consider unready pods as having 0 CPU usage when scaling up, and ignores them when scaling down. If, when scaling up, factoring the unready pods as having 0 CPU would cause a downscale instead, we simply choose not to scale. Otherwise, we simply scale up at the reduced amount caculated by factoring the pods in at zero CPU usage. The effect is that unready pods cause the autoscaler to be a bit more conservative -- large increases in CPU usage can still cause scales, even with unready pods in the mix, but will not cause the scale factors to be as large, in anticipation of the new pods later becoming ready and handling load. Similarly, if there are pods for which no metrics have been retrieved, these pods are treated as having 100% of the requested metric when scaling down, and 0% when scaling up. As above, this cannot change the direction of the scale. This commit also changes the HPA to ignore superfluous metrics -- as long as metrics for all ready pods are present, the HPA we make scaling decisions. Currently, this only works for CPU. For custom metrics, we cannot identify which metrics go to which pods if we get superfluous metrics, so we abort the scale.
2016-09-27 18:47:52 +00:00
"replica_calculator.go",
autogenerated
2016-10-19 21:42:06 +00:00
],
tags = ["automanaged"],
deps = [
move client/record
2017-01-30 18:39:54 +00:00
"//pkg/api:go_default_library",
run hack/update-all.sh
2016-11-18 21:35:28 +00:00
"//pkg/api/v1:go_default_library",
"//pkg/apis/autoscaling/v1:go_default_library",
Convert HPA controller to use autoscaling/v2alpha1 This commit converts the HPA controller over to using the new version of the HorizontalPodAutoscaler object found in autoscaling/v2alpha1. Note that while the autoscaler will accept requests for object metrics, the scale client will return an error on attempts to get object metrics (since that requires the new custom metrics API, which is not yet implemented). This also enables the HPA object in v2alpha1 as a retrievable API version by default.
2016-12-02 20:18:26 +00:00
"//pkg/apis/autoscaling/v2alpha1:go_default_library",
run hack/update-all.sh
2016-11-18 21:35:28 +00:00
"//pkg/apis/extensions/v1beta1:go_default_library",
rename /release_1_5 to /clientset
2016-12-14 01:18:17 +00:00
"//pkg/client/clientset_generated/clientset/typed/autoscaling/v1:go_default_library",
"//pkg/client/clientset_generated/clientset/typed/core/v1:go_default_library",
"//pkg/client/clientset_generated/clientset/typed/extensions/v1beta1:go_default_library",
react to informer updates
2017-02-08 21:18:21 +00:00
"//pkg/client/informers/informers_generated/externalversions/autoscaling/v1:go_default_library",
Switch hpa controller to shared informer
2017-02-09 19:59:19 +00:00
"//pkg/client/listers/autoscaling/v1:go_default_library",
Rate limit HPA controller to sync period Since the HPA controller pulls information from an external source that makes no guarantees about consistency, it's possible for the HPA to get into an infinite update loop -- if the metrics change with every query, the HPA controller will run it's normal reconcilation, post a status update, see that status update itself, fetch new metrics, and if those metrics are different, post another status update, and repeat. This can lead to continuously updating a single HPA. By rate-limiting each HPA to once per sync interval, we prevent this from happening.
2017-03-08 07:02:34 +00:00
"//pkg/controller:go_default_library",
autogenerated
2016-10-19 21:42:06 +00:00
"//pkg/controller/podautoscaler/metrics:go_default_library",
"//vendor:github.com/golang/glog",
Rate limit HPA controller to sync period Since the HPA controller pulls information from an external source that makes no guarantees about consistency, it's possible for the HPA to get into an infinite update loop -- if the metrics change with every query, the HPA controller will run it's normal reconcilation, post a status update, see that status update itself, fetch new metrics, and if those metrics are different, post another status update, and repeat. This can lead to continuously updating a single HPA. By rate-limiting each HPA to once per sync interval, we prevent this from happening.
2017-03-08 07:02:34 +00:00
"//vendor:k8s.io/apimachinery/pkg/api/errors",
Update generated files
2017-01-29 12:08:49 +00:00
"//vendor:k8s.io/apimachinery/pkg/api/resource",
start the apimachinery repo
2017-01-11 14:09:48 +00:00
"//vendor:k8s.io/apimachinery/pkg/apis/meta/v1",
"//vendor:k8s.io/apimachinery/pkg/labels",
Convert HPA controller to use autoscaling/v2alpha1 This commit converts the HPA controller over to using the new version of the HorizontalPodAutoscaler object found in autoscaling/v2alpha1. Note that while the autoscaler will accept requests for object metrics, the scale client will return an error on attempts to get object metrics (since that requires the new custom metrics API, which is not yet implemented). This also enables the HPA object in v2alpha1 as a retrievable API version by default.
2016-12-02 20:18:26 +00:00
"//vendor:k8s.io/apimachinery/pkg/runtime",
"//vendor:k8s.io/apimachinery/pkg/runtime/schema",
start the apimachinery repo
2017-01-11 14:09:48 +00:00
"//vendor:k8s.io/apimachinery/pkg/util/runtime",
"//vendor:k8s.io/apimachinery/pkg/util/sets",
Rate limit HPA controller to sync period Since the HPA controller pulls information from an external source that makes no guarantees about consistency, it's possible for the HPA to get into an infinite update loop -- if the metrics change with every query, the HPA controller will run it's normal reconcilation, post a status update, see that status update itself, fetch new metrics, and if those metrics are different, post another status update, and repeat. This can lead to continuously updating a single HPA. By rate-limiting each HPA to once per sync interval, we prevent this from happening.
2017-03-08 07:02:34 +00:00
"//vendor:k8s.io/apimachinery/pkg/util/wait",
move client/record
2017-01-30 18:39:54 +00:00
"//vendor:k8s.io/client-go/kubernetes/typed/core/v1",
"//vendor:k8s.io/client-go/pkg/api/v1",
make tools/cache authoritative
2017-01-24 14:11:51 +00:00
"//vendor:k8s.io/client-go/tools/cache",
move client/record
2017-01-30 18:39:54 +00:00
"//vendor:k8s.io/client-go/tools/record",
Rate limit HPA controller to sync period Since the HPA controller pulls information from an external source that makes no guarantees about consistency, it's possible for the HPA to get into an infinite update loop -- if the metrics change with every query, the HPA controller will run it's normal reconcilation, post a status update, see that status update itself, fetch new metrics, and if those metrics are different, post another status update, and repeat. This can lead to continuously updating a single HPA. By rate-limiting each HPA to once per sync interval, we prevent this from happening.
2017-03-08 07:02:34 +00:00
"//vendor:k8s.io/client-go/util/workqueue",
autogenerated
2016-10-19 21:42:06 +00:00
],
)
go_test(
name = "go_default_test",
HPA: Consider unready pods and missing metrics Currently, the HPA considers unready pods the same as ready pods when looking at their CPU and custom metric usage. However, pods frequently use extra CPU during initialization, so we want to consider them separately. This commit causes the HPA to consider unready pods as having 0 CPU usage when scaling up, and ignores them when scaling down. If, when scaling up, factoring the unready pods as having 0 CPU would cause a downscale instead, we simply choose not to scale. Otherwise, we simply scale up at the reduced amount caculated by factoring the pods in at zero CPU usage. The effect is that unready pods cause the autoscaler to be a bit more conservative -- large increases in CPU usage can still cause scales, even with unready pods in the mix, but will not cause the scale factors to be as large, in anticipation of the new pods later becoming ready and handling load. Similarly, if there are pods for which no metrics have been retrieved, these pods are treated as having 100% of the requested metric when scaling down, and 0% when scaling up. As above, this cannot change the direction of the scale. This commit also changes the HPA to ignore superfluous metrics -- as long as metrics for all ready pods are present, the HPA we make scaling decisions. Currently, this only works for CPU. For custom metrics, we cannot identify which metrics go to which pods if we get superfluous metrics, so we abort the scale.
2016-09-27 18:47:52 +00:00
srcs = [
"horizontal_test.go",
HPA Controller: Use Custom Metrics API This commit switches over the HPA controller to use the custom metrics API. It also converts the HPA controller to use the generated client in k8s.io/metrics for the resource metrics API. In order to enable support, you must enable `--horizontal-pod-autoscaler-use-rest-clients` on the controller-manager, which will switch the HPA controller's MetricsClient implementation over to use the standard rest clients for both custom metrics and resource metrics. This requires that at the least resource metrics API is registered with kube-aggregator, and that the controller manager is pointed at kube-aggregator. For this to work, Heapster must be serving the new-style API server (`--api-server=true`).
2017-02-20 06:17:16 +00:00
"legacy_horizontal_test.go",
"legacy_replica_calculator_test.go",
HPA: Consider unready pods and missing metrics Currently, the HPA considers unready pods the same as ready pods when looking at their CPU and custom metric usage. However, pods frequently use extra CPU during initialization, so we want to consider them separately. This commit causes the HPA to consider unready pods as having 0 CPU usage when scaling up, and ignores them when scaling down. If, when scaling up, factoring the unready pods as having 0 CPU would cause a downscale instead, we simply choose not to scale. Otherwise, we simply scale up at the reduced amount caculated by factoring the pods in at zero CPU usage. The effect is that unready pods cause the autoscaler to be a bit more conservative -- large increases in CPU usage can still cause scales, even with unready pods in the mix, but will not cause the scale factors to be as large, in anticipation of the new pods later becoming ready and handling load. Similarly, if there are pods for which no metrics have been retrieved, these pods are treated as having 100% of the requested metric when scaling down, and 0% when scaling up. As above, this cannot change the direction of the scale. This commit also changes the HPA to ignore superfluous metrics -- as long as metrics for all ready pods are present, the HPA we make scaling decisions. Currently, this only works for CPU. For custom metrics, we cannot identify which metrics go to which pods if we get superfluous metrics, so we abort the scale.
2016-09-27 18:47:52 +00:00
"replica_calculator_test.go",
],
autogenerated
2016-12-29 21:02:00 +00:00
library = ":go_default_library",
autogenerated
2016-10-19 21:42:06 +00:00
tags = ["automanaged"],
deps = [
refactor: update bazel, codec, and gofmt
2016-12-03 19:06:03 +00:00
"//pkg/api/unversioned:go_default_library",
autogenerated
2016-10-19 21:42:06 +00:00
"//pkg/api/v1:go_default_library",
move client/record
2017-01-30 18:39:54 +00:00
"//pkg/apis/autoscaling/install:go_default_library",
run hack/update-all.sh
2016-11-18 21:35:28 +00:00
"//pkg/apis/autoscaling/v1:go_default_library",
Convert HPA controller to use autoscaling/v2alpha1 This commit converts the HPA controller over to using the new version of the HorizontalPodAutoscaler object found in autoscaling/v2alpha1. Note that while the autoscaler will accept requests for object metrics, the scale client will return an error on attempts to get object metrics (since that requires the new custom metrics API, which is not yet implemented). This also enables the HPA object in v2alpha1 as a retrievable API version by default.
2016-12-02 20:18:26 +00:00
"//pkg/apis/autoscaling/v2alpha1:go_default_library",
move client/record
2017-01-30 18:39:54 +00:00
"//pkg/apis/extensions/install:go_default_library",
run hack/update-all.sh
2016-11-18 21:35:28 +00:00
"//pkg/apis/extensions/v1beta1:go_default_library",
rename /release_1_5 to /clientset
2016-12-14 01:18:17 +00:00
"//pkg/client/clientset_generated/clientset/fake:go_default_library",
react to informer updates
2017-02-08 21:18:21 +00:00
"//pkg/client/informers/informers_generated/externalversions:go_default_library",
Switch hpa controller to shared informer
2017-02-09 19:59:19 +00:00
"//pkg/controller:go_default_library",
autogenerated
2016-10-19 21:42:06 +00:00
"//pkg/controller/podautoscaler/metrics:go_default_library",
"//vendor:github.com/stretchr/testify/assert",
HPA: Consider unready pods and missing metrics Currently, the HPA considers unready pods the same as ready pods when looking at their CPU and custom metric usage. However, pods frequently use extra CPU during initialization, so we want to consider them separately. This commit causes the HPA to consider unready pods as having 0 CPU usage when scaling up, and ignores them when scaling down. If, when scaling up, factoring the unready pods as having 0 CPU would cause a downscale instead, we simply choose not to scale. Otherwise, we simply scale up at the reduced amount caculated by factoring the pods in at zero CPU usage. The effect is that unready pods cause the autoscaler to be a bit more conservative -- large increases in CPU usage can still cause scales, even with unready pods in the mix, but will not cause the scale factors to be as large, in anticipation of the new pods later becoming ready and handling load. Similarly, if there are pods for which no metrics have been retrieved, these pods are treated as having 100% of the requested metric when scaling down, and 0% when scaling up. As above, this cannot change the direction of the scale. This commit also changes the HPA to ignore superfluous metrics -- as long as metrics for all ready pods are present, the HPA we make scaling decisions. Currently, this only works for CPU. For custom metrics, we cannot identify which metrics go to which pods if we get superfluous metrics, so we abort the scale.
2016-09-27 18:47:52 +00:00
"//vendor:github.com/stretchr/testify/require",
Update generated files
2017-01-29 12:08:49 +00:00
"//vendor:k8s.io/apimachinery/pkg/api/resource",
start the apimachinery repo
2017-01-11 14:09:48 +00:00
"//vendor:k8s.io/apimachinery/pkg/apis/meta/v1",
"//vendor:k8s.io/apimachinery/pkg/runtime",
HPA Controller: Use Custom Metrics API This commit switches over the HPA controller to use the custom metrics API. It also converts the HPA controller to use the generated client in k8s.io/metrics for the resource metrics API. In order to enable support, you must enable `--horizontal-pod-autoscaler-use-rest-clients` on the controller-manager, which will switch the HPA controller's MetricsClient implementation over to use the standard rest clients for both custom metrics and resource metrics. This requires that at the least resource metrics API is registered with kube-aggregator, and that the controller manager is pointed at kube-aggregator. For this to work, Heapster must be serving the new-style API server (`--api-server=true`).
2017-02-20 06:17:16 +00:00
"//vendor:k8s.io/apimachinery/pkg/runtime/schema",
start the apimachinery repo
2017-01-11 14:09:48 +00:00
"//vendor:k8s.io/apimachinery/pkg/watch",
move client/record
2017-01-30 18:39:54 +00:00
"//vendor:k8s.io/client-go/kubernetes/fake",
HPA Controller: Use Custom Metrics API This commit switches over the HPA controller to use the custom metrics API. It also converts the HPA controller to use the generated client in k8s.io/metrics for the resource metrics API. In order to enable support, you must enable `--horizontal-pod-autoscaler-use-rest-clients` on the controller-manager, which will switch the HPA controller's MetricsClient implementation over to use the standard rest clients for both custom metrics and resource metrics. This requires that at the least resource metrics API is registered with kube-aggregator, and that the controller manager is pointed at kube-aggregator. For this to work, Heapster must be serving the new-style API server (`--api-server=true`).
2017-02-20 06:17:16 +00:00
"//vendor:k8s.io/client-go/pkg/api",
move client/record
2017-01-30 18:39:54 +00:00
"//vendor:k8s.io/client-go/pkg/api/v1",
find and replace
2017-01-19 18:27:59 +00:00
"//vendor:k8s.io/client-go/rest",
move testing/core to client-go
2017-01-25 20:07:10 +00:00
"//vendor:k8s.io/client-go/testing",
autogenerated
2016-10-19 21:42:06 +00:00
"//vendor:k8s.io/heapster/metrics/api/v1/types",
"//vendor:k8s.io/heapster/metrics/apis/metrics/v1alpha1",
HPA Controller: Use Custom Metrics API This commit switches over the HPA controller to use the custom metrics API. It also converts the HPA controller to use the generated client in k8s.io/metrics for the resource metrics API. In order to enable support, you must enable `--horizontal-pod-autoscaler-use-rest-clients` on the controller-manager, which will switch the HPA controller's MetricsClient implementation over to use the standard rest clients for both custom metrics and resource metrics. This requires that at the least resource metrics API is registered with kube-aggregator, and that the controller manager is pointed at kube-aggregator. For this to work, Heapster must be serving the new-style API server (`--api-server=true`).
2017-02-20 06:17:16 +00:00
"//vendor:k8s.io/metrics/pkg/apis/custom_metrics/v1alpha1",
"//vendor:k8s.io/metrics/pkg/apis/metrics/v1alpha1",
"//vendor:k8s.io/metrics/pkg/client/clientset_generated/clientset/fake",
"//vendor:k8s.io/metrics/pkg/client/custom_metrics/fake",
autogenerated
2016-10-19 21:42:06 +00:00
],
)
Enable auto-generating sources rules
2017-01-03 22:40:41 +00:00
filegroup(
name = "package-srcs",
srcs = glob(["**"]),
tags = ["automanaged"],
visibility = ["//visibility:private"],
)
filegroup(
name = "all-srcs",
srcs = [
":package-srcs",
"//pkg/controller/podautoscaler/metrics:all-srcs",
],
tags = ["automanaged"],
)