334 should solve allow C nodes to handle changes of IP address, but we don't have E2E tests which simulate a C node IP address changing.
Because we don't have a reliable way to replace a Pod and ensure that its replacement has a new IP address.
330 has some code which attempted to provoke an IP address change, by running another (unrelated) pod immediately after deleting a C pod, in the hope that the previous IP address would be consumed by the new pod and that the new C pod would be issued a new IP address.
It doesn't work at all on minikube and it was quite flaky on kubeadm-dind-cluster.
Perhaps we can create a CNI plugin for testing which never re-uses IP addresses.
/kind bug
What happened:
What you expected to happen:
How to reproduce it (as minimally and precisely as possible):
334 should solve allow C nodes to handle changes of IP address, but we don't have E2E tests which simulate a C node IP address changing.
Because we don't have a reliable way to replace a Pod and ensure that its replacement has a new IP address.
330 has some code which attempted to provoke an IP address change, by running another (unrelated) pod immediately after deleting a C pod, in the hope that the previous IP address would be consumed by the new pod and that the new C pod would be issued a new IP address.
It doesn't work at all on minikube and it was quite flaky on
kubeadm-dind-cluster.Perhaps we can create a CNI plugin for testing which never re-uses IP addresses.
/kind bug
What happened:
What you expected to happen:
How to reproduce it (as minimally and precisely as possible):
Anything else we need to know?:
Environment:
kubectl version):