Add --random-fully to MASQ iptables rules to mitigate conntrack issues

[coufalja]

To mitigate conntrack issues in Kubernetes.
See: https://tech.xing.com/a-reason-for-unexplained-connection-timeouts-on-kubernetes-docker-abd041cf7e02 and kubernetes/kubernetes#56903 for details.

[coufalja]

Docker image for testing purposes: wanderadock/kube-router:amd64-random-all

[murali-reddy]

@coufalja thanks for the PR. --random-fully option make sense. Changes look good but on upgrade we would end up with two rules. Old rule plus new rule with --random-fully option set. Are you expecting users to flush the iptables chains?

[coufalja]

@murali-reddy The way I deployed was going through full rolling-update of a cluster so I didn't hit the issue. But yeah It would be great to actually allow users to update in place. What needs to be done? Adding the old one to pkg/controllers/routing/pod_egress.go:85 and pkg/controllers/proxy/network_services_controller.go:1268 ?

[aauren]

This LGTM. Thanks for all of your work on this!

@murali-reddy I tested this locally on our nodes with both iptables that are able to support --random-full and iptables that are not. I also tested the upgrade procedure and found that it cleaned the nodes appropriately when upgrading from iptables that didn't support it to iptables that did support it.

[coufalja]

@aauren Thanks, just a question when I can expect this to be released? in the 1.1 or you plan to release 1.0.2 with a round of minor fixes?

[mrueg]

This would be an additional feature, so it will be in 1.1

[murali-reddy]

I tested this locally on our nodes with both iptables that are able to support --random-full and iptables that are not. I also tested the upgrade procedure and found that it cleaned the nodes appropriately when upgrading from iptables that didn't support it to iptables that did support it.

thanks @aauren