CI: Stabilize ConformanceKindEnvoyDaemonSet

[mhofstetter]

This PR tries to stabilize and de-flake the check ConformanceKKindEnvoyDaemonSet - mainly by removing the explicit connectivity-check flags external-* and using the default ones.

Currently it's failing on main and branches with failures when calling the external services: e.g. https://github.com/cilium/cilium/actions/runs/5278470155/jobs/9547854043

📋 Test Report
❌ 6/45 tests failed (10/292 actions), 10 tests skipped, 0 scenarios skipped:
Test [no-policies]:
  ❌ no-policies/pod-to-cidr/external-8888-1: cilium-test/client-6965d549d5-7gpbl (10.244.1.96) -> external-8888 (8.8.8.8:443)
connectivity test failed: 6 tests failed
Test [all-ingress-deny]:
  ❌ all-ingress-deny/pod-to-cidr/external-8888-0: cilium-test/client2-76f4d7c5bc-s5245 (10.244.1.212) -> external-8888 (8.8.8.8:443)
  ❌ all-ingress-deny/pod-to-cidr/external-8888-1: cilium-test/client-6965d549d5-7gpbl (10.244.1.96) -> external-8888 (8.8.8.8:443)
Test [all-ingress-deny-knp]:
  ❌ all-ingress-deny-knp/pod-to-cidr/external-8888-0: cilium-test/client-6965d549d5-7gpbl (10.244.1.96) -> external-8888 (8.8.8.8:443)
  ❌ all-ingress-deny-knp/pod-to-cidr/external-8888-1: cilium-test/client2-76f4d7c5bc-s5245 (10.244.1.212) -> external-8888 (8.8.8.8:443)
Test [to-cidr-external]:
  ❌ to-cidr-external/pod-to-cidr/external-8888-1: cilium-test/client2-76f4d7c5bc-s5245 (10.244.1.212) -> external-8888 (8.8.8.8:443)
Test [to-cidr-external-knp]:
  ❌ to-cidr-external-knp/pod-to-cidr/external-8888-0: cilium-test/client-6965d549d5-7gpbl (10.244.1.96) -> external-8888 (8.8.8.8:443)
  ❌ to-cidr-external-knp/pod-to-cidr/external-8888-1: cilium-test/client2-76f4d7c5bc-s5245 (10.244.1.212) -> external-8888 (8.8.8.8:443)
Test [client-egress-to-cidr-deny]:
  ❌ client-egress-to-cidr-deny/pod-to-cidr/external-8888-0: cilium-test/client-6965d549d5-7gpbl (10.244.1.96) -> external-8888 (8.8.8.8:443)
  ❌ client-egress-to-cidr-deny/pod-to-cidr/external-8888-1: cilium-test/client2-76f4d7c5bc-s5245 (10.244.1.212) -> external-8888 (8.8.8.8:443)

Additional changes in the check:

• kind version update
• KPR=strict

[mhofstetter]

/test

[mhofstetter]

counting four successful runs in a row 🟢 🟢 🟢 🟢 🙏

[joestringer]

@mhofstetter Can you describe a bit around the background to changing KPR? Does that mean we're losing coverage for the non-KPR approach? Was this discussed already with other folks in @cilium/sig-datapath ?

The rest of the changes LGTM.

[mhofstetter]

Can you describe a bit around the background to changing KPR? Does that mean we're losing coverage for the non-KPR approach? Was this discussed already with other folks in @cilium/sig-datapath ?

The rest of the changes LGTM.

@joestringer Thanks for reaching out. As its name indicate, the sole purpose of this workflow is to have at least some connectivity test coverage on the new feature where Envoy is deployed as separate DaemonSet.

Most other aspects are covered within Conformance E2E, where the different features (including KPR) are covered in the matrix properties of the jobs. (this has been introduced after i made a copy of an existing workflow to create this workflow)

At some point in the future we have to decide whether we're going to include the Envoy DaemonSet feature in the mentioned matrix too or whether it will become the new default. I had a short discussion about this with @brb while he was moving most workflows into the E2E workflow.

Therefore, the switch of KPR shouldn't impact anybody else - and more importantly: we shouldn't lose any actual coverage.

[joestringer]

OK thanks. Part of where I'm coming from here is that if we need to set KPR for this CI workflow to be stable, that could be hiding a real issue underneath. We can make this workflow more stable by switching that, but I'm also aware that our users might not have the option to just enable KPR. It's very easy to toggle a few settings in different CI workflows and then just lose coverage of certain combinations, then we'll only find out a few months later once our users try to deploy it. If we think that there's a risk of this, I'd request that we file an issue to track any missing combinations or to investigate why this workflow needs KPR vs. not. In an ideal world, kube-proxy vs. KPR would be functionally equivalent, just KPR is better (performance) due to the different design. In practice though kube-proxy vs. KPR often does have real functional differences due to either bugs in the implementation or integration issues.

That said I recognize now that the ConformanceKindEnvoyDaemonSet test is specifically for this new deployment model with the separate Envoy, so the purpose of this test is not to validate kube-proxy vs. KPR, so I'm fine with this 👍