I had been thinking about updating the podspec here to demonstrate / test that bumping the mirror podspecs result in generation getting bumped, something like this:

ginkgo.By("updating tolerations to trigger generation bump")
pod.Spec.Tolerations = append(pod.Spec.Tolerations, v1.Toleration{
	Key:      "pod-generation-test-" + string(uuid.NewUUID()),
	Operator: v1.TolerationOpEqual,
	Value:    "bar",
	Effect:   v1.TaintEffectNoSchedule,
})
_, err := f.ClientSet.CoreV1().Pods("kube-system").Update(ctx, &pod, metav1.UpdateOptions{})
framework.ExpectNoError(err, "failed to update pod")

updatedPod, err := f.ClientSet.CoreV1().Pods("kube-system").Get(ctx, pod.Name, metav1.GetOptions{})
framework.ExpectNoError(err, "failed to get pod")
gomega.Expect(updatedPod.Generation).To(gomega.BeEquivalentTo(currentGeneration + 1))
gomega.Expect(updatedPod.Status.ObservedGeneration).To(gomega.BeEquivalentTo(0))

but I felt that modifying the kube-system pods seems dangerous... not sure if there is a simple way to test the behavior of static pods here when their spec is modified (please let me know if there is). If not, then maybe best to leave it out.

Two ways:

1. in test/e2e you can hack around and schedule a pod that will drop a new static pod into the manifests folder. This is not a great way forward.
2. Use test/e2e_node and follow examples https://github.com/kubernetes/kubernetes/blob/master/test/e2e_node/mirror_pod_test.go and https://github.com/kubernetes/kubernetes/blob/master/test/e2e_node/standalone_test.go

@aojea is it a good thing to make tests rely on existence of at least one kube-system static pod? I remember somebody mentioned kube-proxy may go away?

Thanks for the pointer! Will follow 2.

kube-proxy is only used as static pod in gke and gce scripts 🙃 , kubeadm uses a daemonset to deploy kube-proxy ... e2e test has to be agnostic of the cluster type so it does not seem a good idea to assume any cluster will have a kube-system static pod ...