2015-08-20 12:55:28 +00:00
|
|
|
/*
|
2016-06-03 00:25:58 +00:00
|
|
|
Copyright 2015 The Kubernetes Authors.
|
2015-08-20 12:55:28 +00:00
|
|
|
|
|
|
|
Licensed under the Apache License, Version 2.0 (the "License");
|
|
|
|
you may not use this file except in compliance with the License.
|
|
|
|
You may obtain a copy of the License at
|
|
|
|
|
|
|
|
http://www.apache.org/licenses/LICENSE-2.0
|
|
|
|
|
|
|
|
Unless required by applicable law or agreed to in writing, software
|
|
|
|
distributed under the License is distributed on an "AS IS" BASIS,
|
|
|
|
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
|
|
See the License for the specific language governing permissions and
|
|
|
|
limitations under the License.
|
|
|
|
*/
|
|
|
|
|
2015-09-10 13:10:07 +00:00
|
|
|
package podautoscaler
|
2015-08-20 12:55:28 +00:00
|
|
|
|
|
|
|
import (
|
2015-09-14 08:14:32 +00:00
|
|
|
"encoding/json"
|
2015-08-20 12:55:28 +00:00
|
|
|
"fmt"
|
2015-09-14 08:14:32 +00:00
|
|
|
"io"
|
2016-05-06 21:52:30 +00:00
|
|
|
"math"
|
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
|
|
|
"strconv"
|
|
|
|
"strings"
|
2016-04-20 16:57:36 +00:00
|
|
|
"sync"
|
2015-08-20 12:55:28 +00:00
|
|
|
"testing"
|
2015-09-14 08:14:32 +00:00
|
|
|
"time"
|
2015-08-20 12:55:28 +00:00
|
|
|
|
|
|
|
"k8s.io/kubernetes/pkg/api/resource"
|
2016-12-03 19:06:03 +00:00
|
|
|
"k8s.io/kubernetes/pkg/api/unversioned"
|
2016-05-17 19:31:31 +00:00
|
|
|
"k8s.io/kubernetes/pkg/api/v1"
|
2016-01-13 22:40:56 +00:00
|
|
|
_ "k8s.io/kubernetes/pkg/apimachinery/registered"
|
2016-11-18 20:50:17 +00:00
|
|
|
autoscaling "k8s.io/kubernetes/pkg/apis/autoscaling/v1"
|
|
|
|
extensions "k8s.io/kubernetes/pkg/apis/extensions/v1beta1"
|
2016-12-03 19:06:03 +00:00
|
|
|
metav1 "k8s.io/kubernetes/pkg/apis/meta/v1"
|
2016-12-14 01:18:17 +00:00
|
|
|
"k8s.io/kubernetes/pkg/client/clientset_generated/clientset/fake"
|
|
|
|
v1core "k8s.io/kubernetes/pkg/client/clientset_generated/clientset/typed/core/v1"
|
2016-03-03 10:48:07 +00:00
|
|
|
"k8s.io/kubernetes/pkg/client/record"
|
2016-02-12 18:58:43 +00:00
|
|
|
"k8s.io/kubernetes/pkg/client/restclient"
|
2016-01-29 06:34:08 +00:00
|
|
|
"k8s.io/kubernetes/pkg/client/testing/core"
|
2015-09-10 13:10:07 +00:00
|
|
|
"k8s.io/kubernetes/pkg/controller/podautoscaler/metrics"
|
2015-08-20 12:55:28 +00:00
|
|
|
"k8s.io/kubernetes/pkg/runtime"
|
2016-03-02 08:29:17 +00:00
|
|
|
"k8s.io/kubernetes/pkg/watch"
|
2015-08-20 12:55:28 +00:00
|
|
|
|
2016-04-28 14:29:38 +00:00
|
|
|
heapster "k8s.io/heapster/metrics/api/v1/types"
|
2016-11-30 07:27:27 +00:00
|
|
|
metricsapi "k8s.io/heapster/metrics/apis/metrics/v1alpha1"
|
2015-09-14 08:14:32 +00:00
|
|
|
|
2015-12-13 08:54:43 +00:00
|
|
|
"github.com/stretchr/testify/assert"
|
2015-08-20 12:55:28 +00:00
|
|
|
)
|
|
|
|
|
2015-09-14 08:14:32 +00:00
|
|
|
func (w fakeResponseWrapper) DoRaw() ([]byte, error) {
|
|
|
|
return w.raw, nil
|
|
|
|
}
|
2015-08-20 12:55:28 +00:00
|
|
|
|
2015-09-14 08:14:32 +00:00
|
|
|
func (w fakeResponseWrapper) Stream() (io.ReadCloser, error) {
|
|
|
|
return nil, nil
|
|
|
|
}
|
2015-08-20 12:55:28 +00:00
|
|
|
|
2015-09-14 08:14:32 +00:00
|
|
|
func newFakeResponseWrapper(raw []byte) fakeResponseWrapper {
|
|
|
|
return fakeResponseWrapper{raw: raw}
|
2015-08-20 12:55:28 +00:00
|
|
|
}
|
|
|
|
|
2015-09-14 08:14:32 +00:00
|
|
|
type fakeResponseWrapper struct {
|
|
|
|
raw []byte
|
2015-08-28 10:24:00 +00:00
|
|
|
}
|
|
|
|
|
2016-03-09 00:27:13 +00:00
|
|
|
type fakeResource struct {
|
|
|
|
name string
|
|
|
|
apiVersion string
|
|
|
|
kind string
|
|
|
|
}
|
|
|
|
|
2015-09-14 08:14:32 +00:00
|
|
|
type testCase struct {
|
2016-04-20 16:57:36 +00:00
|
|
|
sync.Mutex
|
2016-04-27 04:35:14 +00:00
|
|
|
minReplicas int32
|
|
|
|
maxReplicas int32
|
|
|
|
initialReplicas int32
|
|
|
|
desiredReplicas int32
|
2016-04-20 16:57:36 +00:00
|
|
|
|
2015-10-13 15:24:23 +00:00
|
|
|
// CPU target utilization as a percentage of the requested resources.
|
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
|
|
|
CPUTarget int32
|
|
|
|
CPUCurrent int32
|
|
|
|
verifyCPUCurrent bool
|
|
|
|
reportedLevels []uint64
|
|
|
|
reportedCPURequests []resource.Quantity
|
2016-11-18 20:50:17 +00:00
|
|
|
reportedPodReadiness []v1.ConditionStatus
|
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
|
|
|
cmTarget *extensions.CustomMetricTargetList
|
|
|
|
scaleUpdated bool
|
|
|
|
statusUpdated bool
|
|
|
|
eventCreated bool
|
|
|
|
verifyEvents bool
|
|
|
|
useMetricsApi bool
|
2016-03-02 09:08:17 +00:00
|
|
|
// Channel with names of HPA objects which we have reconciled.
|
|
|
|
processed chan string
|
2016-03-09 00:27:13 +00:00
|
|
|
|
|
|
|
// Target resource information.
|
|
|
|
resource *fakeResource
|
2016-11-21 09:32:00 +00:00
|
|
|
|
|
|
|
// Last scale time
|
2016-12-03 18:57:26 +00:00
|
|
|
lastScaleTime *metav1.Time
|
2015-08-28 10:24:00 +00:00
|
|
|
}
|
|
|
|
|
2016-04-20 16:57:36 +00:00
|
|
|
// Needs to be called under a lock.
|
2016-02-23 14:18:49 +00:00
|
|
|
func (tc *testCase) computeCPUCurrent() {
|
|
|
|
if len(tc.reportedLevels) != len(tc.reportedCPURequests) || len(tc.reportedLevels) == 0 {
|
|
|
|
return
|
|
|
|
}
|
|
|
|
reported := 0
|
|
|
|
for _, r := range tc.reportedLevels {
|
|
|
|
reported += int(r)
|
|
|
|
}
|
|
|
|
requested := 0
|
|
|
|
for _, req := range tc.reportedCPURequests {
|
|
|
|
requested += int(req.MilliValue())
|
|
|
|
}
|
2016-04-27 04:35:14 +00:00
|
|
|
tc.CPUCurrent = int32(100 * reported / requested)
|
2016-02-23 14:18:49 +00:00
|
|
|
}
|
|
|
|
|
2016-01-29 06:34:08 +00:00
|
|
|
func (tc *testCase) prepareTestClient(t *testing.T) *fake.Clientset {
|
2015-09-14 08:14:32 +00:00
|
|
|
namespace := "test-namespace"
|
|
|
|
hpaName := "test-hpa"
|
|
|
|
podNamePrefix := "test-pod"
|
2016-12-03 18:57:26 +00:00
|
|
|
selector := &metav1.LabelSelector{
|
2016-03-09 00:27:13 +00:00
|
|
|
MatchLabels: map[string]string{"name": podNamePrefix},
|
|
|
|
}
|
2015-09-14 08:14:32 +00:00
|
|
|
|
2016-04-20 16:57:36 +00:00
|
|
|
tc.Lock()
|
|
|
|
|
2015-09-14 08:14:32 +00:00
|
|
|
tc.scaleUpdated = false
|
2016-02-23 12:05:07 +00:00
|
|
|
tc.statusUpdated = false
|
2015-09-14 08:14:32 +00:00
|
|
|
tc.eventCreated = false
|
2016-03-02 09:08:17 +00:00
|
|
|
tc.processed = make(chan string, 100)
|
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
|
|
|
if tc.CPUCurrent == 0 {
|
|
|
|
tc.computeCPUCurrent()
|
|
|
|
}
|
2015-09-14 08:14:32 +00:00
|
|
|
|
2016-03-09 00:27:13 +00:00
|
|
|
// TODO(madhusudancs): HPA only supports resources in extensions/v1beta1 right now. Add
|
|
|
|
// tests for "v1" replicationcontrollers when HPA adds support for cross-group scale.
|
|
|
|
if tc.resource == nil {
|
|
|
|
tc.resource = &fakeResource{
|
|
|
|
name: "test-rc",
|
|
|
|
apiVersion: "extensions/v1beta1",
|
|
|
|
kind: "replicationcontrollers",
|
|
|
|
}
|
|
|
|
}
|
2016-04-20 16:57:36 +00:00
|
|
|
tc.Unlock()
|
2016-03-09 00:27:13 +00:00
|
|
|
|
2016-01-29 06:34:08 +00:00
|
|
|
fakeClient := &fake.Clientset{}
|
|
|
|
fakeClient.AddReactor("list", "horizontalpodautoscalers", func(action core.Action) (handled bool, ret runtime.Object, err error) {
|
2016-04-20 16:57:36 +00:00
|
|
|
tc.Lock()
|
|
|
|
defer tc.Unlock()
|
|
|
|
|
2016-05-05 10:27:24 +00:00
|
|
|
obj := &autoscaling.HorizontalPodAutoscalerList{
|
|
|
|
Items: []autoscaling.HorizontalPodAutoscaler{
|
2015-09-14 08:14:32 +00:00
|
|
|
{
|
2016-11-18 20:50:17 +00:00
|
|
|
ObjectMeta: v1.ObjectMeta{
|
2015-09-14 08:14:32 +00:00
|
|
|
Name: hpaName,
|
|
|
|
Namespace: namespace,
|
|
|
|
SelfLink: "experimental/v1/namespaces/" + namespace + "/horizontalpodautoscalers/" + hpaName,
|
|
|
|
},
|
2016-05-05 10:27:24 +00:00
|
|
|
Spec: autoscaling.HorizontalPodAutoscalerSpec{
|
|
|
|
ScaleTargetRef: autoscaling.CrossVersionObjectReference{
|
|
|
|
Kind: tc.resource.kind,
|
|
|
|
Name: tc.resource.name,
|
|
|
|
APIVersion: tc.resource.apiVersion,
|
2015-09-14 08:14:32 +00:00
|
|
|
},
|
2015-10-13 15:24:23 +00:00
|
|
|
MinReplicas: &tc.minReplicas,
|
2015-09-17 12:08:39 +00:00
|
|
|
MaxReplicas: tc.maxReplicas,
|
2015-09-14 08:14:32 +00:00
|
|
|
},
|
2016-05-05 10:27:24 +00:00
|
|
|
Status: autoscaling.HorizontalPodAutoscalerStatus{
|
2016-02-23 12:05:07 +00:00
|
|
|
CurrentReplicas: tc.initialReplicas,
|
|
|
|
DesiredReplicas: tc.initialReplicas,
|
|
|
|
},
|
2015-09-14 08:14:32 +00:00
|
|
|
},
|
|
|
|
},
|
|
|
|
}
|
2016-04-20 16:57:36 +00:00
|
|
|
|
2015-10-13 15:24:23 +00:00
|
|
|
if tc.CPUTarget > 0.0 {
|
2016-05-05 10:27:24 +00:00
|
|
|
obj.Items[0].Spec.TargetCPUUtilizationPercentage = &tc.CPUTarget
|
2015-10-13 15:24:23 +00:00
|
|
|
}
|
2016-01-29 11:20:19 +00:00
|
|
|
if tc.cmTarget != nil {
|
|
|
|
b, err := json.Marshal(tc.cmTarget)
|
|
|
|
if err != nil {
|
|
|
|
t.Fatalf("Failed to marshal cm: %v", err)
|
|
|
|
}
|
|
|
|
obj.Items[0].Annotations = make(map[string]string)
|
2016-02-05 10:31:51 +00:00
|
|
|
obj.Items[0].Annotations[HpaCustomMetricsTargetAnnotationName] = string(b)
|
2016-01-29 11:20:19 +00:00
|
|
|
}
|
2015-09-14 08:14:32 +00:00
|
|
|
return true, obj, nil
|
|
|
|
})
|
|
|
|
|
2016-03-09 00:27:13 +00:00
|
|
|
fakeClient.AddReactor("get", "replicationcontrollers", func(action core.Action) (handled bool, ret runtime.Object, err error) {
|
2016-04-20 16:57:36 +00:00
|
|
|
tc.Lock()
|
|
|
|
defer tc.Unlock()
|
|
|
|
|
2016-03-09 00:27:13 +00:00
|
|
|
obj := &extensions.Scale{
|
2016-11-18 20:50:17 +00:00
|
|
|
ObjectMeta: v1.ObjectMeta{
|
2016-03-09 00:27:13 +00:00
|
|
|
Name: tc.resource.name,
|
|
|
|
Namespace: namespace,
|
|
|
|
},
|
|
|
|
Spec: extensions.ScaleSpec{
|
|
|
|
Replicas: tc.initialReplicas,
|
|
|
|
},
|
|
|
|
Status: extensions.ScaleStatus{
|
|
|
|
Replicas: tc.initialReplicas,
|
2016-11-18 20:50:17 +00:00
|
|
|
Selector: selector.MatchLabels,
|
2016-03-09 00:27:13 +00:00
|
|
|
},
|
|
|
|
}
|
|
|
|
return true, obj, nil
|
|
|
|
})
|
|
|
|
|
|
|
|
fakeClient.AddReactor("get", "deployments", func(action core.Action) (handled bool, ret runtime.Object, err error) {
|
2016-04-20 16:57:36 +00:00
|
|
|
tc.Lock()
|
|
|
|
defer tc.Unlock()
|
|
|
|
|
2016-03-09 00:27:13 +00:00
|
|
|
obj := &extensions.Scale{
|
2016-11-18 20:50:17 +00:00
|
|
|
ObjectMeta: v1.ObjectMeta{
|
2016-03-09 00:27:13 +00:00
|
|
|
Name: tc.resource.name,
|
|
|
|
Namespace: namespace,
|
|
|
|
},
|
|
|
|
Spec: extensions.ScaleSpec{
|
|
|
|
Replicas: tc.initialReplicas,
|
|
|
|
},
|
|
|
|
Status: extensions.ScaleStatus{
|
|
|
|
Replicas: tc.initialReplicas,
|
2016-11-18 20:50:17 +00:00
|
|
|
Selector: selector.MatchLabels,
|
2016-03-09 00:27:13 +00:00
|
|
|
},
|
|
|
|
}
|
|
|
|
return true, obj, nil
|
|
|
|
})
|
|
|
|
|
|
|
|
fakeClient.AddReactor("get", "replicasets", func(action core.Action) (handled bool, ret runtime.Object, err error) {
|
2016-04-20 16:57:36 +00:00
|
|
|
tc.Lock()
|
|
|
|
defer tc.Unlock()
|
|
|
|
|
2015-10-09 22:49:10 +00:00
|
|
|
obj := &extensions.Scale{
|
2016-11-18 20:50:17 +00:00
|
|
|
ObjectMeta: v1.ObjectMeta{
|
2016-03-09 00:27:13 +00:00
|
|
|
Name: tc.resource.name,
|
2015-09-14 08:14:32 +00:00
|
|
|
Namespace: namespace,
|
|
|
|
},
|
2015-10-09 22:49:10 +00:00
|
|
|
Spec: extensions.ScaleSpec{
|
2015-09-14 08:14:32 +00:00
|
|
|
Replicas: tc.initialReplicas,
|
|
|
|
},
|
2015-10-09 22:49:10 +00:00
|
|
|
Status: extensions.ScaleStatus{
|
2015-09-14 08:14:32 +00:00
|
|
|
Replicas: tc.initialReplicas,
|
2016-11-18 20:50:17 +00:00
|
|
|
Selector: selector.MatchLabels,
|
2015-09-14 08:14:32 +00:00
|
|
|
},
|
|
|
|
}
|
|
|
|
return true, obj, nil
|
|
|
|
})
|
|
|
|
|
2016-01-29 06:34:08 +00:00
|
|
|
fakeClient.AddReactor("list", "pods", func(action core.Action) (handled bool, ret runtime.Object, err error) {
|
2016-04-20 16:57:36 +00:00
|
|
|
tc.Lock()
|
|
|
|
defer tc.Unlock()
|
|
|
|
|
2016-11-18 20:50:17 +00:00
|
|
|
obj := &v1.PodList{}
|
2015-10-13 15:24:23 +00:00
|
|
|
for i := 0; i < len(tc.reportedCPURequests); i++ {
|
2016-11-18 20:50:17 +00:00
|
|
|
podReadiness := v1.ConditionTrue
|
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
|
|
|
if tc.reportedPodReadiness != nil {
|
|
|
|
podReadiness = tc.reportedPodReadiness[i]
|
|
|
|
}
|
2015-09-14 08:14:32 +00:00
|
|
|
podName := fmt.Sprintf("%s-%d", podNamePrefix, i)
|
2016-11-18 20:50:17 +00:00
|
|
|
pod := v1.Pod{
|
|
|
|
Status: v1.PodStatus{
|
|
|
|
Phase: v1.PodRunning,
|
|
|
|
Conditions: []v1.PodCondition{
|
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
|
|
|
{
|
2016-11-18 20:50:17 +00:00
|
|
|
Type: v1.PodReady,
|
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
|
|
|
Status: podReadiness,
|
|
|
|
},
|
|
|
|
},
|
2015-09-14 08:14:32 +00:00
|
|
|
},
|
2016-11-18 20:50:17 +00:00
|
|
|
ObjectMeta: v1.ObjectMeta{
|
2015-09-14 08:14:32 +00:00
|
|
|
Name: podName,
|
|
|
|
Namespace: namespace,
|
|
|
|
Labels: map[string]string{
|
|
|
|
"name": podNamePrefix,
|
|
|
|
},
|
|
|
|
},
|
2016-11-18 20:50:17 +00:00
|
|
|
Spec: v1.PodSpec{
|
|
|
|
Containers: []v1.Container{
|
2015-10-13 15:24:23 +00:00
|
|
|
{
|
2016-11-18 20:50:17 +00:00
|
|
|
Resources: v1.ResourceRequirements{
|
|
|
|
Requests: v1.ResourceList{
|
|
|
|
v1.ResourceCPU: tc.reportedCPURequests[i],
|
2015-10-13 15:24:23 +00:00
|
|
|
},
|
|
|
|
},
|
|
|
|
},
|
|
|
|
},
|
|
|
|
},
|
2015-09-14 08:14:32 +00:00
|
|
|
}
|
|
|
|
obj.Items = append(obj.Items, pod)
|
|
|
|
}
|
|
|
|
return true, obj, nil
|
|
|
|
})
|
|
|
|
|
2016-02-12 18:58:43 +00:00
|
|
|
fakeClient.AddProxyReactor("services", func(action core.Action) (handled bool, ret restclient.ResponseWrapper, err error) {
|
2016-04-20 16:57:36 +00:00
|
|
|
tc.Lock()
|
|
|
|
defer tc.Unlock()
|
|
|
|
|
2016-05-17 19:31:31 +00:00
|
|
|
var heapsterRawMemResponse []byte
|
|
|
|
|
|
|
|
if tc.useMetricsApi {
|
2016-11-30 07:27:27 +00:00
|
|
|
metrics := metricsapi.PodMetricsList{}
|
2016-05-17 19:31:31 +00:00
|
|
|
for i, cpu := range tc.reportedLevels {
|
2016-11-30 07:27:27 +00:00
|
|
|
podMetric := metricsapi.PodMetrics{
|
2016-05-17 19:31:31 +00:00
|
|
|
ObjectMeta: v1.ObjectMeta{
|
|
|
|
Name: fmt.Sprintf("%s-%d", podNamePrefix, i),
|
|
|
|
Namespace: namespace,
|
|
|
|
},
|
2016-12-03 19:06:03 +00:00
|
|
|
Timestamp: unversioned.Time{Time: time.Now()},
|
2016-11-30 07:27:27 +00:00
|
|
|
Containers: []metricsapi.ContainerMetrics{
|
2016-05-17 19:31:31 +00:00
|
|
|
{
|
|
|
|
Name: "container",
|
|
|
|
Usage: v1.ResourceList{
|
|
|
|
v1.ResourceCPU: *resource.NewMilliQuantity(
|
|
|
|
int64(cpu),
|
|
|
|
resource.DecimalSI),
|
|
|
|
v1.ResourceMemory: *resource.NewQuantity(
|
|
|
|
int64(1024*1024),
|
|
|
|
resource.BinarySI),
|
|
|
|
},
|
|
|
|
},
|
|
|
|
},
|
|
|
|
}
|
2016-08-19 12:18:59 +00:00
|
|
|
metrics.Items = append(metrics.Items, podMetric)
|
2015-09-14 08:14:32 +00:00
|
|
|
}
|
2016-05-17 19:31:31 +00:00
|
|
|
heapsterRawMemResponse, _ = json.Marshal(&metrics)
|
|
|
|
} else {
|
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
|
|
|
// only return the pods that we actually asked for
|
|
|
|
proxyAction := action.(core.ProxyGetAction)
|
|
|
|
pathParts := strings.Split(proxyAction.GetPath(), "/")
|
|
|
|
// pathParts should look like [ api, v1, model, namespaces, $NS, pod-list, $PODS, metrics, $METRIC... ]
|
|
|
|
if len(pathParts) < 9 {
|
|
|
|
return true, nil, fmt.Errorf("invalid heapster path %q", proxyAction.GetPath())
|
|
|
|
}
|
|
|
|
|
|
|
|
podNames := strings.Split(pathParts[7], ",")
|
|
|
|
podPresent := make([]bool, len(tc.reportedLevels))
|
|
|
|
for _, name := range podNames {
|
|
|
|
if len(name) <= len(podNamePrefix)+1 {
|
|
|
|
return true, nil, fmt.Errorf("unknown pod %q", name)
|
|
|
|
}
|
|
|
|
num, err := strconv.Atoi(name[len(podNamePrefix)+1:])
|
|
|
|
if err != nil {
|
|
|
|
return true, nil, fmt.Errorf("unknown pod %q", name)
|
|
|
|
}
|
|
|
|
podPresent[num] = true
|
|
|
|
}
|
|
|
|
|
2016-05-17 19:31:31 +00:00
|
|
|
timestamp := time.Now()
|
|
|
|
metrics := heapster.MetricResultList{}
|
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
|
|
|
for i, level := range tc.reportedLevels {
|
|
|
|
if !podPresent[i] {
|
|
|
|
continue
|
|
|
|
}
|
|
|
|
|
2016-05-17 19:31:31 +00:00
|
|
|
metric := heapster.MetricResult{
|
2016-07-25 21:34:05 +00:00
|
|
|
Metrics: []heapster.MetricPoint{{Timestamp: timestamp, Value: level, FloatValue: nil}},
|
2016-05-17 19:31:31 +00:00
|
|
|
LatestTimestamp: timestamp,
|
|
|
|
}
|
|
|
|
metrics.Items = append(metrics.Items, metric)
|
|
|
|
}
|
|
|
|
heapsterRawMemResponse, _ = json.Marshal(&metrics)
|
2015-09-14 08:14:32 +00:00
|
|
|
}
|
2016-05-17 19:31:31 +00:00
|
|
|
|
2015-09-14 08:14:32 +00:00
|
|
|
return true, newFakeResponseWrapper(heapsterRawMemResponse), nil
|
|
|
|
})
|
|
|
|
|
2016-03-09 00:27:13 +00:00
|
|
|
fakeClient.AddReactor("update", "replicationcontrollers", func(action core.Action) (handled bool, ret runtime.Object, err error) {
|
2016-04-20 16:57:36 +00:00
|
|
|
tc.Lock()
|
|
|
|
defer tc.Unlock()
|
|
|
|
|
2016-04-13 22:33:15 +00:00
|
|
|
obj := action.(core.UpdateAction).GetObject().(*extensions.Scale)
|
|
|
|
replicas := action.(core.UpdateAction).GetObject().(*extensions.Scale).Spec.Replicas
|
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
|
|
|
assert.Equal(t, tc.desiredReplicas, replicas, "the replica count of the RC should be as expected")
|
2016-03-09 00:27:13 +00:00
|
|
|
tc.scaleUpdated = true
|
|
|
|
return true, obj, nil
|
|
|
|
})
|
|
|
|
|
|
|
|
fakeClient.AddReactor("update", "deployments", func(action core.Action) (handled bool, ret runtime.Object, err error) {
|
2016-04-20 16:57:36 +00:00
|
|
|
tc.Lock()
|
|
|
|
defer tc.Unlock()
|
|
|
|
|
2016-04-13 22:33:15 +00:00
|
|
|
obj := action.(core.UpdateAction).GetObject().(*extensions.Scale)
|
|
|
|
replicas := action.(core.UpdateAction).GetObject().(*extensions.Scale).Spec.Replicas
|
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
|
|
|
assert.Equal(t, tc.desiredReplicas, replicas, "the replica count of the deployment should be as expected")
|
2016-03-09 00:27:13 +00:00
|
|
|
tc.scaleUpdated = true
|
|
|
|
return true, obj, nil
|
|
|
|
})
|
|
|
|
|
|
|
|
fakeClient.AddReactor("update", "replicasets", func(action core.Action) (handled bool, ret runtime.Object, err error) {
|
2016-04-20 16:57:36 +00:00
|
|
|
tc.Lock()
|
|
|
|
defer tc.Unlock()
|
|
|
|
|
2016-04-13 22:33:15 +00:00
|
|
|
obj := action.(core.UpdateAction).GetObject().(*extensions.Scale)
|
|
|
|
replicas := action.(core.UpdateAction).GetObject().(*extensions.Scale).Spec.Replicas
|
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
|
|
|
assert.Equal(t, tc.desiredReplicas, replicas, "the replica count of the replicaset should be as expected")
|
2015-09-14 08:14:32 +00:00
|
|
|
tc.scaleUpdated = true
|
|
|
|
return true, obj, nil
|
|
|
|
})
|
|
|
|
|
2016-01-29 06:34:08 +00:00
|
|
|
fakeClient.AddReactor("update", "horizontalpodautoscalers", func(action core.Action) (handled bool, ret runtime.Object, err error) {
|
2016-04-20 16:57:36 +00:00
|
|
|
tc.Lock()
|
|
|
|
defer tc.Unlock()
|
|
|
|
|
2016-05-05 10:27:24 +00:00
|
|
|
obj := action.(core.UpdateAction).GetObject().(*autoscaling.HorizontalPodAutoscaler)
|
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
|
|
|
assert.Equal(t, namespace, obj.Namespace, "the HPA namespace should be as expected")
|
|
|
|
assert.Equal(t, hpaName, obj.Name, "the HPA name should be as expected")
|
|
|
|
assert.Equal(t, tc.desiredReplicas, obj.Status.DesiredReplicas, "the desired replica count reported in the object status should be as expected")
|
2016-02-23 14:18:49 +00:00
|
|
|
if tc.verifyCPUCurrent {
|
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
|
|
|
assert.NotNil(t, obj.Status.CurrentCPUUtilizationPercentage, "the reported CPU utilization percentage should be non-nil")
|
|
|
|
assert.Equal(t, tc.CPUCurrent, *obj.Status.CurrentCPUUtilizationPercentage, "the report CPU utilization percentage should be as expected")
|
2016-02-23 14:18:49 +00:00
|
|
|
}
|
2016-03-02 08:29:17 +00:00
|
|
|
tc.statusUpdated = true
|
2016-03-02 09:08:17 +00:00
|
|
|
// Every time we reconcile HPA object we are updating status.
|
|
|
|
tc.processed <- obj.Name
|
2015-09-14 08:14:32 +00:00
|
|
|
return true, obj, nil
|
|
|
|
})
|
|
|
|
|
2016-01-29 06:34:08 +00:00
|
|
|
fakeClient.AddReactor("*", "events", func(action core.Action) (handled bool, ret runtime.Object, err error) {
|
2016-04-20 16:57:36 +00:00
|
|
|
tc.Lock()
|
|
|
|
defer tc.Unlock()
|
|
|
|
|
2016-11-18 20:50:17 +00:00
|
|
|
obj := action.(core.CreateAction).GetObject().(*v1.Event)
|
2015-09-14 08:14:32 +00:00
|
|
|
if tc.verifyEvents {
|
2016-10-17 15:14:15 +00:00
|
|
|
switch obj.Reason {
|
|
|
|
case "SuccessfulRescale":
|
|
|
|
assert.Equal(t, fmt.Sprintf("New size: %d; reason: CPU utilization above target", tc.desiredReplicas), obj.Message)
|
|
|
|
case "DesiredReplicasComputed":
|
|
|
|
assert.Equal(t, fmt.Sprintf(
|
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
|
|
|
"Computed the desired num of replicas: %d (avgCPUutil: %d, current replicas: %d)",
|
|
|
|
tc.desiredReplicas,
|
2016-10-17 15:14:15 +00:00
|
|
|
(int64(tc.reportedLevels[0])*100)/tc.reportedCPURequests[0].MilliValue(), tc.initialReplicas), obj.Message)
|
|
|
|
default:
|
|
|
|
assert.False(t, true, fmt.Sprintf("Unexpected event: %s / %s", obj.Reason, obj.Message))
|
|
|
|
}
|
2015-09-14 08:14:32 +00:00
|
|
|
}
|
|
|
|
tc.eventCreated = true
|
|
|
|
return true, obj, nil
|
|
|
|
})
|
|
|
|
|
2016-03-02 08:29:17 +00:00
|
|
|
fakeWatch := watch.NewFake()
|
|
|
|
fakeClient.AddWatchReactor("*", core.DefaultWatchReactor(fakeWatch, nil))
|
|
|
|
|
2015-09-14 08:14:32 +00:00
|
|
|
return fakeClient
|
2015-08-28 10:24:00 +00:00
|
|
|
}
|
|
|
|
|
2015-09-14 08:14:32 +00:00
|
|
|
func (tc *testCase) verifyResults(t *testing.T) {
|
2016-04-20 16:57:36 +00:00
|
|
|
tc.Lock()
|
|
|
|
defer tc.Unlock()
|
|
|
|
|
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
|
|
|
assert.Equal(t, tc.initialReplicas != tc.desiredReplicas, tc.scaleUpdated, "the scale should only be updated if we expected a change in replicas")
|
|
|
|
assert.True(t, tc.statusUpdated, "the status should have been updated")
|
2015-09-14 08:14:32 +00:00
|
|
|
if tc.verifyEvents {
|
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
|
|
|
assert.Equal(t, tc.initialReplicas != tc.desiredReplicas, tc.eventCreated, "an event should have been created only if we expected a change in replicas")
|
2015-08-28 10:24:00 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-09-14 08:14:32 +00:00
|
|
|
func (tc *testCase) runTest(t *testing.T) {
|
|
|
|
testClient := tc.prepareTestClient(t)
|
2015-11-06 17:55:31 +00:00
|
|
|
metricsClient := metrics.NewHeapsterMetricsClient(testClient, metrics.DefaultHeapsterNamespace, metrics.DefaultHeapsterScheme, metrics.DefaultHeapsterService, metrics.DefaultHeapsterPort)
|
2016-03-03 10:48:07 +00:00
|
|
|
|
|
|
|
broadcaster := record.NewBroadcasterForTests(0)
|
2016-11-18 20:50:17 +00:00
|
|
|
broadcaster.StartRecordingToSink(&v1core.EventSinkImpl{Interface: testClient.Core().Events("")})
|
|
|
|
recorder := broadcaster.NewRecorder(v1.EventSource{Component: "horizontal-pod-autoscaler"})
|
2016-03-03 10:48:07 +00:00
|
|
|
|
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
|
|
|
replicaCalc := &ReplicaCalculator{
|
|
|
|
metricsClient: metricsClient,
|
|
|
|
podsGetter: testClient.Core(),
|
|
|
|
}
|
|
|
|
|
2016-03-03 10:48:07 +00:00
|
|
|
hpaController := &HorizontalController{
|
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
|
|
|
replicaCalc: replicaCalc,
|
2016-03-03 10:48:07 +00:00
|
|
|
eventRecorder: recorder,
|
|
|
|
scaleNamespacer: testClient.Extensions(),
|
2016-05-05 10:27:24 +00:00
|
|
|
hpaNamespacer: testClient.Autoscaling(),
|
2016-03-03 10:48:07 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
store, frameworkController := newInformer(hpaController, time.Minute)
|
|
|
|
hpaController.store = store
|
|
|
|
hpaController.controller = frameworkController
|
|
|
|
|
2016-03-02 08:29:17 +00:00
|
|
|
stop := make(chan struct{})
|
|
|
|
defer close(stop)
|
|
|
|
go hpaController.Run(stop)
|
2016-03-03 10:48:07 +00:00
|
|
|
|
2016-04-20 16:57:36 +00:00
|
|
|
tc.Lock()
|
2015-09-14 08:14:32 +00:00
|
|
|
if tc.verifyEvents {
|
2016-04-20 16:57:36 +00:00
|
|
|
tc.Unlock()
|
2015-09-14 08:14:32 +00:00
|
|
|
// We need to wait for events to be broadcasted (sleep for longer than record.sleepDuration).
|
2016-03-03 10:48:07 +00:00
|
|
|
time.Sleep(2 * time.Second)
|
2016-04-20 16:57:36 +00:00
|
|
|
} else {
|
|
|
|
tc.Unlock()
|
2015-09-14 08:14:32 +00:00
|
|
|
}
|
2016-03-02 09:08:17 +00:00
|
|
|
// Wait for HPA to be processed.
|
|
|
|
<-tc.processed
|
2015-09-14 08:14:32 +00:00
|
|
|
tc.verifyResults(t)
|
|
|
|
}
|
2015-08-20 12:55:28 +00:00
|
|
|
|
2016-03-09 00:27:13 +00:00
|
|
|
func TestDefaultScaleUpRC(t *testing.T) {
|
2016-02-29 11:02:54 +00:00
|
|
|
tc := testCase{
|
|
|
|
minReplicas: 2,
|
|
|
|
maxReplicas: 6,
|
|
|
|
initialReplicas: 4,
|
|
|
|
desiredReplicas: 5,
|
|
|
|
verifyCPUCurrent: true,
|
|
|
|
reportedLevels: []uint64{900, 950, 950, 1000},
|
|
|
|
reportedCPURequests: []resource.Quantity{resource.MustParse("1.0"), resource.MustParse("1.0"), resource.MustParse("1.0"), resource.MustParse("1.0")},
|
2016-05-17 19:31:31 +00:00
|
|
|
useMetricsApi: true,
|
2016-02-29 11:02:54 +00:00
|
|
|
}
|
|
|
|
tc.runTest(t)
|
|
|
|
}
|
|
|
|
|
2016-03-09 00:27:13 +00:00
|
|
|
func TestDefaultScaleUpDeployment(t *testing.T) {
|
|
|
|
tc := testCase{
|
|
|
|
minReplicas: 2,
|
|
|
|
maxReplicas: 6,
|
|
|
|
initialReplicas: 4,
|
|
|
|
desiredReplicas: 5,
|
|
|
|
verifyCPUCurrent: true,
|
|
|
|
reportedLevels: []uint64{900, 950, 950, 1000},
|
|
|
|
reportedCPURequests: []resource.Quantity{resource.MustParse("1.0"), resource.MustParse("1.0"), resource.MustParse("1.0"), resource.MustParse("1.0")},
|
2016-05-17 19:31:31 +00:00
|
|
|
useMetricsApi: true,
|
2016-03-09 00:27:13 +00:00
|
|
|
resource: &fakeResource{
|
|
|
|
name: "test-dep",
|
|
|
|
apiVersion: "extensions/v1beta1",
|
|
|
|
kind: "deployments",
|
|
|
|
},
|
|
|
|
}
|
|
|
|
tc.runTest(t)
|
|
|
|
}
|
|
|
|
|
|
|
|
func TestDefaultScaleUpReplicaSet(t *testing.T) {
|
|
|
|
tc := testCase{
|
|
|
|
minReplicas: 2,
|
|
|
|
maxReplicas: 6,
|
|
|
|
initialReplicas: 4,
|
|
|
|
desiredReplicas: 5,
|
|
|
|
verifyCPUCurrent: true,
|
|
|
|
reportedLevels: []uint64{900, 950, 950, 1000},
|
|
|
|
reportedCPURequests: []resource.Quantity{resource.MustParse("1.0"), resource.MustParse("1.0"), resource.MustParse("1.0"), resource.MustParse("1.0")},
|
2016-05-17 19:31:31 +00:00
|
|
|
useMetricsApi: true,
|
2016-03-09 00:27:13 +00:00
|
|
|
resource: &fakeResource{
|
|
|
|
name: "test-replicaset",
|
|
|
|
apiVersion: "extensions/v1beta1",
|
|
|
|
kind: "replicasets",
|
|
|
|
},
|
|
|
|
}
|
|
|
|
tc.runTest(t)
|
|
|
|
}
|
|
|
|
|
2015-09-14 08:14:32 +00:00
|
|
|
func TestScaleUp(t *testing.T) {
|
|
|
|
tc := testCase{
|
2015-10-13 15:24:23 +00:00
|
|
|
minReplicas: 2,
|
|
|
|
maxReplicas: 6,
|
|
|
|
initialReplicas: 3,
|
|
|
|
desiredReplicas: 5,
|
|
|
|
CPUTarget: 30,
|
2016-02-23 14:18:49 +00:00
|
|
|
verifyCPUCurrent: true,
|
2015-10-13 15:24:23 +00:00
|
|
|
reportedLevels: []uint64{300, 500, 700},
|
|
|
|
reportedCPURequests: []resource.Quantity{resource.MustParse("1.0"), resource.MustParse("1.0"), resource.MustParse("1.0")},
|
2016-05-17 19:31:31 +00:00
|
|
|
useMetricsApi: true,
|
2015-08-25 17:16:47 +00:00
|
|
|
}
|
2015-09-14 08:14:32 +00:00
|
|
|
tc.runTest(t)
|
|
|
|
}
|
2015-08-25 17:16:47 +00:00
|
|
|
|
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
|
|
|
func TestScaleUpUnreadyLessScale(t *testing.T) {
|
|
|
|
tc := testCase{
|
|
|
|
minReplicas: 2,
|
|
|
|
maxReplicas: 6,
|
|
|
|
initialReplicas: 3,
|
|
|
|
desiredReplicas: 4,
|
|
|
|
CPUTarget: 30,
|
|
|
|
CPUCurrent: 60,
|
|
|
|
verifyCPUCurrent: true,
|
|
|
|
reportedLevels: []uint64{300, 500, 700},
|
|
|
|
reportedCPURequests: []resource.Quantity{resource.MustParse("1.0"), resource.MustParse("1.0"), resource.MustParse("1.0")},
|
2016-11-18 20:50:17 +00:00
|
|
|
reportedPodReadiness: []v1.ConditionStatus{v1.ConditionFalse, v1.ConditionTrue, v1.ConditionTrue},
|
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
|
|
|
useMetricsApi: true,
|
|
|
|
}
|
|
|
|
tc.runTest(t)
|
|
|
|
}
|
|
|
|
|
|
|
|
func TestScaleUpUnreadyNoScale(t *testing.T) {
|
|
|
|
tc := testCase{
|
|
|
|
minReplicas: 2,
|
|
|
|
maxReplicas: 6,
|
|
|
|
initialReplicas: 3,
|
|
|
|
desiredReplicas: 3,
|
|
|
|
CPUTarget: 30,
|
|
|
|
CPUCurrent: 40,
|
|
|
|
verifyCPUCurrent: true,
|
|
|
|
reportedLevels: []uint64{400, 500, 700},
|
|
|
|
reportedCPURequests: []resource.Quantity{resource.MustParse("1.0"), resource.MustParse("1.0"), resource.MustParse("1.0")},
|
2016-11-18 20:50:17 +00:00
|
|
|
reportedPodReadiness: []v1.ConditionStatus{v1.ConditionTrue, v1.ConditionFalse, v1.ConditionFalse},
|
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
|
|
|
useMetricsApi: true,
|
|
|
|
}
|
|
|
|
tc.runTest(t)
|
|
|
|
}
|
|
|
|
|
2016-03-09 00:27:13 +00:00
|
|
|
func TestScaleUpDeployment(t *testing.T) {
|
|
|
|
tc := testCase{
|
|
|
|
minReplicas: 2,
|
|
|
|
maxReplicas: 6,
|
|
|
|
initialReplicas: 3,
|
|
|
|
desiredReplicas: 5,
|
|
|
|
CPUTarget: 30,
|
|
|
|
verifyCPUCurrent: true,
|
|
|
|
reportedLevels: []uint64{300, 500, 700},
|
|
|
|
reportedCPURequests: []resource.Quantity{resource.MustParse("1.0"), resource.MustParse("1.0"), resource.MustParse("1.0")},
|
2016-05-17 19:31:31 +00:00
|
|
|
useMetricsApi: true,
|
2016-03-09 00:27:13 +00:00
|
|
|
resource: &fakeResource{
|
|
|
|
name: "test-dep",
|
|
|
|
apiVersion: "extensions/v1beta1",
|
|
|
|
kind: "deployments",
|
|
|
|
},
|
|
|
|
}
|
|
|
|
tc.runTest(t)
|
|
|
|
}
|
|
|
|
|
|
|
|
func TestScaleUpReplicaSet(t *testing.T) {
|
|
|
|
tc := testCase{
|
|
|
|
minReplicas: 2,
|
|
|
|
maxReplicas: 6,
|
|
|
|
initialReplicas: 3,
|
|
|
|
desiredReplicas: 5,
|
|
|
|
CPUTarget: 30,
|
|
|
|
verifyCPUCurrent: true,
|
|
|
|
reportedLevels: []uint64{300, 500, 700},
|
|
|
|
reportedCPURequests: []resource.Quantity{resource.MustParse("1.0"), resource.MustParse("1.0"), resource.MustParse("1.0")},
|
2016-05-17 19:31:31 +00:00
|
|
|
useMetricsApi: true,
|
2016-03-09 00:27:13 +00:00
|
|
|
resource: &fakeResource{
|
|
|
|
name: "test-replicaset",
|
|
|
|
apiVersion: "extensions/v1beta1",
|
|
|
|
kind: "replicasets",
|
|
|
|
},
|
|
|
|
}
|
|
|
|
tc.runTest(t)
|
|
|
|
}
|
|
|
|
|
2016-01-29 11:20:19 +00:00
|
|
|
func TestScaleUpCM(t *testing.T) {
|
|
|
|
tc := testCase{
|
|
|
|
minReplicas: 2,
|
|
|
|
maxReplicas: 6,
|
|
|
|
initialReplicas: 3,
|
|
|
|
desiredReplicas: 4,
|
|
|
|
CPUTarget: 0,
|
|
|
|
cmTarget: &extensions.CustomMetricTargetList{
|
|
|
|
Items: []extensions.CustomMetricTarget{{
|
|
|
|
Name: "qps",
|
|
|
|
TargetValue: resource.MustParse("15.0"),
|
|
|
|
}},
|
|
|
|
},
|
|
|
|
reportedLevels: []uint64{20, 10, 30},
|
|
|
|
reportedCPURequests: []resource.Quantity{resource.MustParse("1.0"), resource.MustParse("1.0"), resource.MustParse("1.0")},
|
|
|
|
}
|
|
|
|
tc.runTest(t)
|
|
|
|
}
|
|
|
|
|
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
|
|
|
func TestScaleUpCMUnreadyLessScale(t *testing.T) {
|
|
|
|
tc := testCase{
|
|
|
|
minReplicas: 2,
|
|
|
|
maxReplicas: 6,
|
|
|
|
initialReplicas: 3,
|
|
|
|
desiredReplicas: 4,
|
|
|
|
CPUTarget: 0,
|
|
|
|
cmTarget: &extensions.CustomMetricTargetList{
|
|
|
|
Items: []extensions.CustomMetricTarget{{
|
|
|
|
Name: "qps",
|
|
|
|
TargetValue: resource.MustParse("15.0"),
|
|
|
|
}},
|
|
|
|
},
|
|
|
|
reportedLevels: []uint64{50, 10, 30},
|
2016-11-18 20:50:17 +00:00
|
|
|
reportedPodReadiness: []v1.ConditionStatus{v1.ConditionTrue, v1.ConditionTrue, v1.ConditionFalse},
|
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
|
|
|
reportedCPURequests: []resource.Quantity{resource.MustParse("1.0"), resource.MustParse("1.0"), resource.MustParse("1.0")},
|
|
|
|
}
|
|
|
|
tc.runTest(t)
|
|
|
|
}
|
|
|
|
|
|
|
|
func TestScaleUpCMUnreadyNoScaleWouldScaleDown(t *testing.T) {
|
|
|
|
tc := testCase{
|
|
|
|
minReplicas: 2,
|
|
|
|
maxReplicas: 6,
|
|
|
|
initialReplicas: 3,
|
|
|
|
desiredReplicas: 3,
|
|
|
|
CPUTarget: 0,
|
|
|
|
cmTarget: &extensions.CustomMetricTargetList{
|
|
|
|
Items: []extensions.CustomMetricTarget{{
|
|
|
|
Name: "qps",
|
|
|
|
TargetValue: resource.MustParse("15.0"),
|
|
|
|
}},
|
|
|
|
},
|
|
|
|
reportedLevels: []uint64{50, 15, 30},
|
2016-11-18 20:50:17 +00:00
|
|
|
reportedPodReadiness: []v1.ConditionStatus{v1.ConditionFalse, v1.ConditionTrue, v1.ConditionFalse},
|
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
|
|
|
reportedCPURequests: []resource.Quantity{resource.MustParse("1.0"), resource.MustParse("1.0"), resource.MustParse("1.0")},
|
|
|
|
}
|
|
|
|
tc.runTest(t)
|
|
|
|
}
|
|
|
|
|
2016-02-29 11:02:54 +00:00
|
|
|
func TestDefaultScaleDown(t *testing.T) {
|
|
|
|
tc := testCase{
|
|
|
|
minReplicas: 2,
|
|
|
|
maxReplicas: 6,
|
|
|
|
initialReplicas: 5,
|
|
|
|
desiredReplicas: 4,
|
|
|
|
verifyCPUCurrent: true,
|
|
|
|
reportedLevels: []uint64{400, 500, 600, 700, 800},
|
|
|
|
reportedCPURequests: []resource.Quantity{resource.MustParse("1.0"), resource.MustParse("1.0"), resource.MustParse("1.0"), resource.MustParse("1.0"), resource.MustParse("1.0")},
|
2016-05-17 19:31:31 +00:00
|
|
|
useMetricsApi: true,
|
2016-02-29 11:02:54 +00:00
|
|
|
}
|
|
|
|
tc.runTest(t)
|
|
|
|
}
|
|
|
|
|
2015-09-14 08:14:32 +00:00
|
|
|
func TestScaleDown(t *testing.T) {
|
|
|
|
tc := testCase{
|
2015-10-13 15:24:23 +00:00
|
|
|
minReplicas: 2,
|
|
|
|
maxReplicas: 6,
|
|
|
|
initialReplicas: 5,
|
|
|
|
desiredReplicas: 3,
|
|
|
|
CPUTarget: 50,
|
2016-02-23 14:18:49 +00:00
|
|
|
verifyCPUCurrent: true,
|
2015-10-13 15:24:23 +00:00
|
|
|
reportedLevels: []uint64{100, 300, 500, 250, 250},
|
|
|
|
reportedCPURequests: []resource.Quantity{resource.MustParse("1.0"), resource.MustParse("1.0"), resource.MustParse("1.0"), resource.MustParse("1.0"), resource.MustParse("1.0")},
|
2016-05-17 19:31:31 +00:00
|
|
|
useMetricsApi: true,
|
2015-08-25 17:16:47 +00:00
|
|
|
}
|
2015-09-14 08:14:32 +00:00
|
|
|
tc.runTest(t)
|
|
|
|
}
|
2015-08-25 17:16:47 +00:00
|
|
|
|
2016-01-29 11:20:19 +00:00
|
|
|
func TestScaleDownCM(t *testing.T) {
|
|
|
|
tc := testCase{
|
|
|
|
minReplicas: 2,
|
|
|
|
maxReplicas: 6,
|
|
|
|
initialReplicas: 5,
|
|
|
|
desiredReplicas: 3,
|
|
|
|
CPUTarget: 0,
|
|
|
|
cmTarget: &extensions.CustomMetricTargetList{
|
|
|
|
Items: []extensions.CustomMetricTarget{{
|
|
|
|
Name: "qps",
|
|
|
|
TargetValue: resource.MustParse("20"),
|
|
|
|
}}},
|
|
|
|
reportedLevels: []uint64{12, 12, 12, 12, 12},
|
|
|
|
reportedCPURequests: []resource.Quantity{resource.MustParse("1.0"), resource.MustParse("1.0"), resource.MustParse("1.0"), resource.MustParse("1.0"), resource.MustParse("1.0")},
|
|
|
|
}
|
|
|
|
tc.runTest(t)
|
|
|
|
}
|
|
|
|
|
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
|
|
|
func TestScaleDownIgnoresUnreadyPods(t *testing.T) {
|
|
|
|
tc := testCase{
|
|
|
|
minReplicas: 2,
|
|
|
|
maxReplicas: 6,
|
|
|
|
initialReplicas: 5,
|
|
|
|
desiredReplicas: 2,
|
|
|
|
CPUTarget: 50,
|
|
|
|
CPUCurrent: 30,
|
|
|
|
verifyCPUCurrent: true,
|
|
|
|
reportedLevels: []uint64{100, 300, 500, 250, 250},
|
|
|
|
reportedCPURequests: []resource.Quantity{resource.MustParse("1.0"), resource.MustParse("1.0"), resource.MustParse("1.0"), resource.MustParse("1.0"), resource.MustParse("1.0")},
|
|
|
|
useMetricsApi: true,
|
2016-11-18 20:50:17 +00:00
|
|
|
reportedPodReadiness: []v1.ConditionStatus{v1.ConditionTrue, v1.ConditionTrue, v1.ConditionTrue, v1.ConditionFalse, v1.ConditionFalse},
|
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
|
|
|
}
|
|
|
|
tc.runTest(t)
|
|
|
|
}
|
|
|
|
|
2015-09-14 08:14:32 +00:00
|
|
|
func TestTolerance(t *testing.T) {
|
|
|
|
tc := testCase{
|
2015-10-13 15:24:23 +00:00
|
|
|
minReplicas: 1,
|
|
|
|
maxReplicas: 5,
|
|
|
|
initialReplicas: 3,
|
|
|
|
desiredReplicas: 3,
|
|
|
|
CPUTarget: 100,
|
|
|
|
reportedLevels: []uint64{1010, 1030, 1020},
|
|
|
|
reportedCPURequests: []resource.Quantity{resource.MustParse("0.9"), resource.MustParse("1.0"), resource.MustParse("1.1")},
|
2016-05-17 19:31:31 +00:00
|
|
|
useMetricsApi: true,
|
2016-01-29 11:20:19 +00:00
|
|
|
}
|
|
|
|
tc.runTest(t)
|
|
|
|
}
|
|
|
|
|
|
|
|
func TestToleranceCM(t *testing.T) {
|
|
|
|
tc := testCase{
|
|
|
|
minReplicas: 1,
|
|
|
|
maxReplicas: 5,
|
|
|
|
initialReplicas: 3,
|
|
|
|
desiredReplicas: 3,
|
|
|
|
cmTarget: &extensions.CustomMetricTargetList{
|
|
|
|
Items: []extensions.CustomMetricTarget{{
|
|
|
|
Name: "qps",
|
|
|
|
TargetValue: resource.MustParse("20"),
|
|
|
|
}}},
|
|
|
|
reportedLevels: []uint64{20, 21, 21},
|
|
|
|
reportedCPURequests: []resource.Quantity{resource.MustParse("0.9"), resource.MustParse("1.0"), resource.MustParse("1.1")},
|
2015-08-25 17:16:47 +00:00
|
|
|
}
|
2015-09-14 08:14:32 +00:00
|
|
|
tc.runTest(t)
|
|
|
|
}
|
2015-08-20 12:55:28 +00:00
|
|
|
|
2015-09-17 12:08:39 +00:00
|
|
|
func TestMinReplicas(t *testing.T) {
|
2015-09-14 08:14:32 +00:00
|
|
|
tc := testCase{
|
2015-10-13 15:24:23 +00:00
|
|
|
minReplicas: 2,
|
|
|
|
maxReplicas: 5,
|
|
|
|
initialReplicas: 3,
|
|
|
|
desiredReplicas: 2,
|
|
|
|
CPUTarget: 90,
|
|
|
|
reportedLevels: []uint64{10, 95, 10},
|
|
|
|
reportedCPURequests: []resource.Quantity{resource.MustParse("0.9"), resource.MustParse("1.0"), resource.MustParse("1.1")},
|
2016-05-17 19:31:31 +00:00
|
|
|
useMetricsApi: true,
|
2015-09-14 13:08:43 +00:00
|
|
|
}
|
2015-09-14 08:14:32 +00:00
|
|
|
tc.runTest(t)
|
|
|
|
}
|
2015-09-14 13:08:43 +00:00
|
|
|
|
2016-02-12 15:26:59 +00:00
|
|
|
func TestZeroReplicas(t *testing.T) {
|
|
|
|
tc := testCase{
|
|
|
|
minReplicas: 3,
|
|
|
|
maxReplicas: 5,
|
|
|
|
initialReplicas: 0,
|
2016-07-19 15:54:38 +00:00
|
|
|
desiredReplicas: 0,
|
2016-02-12 15:26:59 +00:00
|
|
|
CPUTarget: 90,
|
|
|
|
reportedLevels: []uint64{},
|
|
|
|
reportedCPURequests: []resource.Quantity{},
|
2016-05-17 19:31:31 +00:00
|
|
|
useMetricsApi: true,
|
2016-02-12 15:26:59 +00:00
|
|
|
}
|
|
|
|
tc.runTest(t)
|
|
|
|
}
|
|
|
|
|
2016-02-23 14:18:49 +00:00
|
|
|
func TestTooFewReplicas(t *testing.T) {
|
2016-02-12 15:26:59 +00:00
|
|
|
tc := testCase{
|
|
|
|
minReplicas: 3,
|
|
|
|
maxReplicas: 5,
|
|
|
|
initialReplicas: 2,
|
|
|
|
desiredReplicas: 3,
|
|
|
|
CPUTarget: 90,
|
|
|
|
reportedLevels: []uint64{},
|
|
|
|
reportedCPURequests: []resource.Quantity{},
|
2016-05-17 19:31:31 +00:00
|
|
|
useMetricsApi: true,
|
2016-02-12 15:26:59 +00:00
|
|
|
}
|
|
|
|
tc.runTest(t)
|
|
|
|
}
|
|
|
|
|
|
|
|
func TestTooManyReplicas(t *testing.T) {
|
|
|
|
tc := testCase{
|
|
|
|
minReplicas: 3,
|
|
|
|
maxReplicas: 5,
|
|
|
|
initialReplicas: 10,
|
|
|
|
desiredReplicas: 5,
|
|
|
|
CPUTarget: 90,
|
|
|
|
reportedLevels: []uint64{},
|
|
|
|
reportedCPURequests: []resource.Quantity{},
|
2016-05-17 19:31:31 +00:00
|
|
|
useMetricsApi: true,
|
2016-02-12 15:26:59 +00:00
|
|
|
}
|
|
|
|
tc.runTest(t)
|
|
|
|
}
|
|
|
|
|
2015-09-17 12:08:39 +00:00
|
|
|
func TestMaxReplicas(t *testing.T) {
|
2015-09-14 08:14:32 +00:00
|
|
|
tc := testCase{
|
2015-10-13 15:24:23 +00:00
|
|
|
minReplicas: 2,
|
|
|
|
maxReplicas: 5,
|
|
|
|
initialReplicas: 3,
|
|
|
|
desiredReplicas: 5,
|
|
|
|
CPUTarget: 90,
|
|
|
|
reportedLevels: []uint64{8000, 9500, 1000},
|
|
|
|
reportedCPURequests: []resource.Quantity{resource.MustParse("0.9"), resource.MustParse("1.0"), resource.MustParse("1.1")},
|
2016-05-17 19:31:31 +00:00
|
|
|
useMetricsApi: true,
|
2015-09-14 08:14:32 +00:00
|
|
|
}
|
|
|
|
tc.runTest(t)
|
2015-08-20 12:55:28 +00:00
|
|
|
}
|
|
|
|
|
2015-09-14 08:14:32 +00:00
|
|
|
func TestSuperfluousMetrics(t *testing.T) {
|
|
|
|
tc := testCase{
|
2015-10-13 15:24:23 +00:00
|
|
|
minReplicas: 2,
|
|
|
|
maxReplicas: 6,
|
|
|
|
initialReplicas: 4,
|
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
|
|
|
desiredReplicas: 6,
|
2015-10-13 15:24:23 +00:00
|
|
|
CPUTarget: 100,
|
|
|
|
reportedLevels: []uint64{4000, 9500, 3000, 7000, 3200, 2000},
|
|
|
|
reportedCPURequests: []resource.Quantity{resource.MustParse("1.0"), resource.MustParse("1.0"), resource.MustParse("1.0"), resource.MustParse("1.0")},
|
2016-05-17 19:31:31 +00:00
|
|
|
useMetricsApi: true,
|
2015-08-26 14:17:18 +00:00
|
|
|
}
|
2015-09-14 08:14:32 +00:00
|
|
|
tc.runTest(t)
|
|
|
|
}
|
2015-08-28 10:24:00 +00:00
|
|
|
|
2015-09-14 08:14:32 +00:00
|
|
|
func TestMissingMetrics(t *testing.T) {
|
|
|
|
tc := testCase{
|
2015-10-13 15:24:23 +00:00
|
|
|
minReplicas: 2,
|
|
|
|
maxReplicas: 6,
|
|
|
|
initialReplicas: 4,
|
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
|
|
|
desiredReplicas: 3,
|
2015-10-13 15:24:23 +00:00
|
|
|
CPUTarget: 100,
|
|
|
|
reportedLevels: []uint64{400, 95},
|
|
|
|
reportedCPURequests: []resource.Quantity{resource.MustParse("1.0"), resource.MustParse("1.0"), resource.MustParse("1.0"), resource.MustParse("1.0")},
|
2016-05-17 19:31:31 +00:00
|
|
|
useMetricsApi: true,
|
2015-08-20 12:55:28 +00:00
|
|
|
}
|
2015-09-14 08:14:32 +00:00
|
|
|
tc.runTest(t)
|
|
|
|
}
|
|
|
|
|
|
|
|
func TestEmptyMetrics(t *testing.T) {
|
|
|
|
tc := testCase{
|
2015-10-13 15:24:23 +00:00
|
|
|
minReplicas: 2,
|
|
|
|
maxReplicas: 6,
|
|
|
|
initialReplicas: 4,
|
|
|
|
desiredReplicas: 4,
|
|
|
|
CPUTarget: 100,
|
|
|
|
reportedLevels: []uint64{},
|
|
|
|
reportedCPURequests: []resource.Quantity{resource.MustParse("1.0"), resource.MustParse("1.0"), resource.MustParse("1.0"), resource.MustParse("1.0")},
|
2016-05-17 19:31:31 +00:00
|
|
|
useMetricsApi: true,
|
2015-08-20 12:55:28 +00:00
|
|
|
}
|
2015-09-14 08:14:32 +00:00
|
|
|
tc.runTest(t)
|
|
|
|
}
|
|
|
|
|
2015-10-13 15:24:23 +00:00
|
|
|
func TestEmptyCPURequest(t *testing.T) {
|
2015-09-14 08:14:32 +00:00
|
|
|
tc := testCase{
|
2015-09-17 12:08:39 +00:00
|
|
|
minReplicas: 1,
|
|
|
|
maxReplicas: 5,
|
2015-09-14 08:14:32 +00:00
|
|
|
initialReplicas: 1,
|
2015-10-13 15:24:23 +00:00
|
|
|
desiredReplicas: 1,
|
|
|
|
CPUTarget: 100,
|
2015-09-14 08:14:32 +00:00
|
|
|
reportedLevels: []uint64{200},
|
2016-05-17 19:31:31 +00:00
|
|
|
useMetricsApi: true,
|
2015-10-13 15:24:23 +00:00
|
|
|
}
|
|
|
|
tc.runTest(t)
|
|
|
|
}
|
|
|
|
|
|
|
|
func TestEventCreated(t *testing.T) {
|
|
|
|
tc := testCase{
|
|
|
|
minReplicas: 1,
|
|
|
|
maxReplicas: 5,
|
|
|
|
initialReplicas: 1,
|
|
|
|
desiredReplicas: 2,
|
|
|
|
CPUTarget: 50,
|
|
|
|
reportedLevels: []uint64{200},
|
|
|
|
reportedCPURequests: []resource.Quantity{resource.MustParse("0.2")},
|
|
|
|
verifyEvents: true,
|
2016-05-17 19:31:31 +00:00
|
|
|
useMetricsApi: true,
|
2015-08-25 17:16:47 +00:00
|
|
|
}
|
2015-09-14 08:14:32 +00:00
|
|
|
tc.runTest(t)
|
|
|
|
}
|
2015-08-25 17:16:47 +00:00
|
|
|
|
2015-09-14 08:14:32 +00:00
|
|
|
func TestEventNotCreated(t *testing.T) {
|
|
|
|
tc := testCase{
|
2015-10-13 15:24:23 +00:00
|
|
|
minReplicas: 1,
|
|
|
|
maxReplicas: 5,
|
|
|
|
initialReplicas: 2,
|
|
|
|
desiredReplicas: 2,
|
|
|
|
CPUTarget: 50,
|
|
|
|
reportedLevels: []uint64{200, 200},
|
|
|
|
reportedCPURequests: []resource.Quantity{resource.MustParse("0.4"), resource.MustParse("0.4")},
|
|
|
|
verifyEvents: true,
|
2016-05-17 19:31:31 +00:00
|
|
|
useMetricsApi: true,
|
2015-09-14 08:14:32 +00:00
|
|
|
}
|
|
|
|
tc.runTest(t)
|
2015-08-20 12:55:28 +00:00
|
|
|
}
|
2015-10-13 15:24:23 +00:00
|
|
|
|
2016-10-17 15:14:15 +00:00
|
|
|
func TestMissingReports(t *testing.T) {
|
|
|
|
tc := testCase{
|
|
|
|
minReplicas: 1,
|
|
|
|
maxReplicas: 5,
|
|
|
|
initialReplicas: 4,
|
|
|
|
desiredReplicas: 2,
|
|
|
|
CPUTarget: 50,
|
|
|
|
reportedLevels: []uint64{200},
|
|
|
|
reportedCPURequests: []resource.Quantity{resource.MustParse("0.2")},
|
|
|
|
useMetricsApi: true,
|
|
|
|
}
|
|
|
|
tc.runTest(t)
|
|
|
|
}
|
|
|
|
|
|
|
|
func TestUpscaleCap(t *testing.T) {
|
|
|
|
tc := testCase{
|
|
|
|
minReplicas: 1,
|
|
|
|
maxReplicas: 100,
|
|
|
|
initialReplicas: 3,
|
|
|
|
desiredReplicas: 6,
|
|
|
|
CPUTarget: 10,
|
|
|
|
reportedLevels: []uint64{100, 200, 300},
|
|
|
|
reportedCPURequests: []resource.Quantity{resource.MustParse("0.1"), resource.MustParse("0.1"), resource.MustParse("0.1")},
|
|
|
|
useMetricsApi: true,
|
|
|
|
}
|
|
|
|
tc.runTest(t)
|
|
|
|
}
|
|
|
|
|
2016-05-06 21:52:30 +00:00
|
|
|
// TestComputedToleranceAlgImplementation is a regression test which
|
|
|
|
// back-calculates a minimal percentage for downscaling based on a small percentage
|
|
|
|
// increase in pod utilization which is calibrated against the tolerance value.
|
|
|
|
func TestComputedToleranceAlgImplementation(t *testing.T) {
|
|
|
|
|
|
|
|
startPods := int32(10)
|
|
|
|
// 150 mCPU per pod.
|
|
|
|
totalUsedCPUOfAllPods := uint64(startPods * 150)
|
|
|
|
// Each pod starts out asking for 2X what is really needed.
|
|
|
|
// This means we will have a 50% ratio of used/requested
|
|
|
|
totalRequestedCPUOfAllPods := int32(2 * totalUsedCPUOfAllPods)
|
|
|
|
requestedToUsed := float64(totalRequestedCPUOfAllPods / int32(totalUsedCPUOfAllPods))
|
|
|
|
// Spread the amount we ask over 10 pods. We can add some jitter later in reportedLevels.
|
|
|
|
perPodRequested := totalRequestedCPUOfAllPods / startPods
|
|
|
|
|
|
|
|
// Force a minimal scaling event by satisfying (tolerance < 1 - resourcesUsedRatio).
|
|
|
|
target := math.Abs(1/(requestedToUsed*(1-tolerance))) + .01
|
|
|
|
finalCpuPercentTarget := int32(target * 100)
|
|
|
|
resourcesUsedRatio := float64(totalUsedCPUOfAllPods) / float64(float64(totalRequestedCPUOfAllPods)*target)
|
|
|
|
|
|
|
|
// i.e. .60 * 20 -> scaled down expectation.
|
|
|
|
finalPods := int32(math.Ceil(resourcesUsedRatio * float64(startPods)))
|
|
|
|
|
|
|
|
// To breach tolerance we will create a utilization ratio difference of tolerance to usageRatioToleranceValue)
|
|
|
|
tc := testCase{
|
|
|
|
minReplicas: 0,
|
|
|
|
maxReplicas: 1000,
|
|
|
|
initialReplicas: startPods,
|
|
|
|
desiredReplicas: finalPods,
|
|
|
|
CPUTarget: finalCpuPercentTarget,
|
|
|
|
reportedLevels: []uint64{
|
|
|
|
totalUsedCPUOfAllPods / 10,
|
|
|
|
totalUsedCPUOfAllPods / 10,
|
|
|
|
totalUsedCPUOfAllPods / 10,
|
|
|
|
totalUsedCPUOfAllPods / 10,
|
|
|
|
totalUsedCPUOfAllPods / 10,
|
|
|
|
totalUsedCPUOfAllPods / 10,
|
|
|
|
totalUsedCPUOfAllPods / 10,
|
|
|
|
totalUsedCPUOfAllPods / 10,
|
|
|
|
totalUsedCPUOfAllPods / 10,
|
|
|
|
totalUsedCPUOfAllPods / 10,
|
|
|
|
},
|
|
|
|
reportedCPURequests: []resource.Quantity{
|
|
|
|
resource.MustParse(fmt.Sprint(perPodRequested+100) + "m"),
|
|
|
|
resource.MustParse(fmt.Sprint(perPodRequested-100) + "m"),
|
|
|
|
resource.MustParse(fmt.Sprint(perPodRequested+10) + "m"),
|
|
|
|
resource.MustParse(fmt.Sprint(perPodRequested-10) + "m"),
|
|
|
|
resource.MustParse(fmt.Sprint(perPodRequested+2) + "m"),
|
|
|
|
resource.MustParse(fmt.Sprint(perPodRequested-2) + "m"),
|
|
|
|
resource.MustParse(fmt.Sprint(perPodRequested+1) + "m"),
|
|
|
|
resource.MustParse(fmt.Sprint(perPodRequested-1) + "m"),
|
|
|
|
resource.MustParse(fmt.Sprint(perPodRequested) + "m"),
|
|
|
|
resource.MustParse(fmt.Sprint(perPodRequested) + "m"),
|
|
|
|
},
|
2016-05-17 19:31:31 +00:00
|
|
|
useMetricsApi: true,
|
2016-05-06 21:52:30 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
tc.runTest(t)
|
|
|
|
|
|
|
|
// Reuse the data structure above, now testing "unscaling".
|
|
|
|
// Now, we test that no scaling happens if we are in a very close margin to the tolerance
|
|
|
|
target = math.Abs(1/(requestedToUsed*(1-tolerance))) + .004
|
|
|
|
finalCpuPercentTarget = int32(target * 100)
|
|
|
|
tc.CPUTarget = finalCpuPercentTarget
|
|
|
|
tc.initialReplicas = startPods
|
|
|
|
tc.desiredReplicas = startPods
|
|
|
|
tc.runTest(t)
|
|
|
|
}
|
|
|
|
|
2016-11-21 09:32:00 +00:00
|
|
|
func TestScaleUpRCImmediately(t *testing.T) {
|
2016-12-03 18:57:26 +00:00
|
|
|
time := metav1.Time{Time: time.Now()}
|
2016-11-21 09:32:00 +00:00
|
|
|
tc := testCase{
|
|
|
|
minReplicas: 2,
|
|
|
|
maxReplicas: 6,
|
|
|
|
initialReplicas: 1,
|
|
|
|
desiredReplicas: 2,
|
|
|
|
verifyCPUCurrent: true,
|
|
|
|
reportedLevels: []uint64{0, 0, 0, 0},
|
|
|
|
reportedCPURequests: []resource.Quantity{resource.MustParse("1.0"), resource.MustParse("1.0"), resource.MustParse("1.0"), resource.MustParse("1.0")},
|
|
|
|
useMetricsApi: true,
|
|
|
|
lastScaleTime: &time,
|
|
|
|
}
|
|
|
|
tc.runTest(t)
|
|
|
|
}
|
|
|
|
|
|
|
|
func TestScaleDownRCImmediately(t *testing.T) {
|
2016-12-03 18:57:26 +00:00
|
|
|
time := metav1.Time{Time: time.Now()}
|
2016-11-21 09:32:00 +00:00
|
|
|
tc := testCase{
|
|
|
|
minReplicas: 2,
|
|
|
|
maxReplicas: 5,
|
|
|
|
initialReplicas: 6,
|
|
|
|
desiredReplicas: 5,
|
|
|
|
CPUTarget: 50,
|
|
|
|
reportedLevels: []uint64{8000, 9500, 1000},
|
|
|
|
reportedCPURequests: []resource.Quantity{resource.MustParse("0.9"), resource.MustParse("1.0"), resource.MustParse("1.1")},
|
|
|
|
useMetricsApi: true,
|
|
|
|
lastScaleTime: &time,
|
|
|
|
}
|
|
|
|
tc.runTest(t)
|
|
|
|
}
|
|
|
|
|
2015-12-13 08:54:43 +00:00
|
|
|
// TODO: add more tests
|