Change:
{utiliptables.TableNAT, KubeNodePortChain}, {utiliptables.TableNAT, KubeLoadBalancerChain}, {utiliptables.TableNAT, KubeMarkMasqChain}, <ins> {utiliptables.TableNAT, KubeMarkDropChain}, </ins> {utiliptables.TableFilter, KubeForwardChain}, }

Discussion:
What happened: When building on sync fail messages are observed in the log when mode=ipvs is used; The chain is not defined (but is defined 5 times) What you expected to happen: Sync shall succeed. The chain shall be defined before use in the "restore" command to iptables. How to reproduce it (as minimally and precisely as possible): Start a cluster built on master with proxy-mode=ipvs Check the kube-proxy logs Anything else we need to know?: All tests works fine. Also this may be a fault during start-up, I can se only one fault logging. Anyway this log printout does not exist in 1.15. Environment: Kubernetes version (use ):Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig network /area ipvs
how fix this issue , i user kube-proxy 1.15
I do not get this on k8s 1.15, only when I build locally from . Can you see similar printouts in 1.15?
this error report disappear when i systemctl stop kube-proxy systemctl stop kubelet leave node from cluster, delete kubelet-client- iptable -F systemctl start kubelet add node to cluster systemctl start kube-proxy the error disappear It's related to the order of start-up
Yes, this could well be start-up order dependent. I think the chain is actually created by and used by . Since I see only one of these log printouts I guess the problem is harmless. I leave this issue open for some time for others to have a look at.
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
What version of iptables do you have? And is the kubelet running?
/assign
Yes, kubelet is running. But I start kubelet and kube-proxy from start-scripts so I really think this is a transient problem during start-up that may not be seen if k8s is started in other ways. I would like to close this issue since nothing seem to break, it just "looks ugly". That some chains are created by kubelet is however unfortunate. It will spill over on dual-stack since also kubelet must handle ipv4 and ipv6 iptables.

Yeah this sounds like a startup ordering issue, given that it seems to resolve itself after a few retries. We could: Make the kube-proxy do something nicer on startup when those chains don't exist (e.g., print a log like "Waiting for kubelet to program necessary chains" and retry, or something like that). Make the kube-proxy program these chains itself if they don't exist (I'm not familiar with the history of this one or why the kubelet installs these rather than kube-proxy - do you know?) Do nothing and live with some ugly logs./ crashing until the kubelet comes up. WDPT? /kind bug /remove-triage unresolved
The chain-create problem has implications on dual-stack also. Please see comments in;
Note that the does not crash, it only logs failed syncs.
no idea is this same problem but I am running kops with debian buster and things start to fail If I use same setup except debian stretch everything will work. Buster is using iptables v1.8.2 (nf_tables) stretch is using iptables v1.6.0 I think this failure leads to situation that weave cannot connect to master in init. Working master: Not working (buster): Iptables rules are not generated and kube-proxy will print errors edit: actually this fixes my problem
Same problem with Oracle Linux 8 Installed with kubeadm and --proxy-mode="" (iptables) I found KUBE-MARK-DROP isn't created in kube-proxy container (tested with weave and flannel). When execute: kubectl -n kube-system exec -i kube-proxy-XXXX -- /bin/sh -c "iptables -t nat -N KUBE-MARK-DROP;iptables -t nat -A KUBE-MARK-DROP -j MARK --set-xmark 0x8000/0x8000" Kube-proxy back to normal state.