Change:
framework.ExpectNoError(err) }) <del> /* Create a ClusterIP service with an External IP that is not assigned to an interface. The IP ranges here are reserved for documentation according to [RFC 5737](https://tools.ietf.org/html/rfc5737) Section 3 and should not be used by any host. */ ginkgo.It("should be possible to connect to a service via ExternalIP when the external IP is not assigned to a node", func() { serviceName := "externalip-test" ns := f.Namespace.Name externalIP := "203.0.113.250" if framework.TestContext.ClusterIsIPv6() { externalIP = "2001:DB8::cb00:71fa" } jig := e2eservice.NewTestJig(cs, ns, serviceName) ginkgo.By("creating service " + serviceName + " with type=clusterIP in namespace " + ns) clusterIPService, err := jig.CreateTCPService(func(svc *v1.Service) { svc.Spec.Type = v1.ServiceTypeClusterIP svc.Spec.ExternalIPs = []string{externalIP} svc.Spec.Ports = []v1.ServicePort{ {Port: 80, Name: "http", Protocol: v1.ProtocolTCP, TargetPort: intstr.FromInt(9376)}, } }) framework.ExpectNoError(err) err = jig.CreateServicePods(2) framework.ExpectNoError(err) execPod := e2epod.CreateExecPodOrFail(cs, ns, "execpod", nil) err = jig.CheckServiceReachability(clusterIPService, execPod) framework.ExpectNoError(err) }) </del> // TODO: Get rid of [DisabledForLargeClusters] tag when issue #56138 is fixed. ginkgo.It("should be able to change the type and ports of a service [Slow] [DisabledForLargeClusters]", func() { // requires cloud load-balancer support

Discussion:
Which jobs are failing: Which test(s) are failing: - Since when has it been failing: Testgrid link: Reason for failure: Nov 4 11:59:41.385: Unexpected error: &lt;*errors.errorString | 0xc00298c3d0: { s: "service is not reachable within 2m0s timeout on endpoint 203.0.113.250:80 over TCP protocol", } service is not reachable within 2m0s timeout on endpoint 203.0.113.250:80 over TCP protocol occurred Anything else we need to know: /priority important-soon /sig network /cc
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
Apparently this is related to /cc
if you're busy and want me to take a look tomorrow you can assign that to me and I can deep dive into what's missing/happening :) Happy to help and to understand better the flakiness life
so, the test adds a "fake" external IP that should be nated to the service endpoint It went through the CI, you can check the test here passing more details in the issue I opened explaining the test
ok, this is interesting the test is failing when using container runtime DOCKER https://k8s- the same periodic job that uses container runtime CONTAINERD (same as the PR) is working https://k8s- We need to understand what is different regarding the network in GCE jbos, when using docker as runtime, kubenet??? cc:
one diff between the working jobs with containerd and the failing ones with docker is that the failing ones use this part of the code for reference, kube-proxy adds the NAT rules here for external IPs here
IIRC you are using kubenet for azure jobs, are you using docker as runtime, can you please check if this tests fails there too?
The problem happens on environment that are using the bridge plugin, seems I got wrong the feature will revert until we have the right test.

We use kubenet only for IPv6 and dualstack jobs. Rest of the tests use Azure CNI. Default is docker runtime for all jobs.