search

gocd-contrib / docker-elastic-agents-plugin

Docker-based elastic agents for GoCD
https://www.gocd.org
Apache License 2.0
31 stars 39 forks source link

How to properly run kubectl commands on hosting cluster #219

Closed Andrewknackstedt closed 1 year ago

Andrewknackstedt commented 1 year ago

I installed GoCD via the k8s helm chart on my kube cluster, and want to have it deploy files via a kubectl apply command.

How do I properly authenticate kubectl to the hosting cluster?

I currently have a custom docker image with kubectl installed on it, but it seems to not be an optimal design.

GoCD version v23.1.0 GoCD K8s elastic agent plugin 3.8.3-370

chadlwilson commented 1 year ago

Probably more relevant to https://github.com/gocd/kubernetes-elastic-agents, the helm chart repo or the main GoCD repo rather than this one, however in principal the answer is the same - the agent image is agnostic of where it is deployed and what might need to be done within a GoCD build so creating a child image from one of the various GoCD agent images to layer on kubectl and anything tools you may want/need to authenticate with your cluster is the expected approach.

What's not ideal about this setup? How do you need/want to authenticate with the target clusters API server?

Andrewknackstedt commented 1 year ago

Probably more relevant to https://github.com/gocd/kubernetes-elastic-agents

Absolutely correct, I think my brain had a technical glitch

The setup itself is fine -- it's simply not very clear in the docs that the GoCD pipeline agents use a default service account to authenticate themselves to the cluster they run on. It would be nice to add a sample in the docs of what cluster role bindings are expected, and add an option in the helm chart to automatically grant the role bindings to the service account

chadlwilson commented 1 year ago

Well default service account is just Kubernetes default behavior, but it depends on the pod spec in your elastic profile which is up to the user.

There's no assumption that people need to authenticate to the cluster within an agent (or that the build jobs they are running will be targeting Kubernetes) - if you want to deploy to the same (or a different cluster) to GoCD, deciding what roles and bindings you want to grant the agents is really outside the scope of GoCDs helm chart as it depends on what you are wanting to deploy or do within your jobs. Seems more like general Kubernetes knowledge than anything specific to GoCD?

Anyway, if you have a suggestion feel free to submit a PR on the Kubernetes elastic agent repo that outlines your idea.