Name clarity when using Helm #3912
Replies: 1 comment
-
Yes it's confusing took me a bit to sort through it. The Scale Set Controller is what watches the CRDs for deploying "Scale Sets", it's analogous to the Kubernetes Deployment controller that watches for Deployments and creates the needed Pods/ReplicaSets. The second Helm chart is just a helper to make it easy to deploy ScaleSets using the CRD, which just instructs the Controller from the first chart how many runners to deploy, your secrets to connect to GitHub etc. The Controller is what listens to GitHub and creates the runner pods as needed from your GitHub Actions queue(s), and then assigns jobs to them to run. In your case you told the controller to keep at least one Runner Pod running, and create up to two as needed. The difference between Pods and Containers is standard Kubernetes, every pod can have multiple containers that share the same network and storage namespace https://kubernetes.io/docs/concepts/workloads/pods/ |
Beta Was this translation helpful? Give feedback.
-
Hello. This might be a none-issue (due to inexperience), but I am a bit confused on Pod names / purpose. Just trying to confirm the flow between Pods and key purpose when installing things via the Helm charts.
This installs the "operator / controller" pod. Its job is to wait for "listeners" and report their health to GH?
This install the "listeners" pods. Their job is to poll for Jobs in GH and if they find one, tell the "operator" pod to launch an emphemeral runner.
When I submit a repo update, I see a new pod being created with 2 containers (assuming the runner + dind). The part that is confusing me (I think) is the the OCI helm chart name "gha-runner-scale-set". That sounds like its the runner (aka the thing the builds your thing), but in reality it is not, its just a traffic cop.
Thanks for any tips on understanding.
Beta Was this translation helpful? Give feedback.
All reactions