Kubeclient 4.2.2

[timothysmith0609]

What are you trying to accomplish with this PR?
Closes #406
Update Kubeclient to 4.2.2. This will let AWS users properly auth via their kubeconfig

How is this accomplished?

• Bump Gem
• Remove GoogleFriendlyConfig (still need a shim for GCP, but less involved)
• Go through Changelog

Response to changelog

• KubeException is deprecated (it already was, before). Replaced with Kubeclient::HttpError, which is just a subclass of KubeException.

What could go wrong?
New, strange, behaviour not covered by our tests

[timothysmith0609]

As @KnVerey pointed out, it looks like ActiveFailover makes a reference to the to-be-removed GoogleFriendlyConfig. It looks like all we need to do is change the reference from GoogleFriendlyConfig to KubernetesDeploy::KubeclientBuilder::Kubeconfig and their client should retain the correct behaviour.

I'm tempted to change the reference to just use the base KubeClient class (Kubeclient::Config) since it's passing the tests, but I think that will cause issues when it actually has to auth against GCP in production.

[KnVerey]

still need a shim for GCP, but less involved

Why do we still need one? kubeclient's readme makes me think we could replace auth_options: kube_context.auth_options in our KubeClient construction with auth_options: { bearer_token: Kubeclient::GoogleApplicationDefaultCredentials.token }. Does that not work?

I'm tempted to change the reference to just use the base KubeClient class (Kubeclient::Config) since it's passing the tests, but I think that will cause issues when it actually has to auth against GCP in production.

I bet you're right not to assume it has test coverage for this. We'll probably want to work with that team to test the changes locally before merging them. They have a "check kubectl works" script on that repo that should do the trick (and actually uses the same code as failovers--the repo has a neat modular task architecture).

[KnVerey]

Another note: we should definitely test this branch manually using both user credentials and application default credentials before merging. My test app has a Shipit task that can be used for the latter.

[timothysmith0609]

auth_options: { bearer_token: Kubeclient::GoogleApplicationDefaultCredentials.token }. Does that not work?

This would work up until the point we're not targeting a GCP cluster, which due to the open-source nature of this gem is not a valid assumption to make. I'm wondering if it's worth patching kubeclient upstream. Our simple fix (checking for `auth-provider == "gcp") seems sufficient.

[timothysmith0609]

Another note: we should definitely test this branch manually using both user credentials and application default credentials before merging. My test app has a Shipit task that can be used for the latter.

Running with user credentials locally is working fine. Is the Cumulus Cat Task the Shipit task you're talking about?

[timothysmith0609]

Created upstream kubeclient issue for automatically loading default application credentials.

[KnVerey]

I don't need to review again, but please fix the Policial errors and 🎩 with the test app before merging.