• Kubernetes Submit Queue's avatar
    Merge pull request #66615 from jbartosik/cpu-warm-up · c32e0e84
    Kubernetes Submit Queue authored
    Automatic merge from submit-queue (batch tested with PRs 65730, 66615, 66684, 66519, 66510). If you want to cherry-pick this change to another branch, please follow the instructions <a href="https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md">here</a>.
    
    Speed up HPA reaction to metric changes by removing scale up forbidden window
    
    **What this PR does / why we need it**:
    Speed up HPA reaction to metric changes by removing scale up forbidden window.
    
    Scale up forbidden window was protecting HPA against making decision to scale up based on metrics gathered during pod initialisation (which may be invalid, for example pod may be using a lot of CPU despite not doing any "actual" work).
    
    To avoid that negative effect only use per pod metrics from pods that are:
    - ready (so metrics about them should be valid), or
    - unready but creation and last readiness change timestamps are apart more than 10s (pods that have formerly been ready and so metrics are in at least some cases (pod becoming unready because of overload) very useful).
    
    
    This PR only deals with scale up window. I'll send another PR dealing with scale down window soon.
    
    **Which issue(s) this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close the issue(s) when PR gets merged)*:
    
    **Special notes for your reviewer**:
    
    **Release note**:
    ```release-note
    Speed up HPA reaction to metric changes by removing scale up forbidden window.
    
    Scale up forbidden window was protecting HPA against making decision to scale up based on metrics gathered during pod initialisation (which may be invalid, for example pod may be using a lot of CPU despite not doing any "actual" work).
    
    To avoid that negative effect only use per pod metrics from pods that are:
    - ready (so metrics about them should be valid), or
    - unready but creation and last readiness change timestamps are apart more than 10s (pods that have formerly been ready and so metrics are in at least some cases (pod becoming unready because of overload) very useful).
    ```
    c32e0e84
Name
Last commit
Last update
..
bootstrap Loading commit data...
certificates Loading commit data...
cloud Loading commit data...
clusterroleaggregation Loading commit data...
cronjob Loading commit data...
daemon Loading commit data...
deployment Loading commit data...
disruption Loading commit data...
endpoint Loading commit data...
garbagecollector Loading commit data...
history Loading commit data...
job Loading commit data...
namespace Loading commit data...
nodeipam Loading commit data...
nodelifecycle Loading commit data...
podautoscaler Loading commit data...
podgc Loading commit data...
replicaset Loading commit data...
replication Loading commit data...
resourcequota Loading commit data...
route Loading commit data...
service Loading commit data...
serviceaccount Loading commit data...
statefulset Loading commit data...
testutil Loading commit data...
ttl Loading commit data...
util/node Loading commit data...
volume Loading commit data...
.import-restrictions Loading commit data...
BUILD Loading commit data...
OWNERS Loading commit data...
client_builder.go Loading commit data...
controller_ref_manager.go Loading commit data...
controller_ref_manager_test.go Loading commit data...
controller_utils.go Loading commit data...
controller_utils_test.go Loading commit data...
doc.go Loading commit data...
lookup_cache.go Loading commit data...