Change:
clone, err := conversion.NewCloner().DeepCopy(&claim) if err != nil { glog.Errorf("error cloning claim %q: %v", claimToClaimKey(&claim), err) <ins> continue </ins> } claimClone := clone.(*api.PersistentVolumeClaim) ctrl.storeClaimUpdate(claimClone)

Discussion:
As part of the Kubernetes upgrade workflow we have in place, we are upgrading kubernetes from 1.15.3 -1.18.15 (both versions and all versions in the middle are custom patched for different behavior of the and . None of them having anything to do with kube-proxy's IPVS), and as part of this upgrade we are also migrating the from to mode. We have calico 3.12 running on the cluster as part of the CNI stack. Once the pods are migrated from to mode by applying the new DaemonSet manifest, the cluster has a series of stale rules for chain left around that breaks the runtime state of the pods. have cluster running in HA mode (3 Node cluster) where all nodes of the cluster are running as leaders and take the workload as well. There is no non-leader Pods. have customized the kubernetes and calico infra to enable the usage of Link local IP address in range for internal usecases Most of the IPs and the names have been mangled. Stale IP table rules to be cleaned up once the pods and endpoints are stable with all endpoints in Ready address mode. down the pods on a given namespace to 0 (leave the service and Endpoints around) the control plane to 1.18.15 (take the intermediate hop path. 1.15.3 -1.16.7 -1.17.5 -1.18.15) apply the kube-proxy manifest provided above. up the pods scaled down in Step 1. Current workaround we have been putting it use the as an init container and run the and then bring up the in IPVS mode and that seem to take care of the stale entries (but this seem to be too much of a big hammer approach of cleaning up) Kubernetes version (use ):Cloud provider or hardware configuration:OS (e.g: ):Kernel (e.g. ):Install tools: kubeadmNetwork plugin and version (if this is a network-related bug):Others:
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository.

</details
The label(s) cannot be applied. These labels are supported: <detailsIn response to : /label area/kube-proxy Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /sig sig/network Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig network
I don't think that the live migration between kube-proxy implementations iptables<-ipvs is supported, at least I never heard about that and seems tricky. you use to have all the historical context, what do you think?
We tried implementing a cleanup mode but it was problematic and removed. (see ) You can run but that's pretty coarse. Maybe we should add a value to that flag to say which mode to try to cleanup? PRs welcome. The simplest answer is to reboot.
Let's make this a docs issues - we should write this down
can we merge the above so that we can close this issue?
not just yet :-) wouldn't signal registration and calling clean-up would at least clean things up on graceful shutdown? Granted rules will not be there until kube-proxy is restarted.