Currently, ClusterLoader2 does not play well with EKS 1.32, because
anonymous authentication to the API Server metrics endpoint is no
longer possible [1]. Let's ensure we use a supported version until
the issue gets addressed upstream [2].

[1]: https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions-standard.html#kubernetes-1-32
[2]: kubernetes/perf-tests#3214

Signed-off-by: Marco Iorio <marco.iorio@isovalent.com>

Thresholds are ignored if the enableViolations field is not set.

Signed-off-by: Marco Iorio <marco.iorio@isovalent.com>

By default, Cilium disables masquerading towards destinations within the
local VPC, as directly reachable. Yet, although the external target is
deployed in the same VPC for convenience, we want traffic directed to
it to be masqueraded, to reflect the most common type of real deployments,
in which the target is located in an external network. Hence, let's
configure the native routing CIDR to only match the availability zone
hosting the cluster nodes, considering that the external target is
explicitly pinned to a different one.

Signed-off-by: Marco Iorio <marco.iorio@isovalent.com>

So that we trigger an explicit failure in case the metrics don't
include all the expected client pods for whatever reason.

Signed-off-by: Marco Iorio <marco.iorio@isovalent.com>

Sometimes the masquerade delay metrics collection returns no samples,
as the test completes very quickly, and Prometheus may not even have
discovered the scrape target at that point. As a workaround, let's
explicitly wait for it to appear before moving on with the actual test.
Once the target is known, the discovery of the actual pods (once
created) is supposed to be significantly faster.

Signed-off-by: Marco Iorio <marco.iorio@isovalent.com>

Signed-off-by: Marco Iorio <marco.iorio@isovalent.com>

Add a step at the end of the egress gateway scale test to assess the
maximum number of parallel connections that can be opened via the egress
gateway. The test leverages an extended version of the egw-scale-utils
tools, with the server configured to keep connections open, and the
client opening new connections until repeated failures are encountered.

The test is repeated four times, assessing the following combinations:

1. base: client hosted on node N1, towards target at port P1.
2. same-port-node: client hosted on node N1, towards target at port P1;
   it evaluates whether a client hosted on the same node, and targeting
   the same destination is affected by the other open connections.
3. diff-node: client hosted on node N2, towards target at port P1; it
   evaluates whether a client hosted on a different node, and targeting
   the same destination is affected by the other open connections.
4. diff-port: client hosted on node N1, towards target at port P2; it
   evaluates whether a client hosted on the same node, but targeting
   a different destination is affected by the other open connections.

Signed-off-by: Marco Iorio <marco.iorio@isovalent.com>

Update the egress gateway scale test README file to include an overview
of the additional tests recently introduced. Overall, the README file is
simplified and generalized a bit, omitting more specific details, to
reduce the maintenance burden and the likelihood of divergences whenever
minor modifications to the scale test are performed.

Signed-off-by: Marco Iorio <marco.iorio@isovalent.com>