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

Merge pull request #68678 from deads2k/agg-01-availability 

tighten maximum retry loop for aggregate api availability
pull/58/head
k8s-ci-robot 2018-10-01 02:45:31 -07:00 committed by GitHub
parent c847a1f04b ed6b5a77df
commit 2a3c8d580c
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 6 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

7
staging/src/k8s.io/kube-aggregator/pkg/controllers/status/available_controller.go
View File

@ -88,7 +88,12 @@ func NewAvailableConditionController(
endpointsLister: endpointsInformer.Lister(),
endpointsSynced: endpointsInformer.Informer().HasSynced,
serviceResolver: serviceResolver,
queue: workqueue.NewNamedRateLimitingQueue(workqueue.DefaultControllerRateLimiter(), "AvailableConditionController"),
queue: workqueue.NewNamedRateLimitingQueue(
// We want a fairly tight requeue time. The controller listens to the API, but because it relies on the routability of the
// service network, it is possible for an external, non-watchable factor to affect availability. This keeps
// the maximum disruption time to a minimum, but it does prevent hot loops.
workqueue.NewItemExponentialFailureRateLimiter(5*time.Millisecond, 30*time.Second),
"AvailableConditionController"),
}
// construct an http client that will ignore TLS verification (if someone owns the network and messes with your status