mirror of https://github.com/k3s-io/k3s
59cee2c73c
Automatic merge from submit-queue (batch tested with PRs 54533, 54777, 54763, 54806, 54703). 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>. make iptables wait flag generic and tune it to 5 seconds Excerpt from [bug](https://bugzilla.redhat.com/show_bug.cgi?id=1506396) opened by @eparis > iptables-restore has a 2s wait timeout. Data collected today shows that even with a much faster kernel we can reasonably expect iptables-restore to take upwards of 2.4 seconds. (with unpatched/released RHEL kernel this can easily take 7-8 second) > longest runs I saw over about 30 minutes were: > 2.267244 > 2.284707 > 2.291535 > 2.376457 > If we get 2 iptables restores going at the same time, with a 2s timeout it is very likely the second will fail. > I'd like to suggest a 5s timeout. It should still bound the number of thread we may be waiting on and increases the reliability that a common situation will be automatically resolved without failing up the stack. |
||
|---|---|---|
| .. | ||
| async | ||
| bandwidth | ||
| config | ||
| configz | ||
| dbus | ||
| ebtables | ||
| env | ||
| file | ||
| filesystem | ||
| flock | ||
| goroutinemap | ||
| hash | ||
| initsystem | ||
| interrupt | ||
| io | ||
| ipconfig | ||
| iptables | ||
| ipvs | ||
| keymutex | ||
| labels | ||
| limitwriter | ||
| maps | ||
| metrics | ||
| mount | ||
| net | ||
| netsh | ||
| node | ||
| nsenter | ||
| oom | ||
| parsers | ||
| pointer | ||
| procfs | ||
| reflector/prometheus | ||
| removeall | ||
| resourcecontainer | ||
| rlimit | ||
| selinux | ||
| slice | ||
| strings | ||
| sysctl | ||
| system | ||
| tail | ||
| taints | ||
| template | ||
| term | ||
| threading | ||
| tolerations | ||
| version | ||
| workqueue/prometheus | ||
| BUILD | ||
| verify-util-pkg.sh | ||