CI: K8sServicesTest Checks service across nodes Tests NodePort BPF Tests with direct routing Tests NodePort with Maglev Tests NodePort

[aditighag]

/home/jenkins/workspace/Cilium-PR-K8s-1.12-net-next/src/github.com/cilium/cilium/test/ginkgo-ext/scopes.go:514
Request from testclient-sj9l5 pod to service http://10.107.142.225:10080 failed
Expected command: kubectl exec -n default testclient-sj9l5 -- /bin/bash -c 'fails=""; id=$RANDOM; for i in $(seq 1 10); do if curl --path-as-is -s -D /dev/stderr --fail --connect-timeout 5 --max-time 20 http://10.107.142.225:10080 -H "User-Agent: cilium-test-$id/$i"; then echo "Test round $id/$i exit code: $?"; else fails=$fails:$id/$i=$?; fi; done; if [ -n "$fails" ]; then echo "failed: $fails"; fi; cnt="${fails//[^:]}"; if [ ${#cnt} -gt 0 ]; then exit 42; fi' 
To succeed, but it failed:
Exitcode: 42 
Err: exit status 42
Stdout:

99c5ba2b_K8sServicesTest_Checks_service_across_nodes_Tests_NodePort_BPF_Tests_with_direct_routing_Tests_NodePort_with_Maglev_Tests_NodePort.zip

Hit in #13812

[brb]

Just two add more context, the 5/10 request from a client pod to the svc failed with the curl err code 28. This was testing bpf_sock, so it has nothing to do with Maglev.

[sayboras]

Found in #14113 as well.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[stale]

This issue has not seen any activity since it was marked stale. Closing.

[jrajahalme]

Hit in #16258: https://jenkins.cilium.io/job/Cilium-PR-K8s-1.20-kernel-4.19/1074/testReport/junit/Suite-k8s-1/20/K8sServicesTest_Checks_service_across_nodes_Tests_NodePort_BPF_Tests_with_direct_routing_Tests_NodePort_with_Maglev_Tests_NodePort/

[joestringer]

From community meeting: Sounds like when this fails, maybe local requests work but requests to remote backends fail.

[brb]

The recent K8sServices refactoring might have resolved the flake. Closing for now.