15f0468986
Automatic merge from submit-queue 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 @kubernetes/rh-networking @kubernetes/sig-network-misc @eparis @knobunc @danwinship @thockin @freehan
Cluster Configuration
Deprecation Notice: This directory has entered maintenance mode and will not be accepting new providers. Please submit new automation deployments to kube-deploy. Deployments in this directory will continue to be maintained and supported at their current level of support.
The scripts and data in this directory automate creation and configuration of a Kubernetes cluster, including networking, DNS, nodes, and master components.
See the getting-started guides for examples of how to use the scripts.
cloudprovider/config-default.sh contains a set of tweakable definitions/parameters for the cluster.
The heavy lifting of configuring the VMs is done by SaltStack.