Add kubectl installation to Dockerfile

[ahanafy]

This pull request adds the installation of kubectl to the gcp section of the Dockerfile. The previous execution of gcloud components install gke-gcloud-auth-plugin supports kubectl authentication to gke clusters. Having the kubectl cli installed allows users to access their clusters.

Usage of this runner image via spacelift requires a user customize the "Applying" workflow phase by adding the command gcloud auth login --cred-file=/mnt/workspace/cred-file.json (or wherever the gcp credentials file is)

[peterdeme]

I don't see why not. Opinions @adamconnelly @eliecharra?

[adamconnelly]

I think it's ok. The only concerns I would have would be:

1. We're adding more to the image.
2. It's possible that the version of kubectl might not be compatible with all customer's clusters.

But for point 1 the image is already huge compared to our base runner image, presumably because of the overhead of adding gcloud, so I don't think adding kubectl and the auth plugin will be a huge concern here.

And for point 2, given that this is a GCP-specific image, and this is installing the version of kubectl provided by the gcloud command, I think that's fair enough.

So long story short - I don't have any objections here.

[eliecharra]

I'm not strongly against it, but I'm also not super enthusiastic about adding more and more tools to the image, whatever it's actual size.
Is this image meant to be used only for terraform workflows? If yes, I'm not sure to frame why a kubectl binary is useful for terraform workflows.
Correct me if I'm wrong, but it looks like a convenience/debugging move to me? In that case, I think the proper approach is to extends this image and use it instead of making the base image more heavy.
I'm also worried that this will add additional maintenance as we add more tools to the scope.

[peterdeme]

I think I agree with Elie on this one, adding such a tool could make this base image a bit fragile as well. Who knows what breaking change will be introduced in the kubectl.

[ahanafy]

I'm not strongly against it, but I'm also not super enthusiastic about adding more and more tools to the image, whatever it's actual size. Is this image meant to be used only for terraform workflows? If yes, I'm not sure to frame why a kubectl binary is useful for terraform workflows. Correct me if I'm wrong, but it looks like a convenience/debugging move to me? In that case, I think the proper approach is to extends this image and use it instead of making the base image more heavy. I'm also worried that this will add additional maintenance as we add more tools to the scope.

To give you some context as to why this is important for terraform workflows with GCP, you'll notice that the gke autopilot module from terraform-google-modules requires kubectl:
https://registry.terraform.io/modules/terraform-google-modules/kubernetes-engine/google/latest/submodules/beta-autopilot-private-cluster#software-dependencies

I was able to solve this without creating a custom runner so far by adding kubectl installation in the Initialization phase of my stacks, but thought that it made more sense to be in the offical gcp image

[peterdeme]

Let's close this PR for now because of Elie's reasoning (possible breaking changes). I'd recommend building a custom image on top of this one.