Prior "bridge: Change local fdb entries whenever mac address of bridge device changes" [1],
FDB entry for a bridge was not inserted when creating the bridge and it could
only be inserted when a hw address of the bridge was changed. Therefore, on
an older than the 3.14 kernel containers were not able to reach
the "weave" bridge w/o setting the promiscuous mode on.
This should have hit hard Kubernetes users as the weave bridge in their
case is used as a default gateway, and thus it works only after manually
enabling the promiscuous mode.
Additionally, w/o the promiscuous mode a packet sent from a container and
destined to the gateway is flooded on all ports, so it can reach
the "datapath" device resulting in the "Vetoed installation of hairpin flow" error.
[1]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a4b816d8ba1c1917842dc3de97cbf8ef116e043e
The version of manifest-tool in `weshigbee/manifest-tool` is version
0.3.0 and is erroring on every build; latest is 0.8.0 and doesn't error.
Since we are no longer limited to what will run in a container at
CircleCI, also build all architectures.
by-pass ingress network policy chains and accept the packet if
destination is not one of the local pods
return the packets so the egress network policy chains are skipped
in case packet's source is not one of the local pods
Fixes#3344
The liveness probe has the not-so-great side effect of killing the weave pods
if anything goes wrong, making debugging really difficult.
Not only that, we also bumped into the livenessProbe killing pods before they
had a chance to start (see below for the full story).
The readinessProbe is only used for Kubernetes Services: no traffic will be
routed to non-Ready pods when using the Service IP. We can use to to signal the
user something in wrong with Weave Net while not having Kubernetes delete the
pods behind our backs.
I removed the ininitialDelaySeconds field as Kurbernetes won't kill the pod if
not ready.
Notes from a debugging session:
Some nodes may have a vast amount of iptables rules, making each iptables
command take a few seconds (~5-10s). At startup, when the weave container
creates its chains, it runs quite a few iptables commands and the total time of
execution was > 30s.
It's important to note that, at this point, the weave process hasn't started as
those iptables commands are run by an initial script.
Kubernetes was trying to check for the container liveness, was failing, and
then proceeded to kill the weave pods before they had a chance to fully start.
from transient errors (heartbeast misses). In case of transient
errors OverlayForwarder is marked to be unhealty. When overlay forwarder
is unhealty its hept on hold so chooseBest() will skip selecting the forwrder
Once OverlayForwarder is considered healthy run chooseBest() again so the
forwarder can be selected if its the best forwarder
Fixes#1737
Murali Reddy