@kubernetes/sig-node-misc

Can confirm the problem with k8s 1.4.7 & docker 1.13 on debian jessie. kubelet managed by systemd

Since the team @Kargakis tagged here is no longer a team... cc: @kubernetes/sig-node-bugs

Docker 1.13 changed the default iptables forwarding policy to DROP, which has effects like this.

You can change the policy to ACCEPT (which it was in Docker 1.12 and before) by running:

sudo iptables -P FORWARD ACCEPT

on every node. You need to run this in the host network namespace, not inside a pod namespace.

sudo iptables -P FORWARD ACCEPT

Tested out and working

Environment:

• Cloud provider: AWS
• OS: Ubuntu Server 16.04 LTS
• Kernel: 4.4.0-59
• Kubernetes: 1.5.2
• Docker: 1.13
• Network plugin: Weave 1.8.2
• Network: VPC with NAT gateway, internet gateway, public & private subnets

Docker 1.13 changed the default iptables forwarding policy to DROP, which has effects like this.

Could someone explain why docker defaulting to DROP? Does this mean containers of docker v1.13 can't connect outside by default?

@feiskyer generally the Linux default is to have IP forwarding off.
Docker used to turn it on across the board, which was (a) unnecessary and (b) a security issue. 1.13 removed this issue.

Docker add two specific rules which allow traffic off their bridge, and replies to come back:

-A FORWARD -i docker0 ! -o docker0 -j ACCEPT
-A FORWARD -o docker0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

CNI providers which do not use the docker0 bridge need to make similar provision.

@colemickens can you clarify which network plugin you are using - is it kubenet?

This thread sure was a lifesaver, though sadly I found it about 14 hours too late.. I managed to wipe my entire cluster and reinstall everything, with the same issue still persisting. I was about to lose my mind trying to figure out why half of my original cluster was working and the other wasn't. Those which didn't work were installed and added later with docker 1.13, so this explains everything.

Now I've got everything up and running again!

Thanks again for this 👍

The docker change that caused this: moby/moby#28257

(@bboreham Yes, it was kubenet.)

The way that services work with iptables mean that we will be initiating connections in to the bridge. As such, we need to be more permissive than the docker0 lines above as we won't already have a connection for incoming connections. Here is what I had to do (my bridge is called cni0):

iptables -A FORWARD -i cni0 -j ACCEPT
iptables -A FORWARD -o cni0 -j ACCEPT

This says: forward stuff both in and out to cni0 regardless.

It used to be recommended to start Docker with --iptables=false and --ip-masq=false in a Kubernetes deployment, would it be a viable approach to ensure these are effectively disabled using a kubelet flag?

ref. https://kubernetes.io/docs/getting-started-guides/scratch/#docker

Personally I would be happier with the minimum required to make Kubernetes work, rather than blanket turning on IP forwarding from anywhere to anywhere.

Also, it seems to me that specifying --iptables=false while leaving --ip-forward defaulted to true is a very obscure way to arrive at your desired result.

This also appears to stop NodePort services from working. (Thanks to @bboreham for the workaround!)

sorry -- accidental close

@euank I'm not entirely convinced this is the responsibility of CNI plugins. It's discussed above, and some plugins do include workarounds, but manipulating the host to allow forwarding of traffic feels squarely outside of a CNI plugin's responsibilities as I understand them.

I think we still need a solution for this in Kubernetes.

CC @tmjd

We're adding a "allow this interface" chained plugin in to the CNI repository. It's a clean solution to this problem.

containernetworking/plugins#75

@bboreham it works. Thank you!

@squeed iptables-allow is cool. We should document this clearly when the plugin is ready.

#52569 looks to be the proper fix for this (since v1.9.0-alpha.2).

closed with #52569

To make this easier for those in the future: this got merged and released in 1.8.4.

FORWARD -i docker0 ! -o docker0 -j ACCEPT -A FORWARD -o docker0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

this does not make it work even though the packet forward use docker0, because the packet from other node will not be in ctstate RELATED or ESTABLISHED, the first packet will be NEW, and this packet will be drop, so it will never be in ESTABLISHED state

I experienced the same issue on Kubernetes with the Calico network stack under Debian Buster.

Checking a lot of configs and parameters, I ended up with getting it to work by changing the policy for the forward rule to ACCEPT. This made it clear that the issue is somewhere around the firewall.

Running iptables -L gave me the following unveiling warning: # Warning: iptables-legacy tables present, use iptables-legacy to see them

The output given by the list command does not contain any Calico rules. Running iptables-legacy -L showed me the Calico rules, so it seems obvious now why it didn't work. So Calico seems to use the legacy interface.

The issue is the change in Debian to iptables-nft in the alternatives, you can check via:

ls -l /etc/alternatives | grep iptables

Doing the following:

update-alternatives --set iptables /usr/sbin/iptables-legacy
update-alternatives --set ip6tables /usr/sbin/ip6tables-legacy
update-alternatives --set arptables /usr/sbin/arptables-legacy
update-alternatives --set ebtables /usr/sbin/ebtables-legacy

Now it works all fine! Thanks to Long at the Kubernetes Slack channel for pointing the route to solving it.