14 Commits (6b6b6c747e1d465066b78d7ed2896bfb2260dbef)

Author	SHA1	Message	Date
deads2k	9488e2ba30	move testing/core to client-go	2017-01-26 13:54:40 -05:00
deads2k	ee6752ef20	find and replace	2017-01-20 08:04:53 -05:00
Clayton Coleman	bcde05753b	Correct import statements	2017-01-17 16:18:18 -05:00
Clayton Coleman	9a2a50cda7	refactor: use metav1.ObjectMeta in other types	2017-01-17 16:17:19 -05:00
deads2k	f1176d9c5c	mechanical repercussions	2017-01-13 08:27:14 -05:00
deads2k	6a4d5cd7cc	start the apimachinery repo	2017-01-11 09:09:48 -05:00
Solly Ross	c830d94dc4	HPA Controller: Check for 0-sum request value ... In certain conditions in which the set of metrics returned by Heapster is completely disjoint from the set of pods returned by the API server, we can have a request sum of zero, which can cause a panic (due to division by zero). This checks for that condition. Fixes #39680	2017-01-10 17:26:13 -05:00
Chao Xu	03d8820edc	rename /release_1_5 to /clientset	2016-12-14 12:39:48 -08:00
Clayton Coleman	3454a8d52c	refactor: update bazel, codec, and gofmt	2016-12-03 19:10:53 -05:00
Clayton Coleman	5df8cc39c9	refactor: generated	2016-12-03 19:10:46 -05:00
Pengfei Ni	f584ed4398	Fix package aliases to follow golang convention	2016-11-30 15:40:50 +08:00
Chao Xu	7eeb71f698	cmd/kube-controller-manager	2016-11-23 15:53:09 -08:00
Jerzy Szczepkowski	f843aff083	More unittests for HPA. ... Added more unittests for HPA. Fixed inconsistency in replica calculator when usageRatio == 1.0.	2016-11-10 17:30:23 +01:00
Solly Ross	2c66d47786	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-11-08 00:59:23 -05:00