Fixing the Integration Test Properly

[methylDragon]

Description

This PR:

• Bump kustomize, run gomod.sh and add changes to support it #266

Bumps the version of k8s.io/client-go to a version beyond v1.26, triggering this deprecation, which broke our integration tests.

This is because the integration test relies on an auth provider to GCP that used to be a golang import, but is now an installed dependency that requires the test to be run in an environment that ran:

• gcloud components install gke-gcloud-auth-plugin or
• sudo apt-get install google-cloud-sdk-gke-gcloud-auth-plugin

At least, that's the proper way to fix the test. In #266, I could not get the proper way to work because despite the test runner having access to the auth plugin, the test itself did not.

So I added the removed dependency as a hack (which is A VERY BAD WORKAROUND.)
See note in relevant file.

Ideally the test runner should be able to be injected with the above dependency.

[faximan]

I spent some time looking at the repro in #268 but could not find anything out. I agree the plugin is installed.

For reference, if trying the "old" way e.g. as suggested in https://github.com/kubernetes/client-go/issues/242, and add the import

_ "k8s.io/client-go/plugin/pkg/client/auth"

it fails at runtime with Creating the kubernetes client set failed: The gcp auth plugin has been removed. Please use the "gke-gcloud-auth-plugin" kubectl/client-go credential plugin instead.

[methylDragon]

it fails at runtime with Creating the kubernetes client set failed: The gcp auth plugin has been removed. Please use the "gke-gcloud-auth-plugin" kubectl/client-go credential plugin instead.

Yep! This is from the deprecation. The gcp auth plugin upstream got turned into a stub that emits an error: https://github.com/kubernetes/client-go/blob/master/plugin/pkg/client/auth/gcp/gcp_stub.go

[ensonic]

Is this ticket obsolete?

[methylDragon]

Is this ticket obsolete?

I think it's still active, because we're still relying on a workaround... I'm not sure how to fix though

If we are fine with the workaround (linked in the first post), we can close this, but I'm not sure how sustainable it will be.