FailedChanges

Summary

  1. UPSTREAM: 43575: util/iptables: check for and use new iptables-restore (commit: bcda9a1) (details)
  2. UPSTREAM: 44895: util/iptables: grab iptables locks if iptables-restore (commit: c12716f) (details)
  3. UPSTREAM: 45601: util/iptables: fix cross-build failures due to (commit: 0b9485c) (details)
Commit bcda9a1b697c7e80c8f168d9a69646322c026050 by dcbw
UPSTREAM: 43575: util/iptables: check for and use new iptables-restore
'wait' argument
iptables-restore did not previously perform any locking, meaning that
when callers (like kube-proxy) asked iptables-restore to write large
numbers of rules, the iptables-restore process might run in parallel
with other 'iptables' invocations in kubelet (hostports), docker, and
other software.  This causes errors like:
"CNI request failed with status 400: 'Failed to ensure that nat chain
POSTROUTING jumps to MASQUERADE: error checking rule: exit status 4:
iptables: Resource temporarily  unavailable."
or from Docker
"Failed to allocate and map port 1095-1095: iptables failed: iptables
--wait -t nat -A DOCKER -p tcp -d 0/0 --dport 1095
-j DNAT --to-destination 10.1.0.2:1095 ! -i lbr0: iptables: Resource
temporarily unavailable.\n (exit status 4)"
iptables-restore "wait" functionality was added in iptables git commit
999eaa241212d3952ddff39a99d0d55a74e3639e but is NOT YET in a released
version of iptables.
See also https://bugzilla.redhat.com/show_bug.cgi?id=1417234
(commit: bcda9a1)
The file was modifiedvendor/k8s.io/kubernetes/pkg/util/iptables/iptables.go (diff)
The file was modifiedvendor/k8s.io/kubernetes/pkg/util/iptables/iptables_test.go (diff)
Commit c12716f6c68be41279d423f25defd3c16b648641 by dcbw
UPSTREAM: 44895: util/iptables: grab iptables locks if iptables-restore
doesn't support --wait
When iptables-restore doesn't support --wait (which < 1.6.2 don't), it
may conflict with other iptables users on the system, like docker,
because it doesn't acquire the iptables lock before changing iptables
rules. This causes sporadic docker failures when starting containers.
To ensure those don't happen, essentially duplicate the iptables locking
logic inside util/iptables when we know iptables-restore doesn't support
the --wait option.
Unfortunately iptables uses two different locking mechanisms, one until
1.4.x (abstract socket based) and another from 1.6.x (/run/xtables.lock
flock() based).  We have to grab both locks, because we don't know what
version of iptables-restore exists since iptables-restore doesn't have a
--version option before 1.6.2.  Plus, distros (like RHEL) backport the
/run/xtables.lock patch to 1.4.x versions.
Related: https://github.com/kubernetes/kubernetes/pull/43575 See also:
https://github.com/openshift/origin/pull/13845 Fixes:
https://bugzilla.redhat.com/show_bug.cgi?id=1417234
(commit: c12716f)
The file was modifiedvendor/k8s.io/kubernetes/pkg/util/iptables/iptables.go (diff)
The file was modifiedvendor/k8s.io/kubernetes/pkg/util/iptables/iptables_test.go (diff)
Commit 0b9485c7c87047ee438fb3db8d2b8b2f7db2bf19 by dcbw
UPSTREAM: 45601: util/iptables: fix cross-build failures due to
syscall.Flock()
Fixes: https://github.com/kubernetes/kubernetes/issues/45554
(commit: 0b9485c)
The file was addedvendor/k8s.io/kubernetes/pkg/util/iptables/iptables_unsupported.go
The file was addedvendor/k8s.io/kubernetes/pkg/util/iptables/iptables_linux.go
The file was modifiedvendor/k8s.io/kubernetes/pkg/util/iptables/iptables.go (diff)
The file was modifiedvendor/k8s.io/kubernetes/pkg/util/iptables/iptables_test.go (diff)