What happened:
Running CL2 locally with the run-e2e.sh script can unexpectedly fail when it attempts to connect to the wrong API server.
How to reproduce it (as minimally and precisely as possible):
- Add multiple clusters to your
KUBECONFIG file.
- Ensure that the target test cluster is not the first entry in the
KUBECONFIG.
- Use the
run-e2e.sh wrapper to run CL2.
Anything else we need to know?:
The current logic: server=$(kubectl --kubeconfig "${KUBECONFIG}" config view -o jsonpath='{.clusters[0].cluster.server}') always points to the first cluster listed in the KUBECONFIG file.
If there are multiple entries, the script may select connection information from a mismatching entry, effectively breaking connectivity in local development environments. This issue is not visible in K8s CI tests, as those jobs are short-lived and always use a KUBECONFIG file with a single entry.
Workaround:
For scale testing with CL2, create a KUBECONFIG file containing only a single entry pointing to the specific test cluster.
What happened:
Running CL2 locally with the
run-e2e.shscript can unexpectedly fail when it attempts to connect to the wrong API server.How to reproduce it (as minimally and precisely as possible):
KUBECONFIGfile.KUBECONFIG.run-e2e.shwrapper to run CL2.Anything else we need to know?:
The current logic:
server=$(kubectl --kubeconfig "${KUBECONFIG}" config view -o jsonpath='{.clusters[0].cluster.server}')always points to the first cluster listed in theKUBECONFIGfile.If there are multiple entries, the script may select connection information from a mismatching entry, effectively breaking connectivity in local development environments. This issue is not visible in K8s CI tests, as those jobs are short-lived and always use a
KUBECONFIGfile with a single entry.Workaround:
For scale testing with CL2, create a
KUBECONFIGfile containing only a single entry pointing to the specific test cluster.