Try running e2e on big runners

[dereknola]

Details on the CNCF Runners

Runner	K3s Build Time
GHA native (4vcpu)	7m 20s
equinix 4 cpu	5m 13s
equinix 8 cpu	4m 30s

Notes

Github Actions Standard Runner:

• Uses AMD EPYC 7763 64-Core Processor

equinix-XXcpu-XXgb

• Uses AMD EPYC 7401P 24-Core Processor
• No Systemd, uses init
• Possible, but difficult at this time for vagrant VMs
• has Docker installed

equinix-keda-runner

• Similar performance to 4cpu-16gb runner
• Uses AMD EPYC 7401P 24-Core Processor as well
• Unclear what exactly is the difference

oracle-aarch64

• Previously explored with Arm64 builds #10702
• Lacks most support tools
• Can be used to build K3s image
• Lacks NAT kernel module, making any form of testing with K3s impossible
• Currently unable to test, as the runner version is currently Out of Date (which GH kills as a security risk). Waiting on CNCF backend to catch up and fix this.

While the equinix runners on the surface should be slower, they seem to build K3s faster. However, there seems to be issues with availability, as K3s appears to only have access to "one" instance of each runner at a time vs GHA native which we have effectively infinity of as long as we stay under the 50000 minutes a month usage for Github Enterprise.

Conclusion

We should be selective in utilizing the equinix and oracle runners. Generally GHA native runners remain preferable for most use cases. Potential exceptions are:

• Running larger E2E or Docker tests with 5+ nodes/VMs
• Building K3s arm64/arm32 if we need to move off Drone