Change:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: Performing a on a UDP-based service using nodePort leads to traffic from another pod to service being interrupted. Flushing manually the conntrack entry is enabling the traffic to flow again. What you expected to happen: Traffic to continue flowing after rollout. How to reproduce it (as minimally and precisely as possible): The following using some basic python UDP code is exhibiting the issue when the rollout command is executed. The issue is happening often (2 times over 3 I would say). Anything else we need to know?: I notice the k8s doing the flushing is using a conntrack parameter that seems to be ineffective in that particular usecase: However, the following altered command line works: Environment: Kubernetes version (use ): Client Version: version.Info{Major:"1", Minor:"19", GitVersion:"v1.19.3", GitCommit:"", GitTreeState:"clean", BuildDate:"2020-10-14T12:50:19Z", GoVersion:"go1.15.2", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"19", GitVersion:"v1.19.0", GitCommit:"", GitTreeState:"clean", BuildDate:"2020-08-26T14:23:04Z", GoVersion:"go1.15", Compiler:"gc", Platform:"linux/amd64"} Cloud provider or hardware configuration: baremetal OS (e.g: ): NAME="Ubuntu" VERSION="20.04.1 LTS (Focal Fossa)" ID=ubuntu IDLIKE=debian PRETTYNAME="Ubuntu 20.04.1 LTS" VERSIONID="20.04" HOMEURL="" SUPPORTURL="" BUGREPORTURL="" PRIVACYPOLICYURL="" VERSIONCODENAME=focal UBUNTUCODENAME=focal Kernel (e.g. ): Linux falcon 5.4.0-52-generic -Ubuntu SMP Thu Oct 15 10:57:00 UTC 2020 x8664 x8664 x8664 GNU/Linux Install tools: kubeadm v.1.19.3 Network plugin and version (if this is a network-related bug): calico , deployed using calico-typha operator - no network policy or endpoint objects deployed. Others: Bug originally found on a kops-based cluster with 1.17.9 with SIP based traffic on port 5060, we checked on a more recent baremetal 1.19 cluster deployment.
/sig network
Proxy mode is iptables btw.
/cc
so , the whole logic to delete conntrack entries in kube-proxy happens here The code that you link has an interesting comment that seems to link to an old issue with, the same problem you are reporting??? I think that the problem is here if is a nodePort it only deletes the NAT entries that are directed to the NodePort, but as we can see in your example, we are not deleting the entries directed to the ClusterIP, that as you demonstrated it seems to work. I think that removing the in that part of the code, so we ALWAYS delete the cluster IP -endpoint conntrack entries will solve the problem are you interested in take on this and fix it, and correct me if I'm wrong?
tentative PR
/assign /triage accepted

Discussion:
var err error if nodePort != 0 { err = conntrack.ClearEntriesForPortNAT(proxier.exec, endpointIP, nodePort, svcProto) <del> } else { err = conntrack.ClearEntriesForNAT(proxier.exec, svcInfo.ClusterIP().String(), endpointIP, svcProto) </del> <ins> if err != nil { klog.Errorf("Failed to delete nodeport-related %s endpoint connections, error: %v", epSvcPair.ServicePortName.String(), err) } </ins> } <ins> err = conntrack.ClearEntriesForNAT(proxier.exec, svcInfo.ClusterIP().String(), endpointIP, svcProto) </ins> if err != nil { klog.Errorf("Failed to delete %s endpoint connections, error: %v", epSvcPair.ServicePortName.String(), err) }