{"id":1909,"date":"2025-03-31T08:00:00","date_gmt":"2025-03-31T05:00:00","guid":{"rendered":"https:\/\/upcloud.com\/global\/us\/resources\/tutorials\/supercharge-your-ci-cd-deploy-lightning-fast-github-actions-runners-on-upclouds-managed-kubernetes-part-2\/"},"modified":"2025-03-31T08:00:00","modified_gmt":"2025-03-31T05:00:00","slug":"supercharge-your-ci-cd-deploy-lightning-fast-github-actions-runners-on-upclouds-managed-kubernetes-part-2","status":"publish","type":"tutorial","link":"https:\/\/upcloud.com\/global\/resources\/tutorials\/supercharge-your-ci-cd-deploy-lightning-fast-github-actions-runners-on-upclouds-managed-kubernetes-part-2\/","title":{"rendered":"Supercharge Your CI\/CD: Deploy Lightning-Fast GitHub Actions Runners on UpCloud\u2019s Managed Kubernetes: Part 2"},"content":{"rendered":"\n\n\n

Welcome back to the four-part series on supercharging your CI\/CD pipelines by deploying lightning-fast GitHub Actions Runners on UpCloud\u2019s Managed Kubernetes! In the previous installment<\/a>, you successfully set up a functional self-hosted runner on an UpCloud-based Kubernetes cluster, ready to execute your GitHub Actions workflows.<\/p>\n\n\n\n

Now, it\u2019s time to look closer into your runner deployment and learn some advanced configurations. In this part, we\u2019ll explore how to customize the runner deployment configuration, giving you fine-grained control over resources, tool installations, and standardization across your runner fleet.<\/p>\n\n\n\n

You\u2019ll also learn how to configure network policies for enhanced security and implement effective autoscaling policies to optimize runner costs. Let\u2019s get started on fine-tuning your GitHub Actions Runners!<\/p>\n\n\n\n

Customizing Runner and Workflow Pods<\/strong><\/h2>\n\n\n\n

Customizing runner and workflow pods can help with optimizing the performance and functionality of your self-hosted GitHub Actions Runners. As you installed the Actions Runner Controller using Helm charts in the last part of this series, you use the values file for the chart to pass in customization options when creating the controller. This template<\/a> for the values.yaml file for the GitHub Actions Runner Controller mentions all the options and customizations you can pass in through it.<\/p>\n\n\n\n

In some cases, you might also need to use configmaps and hook extensions<\/a> to pass in configurations and scripts to the runner pods. You will learn about these in this section as you need them.<\/p>\n\n\n\n

While you might be used to directly modifying the values.yaml file of the helm chart or using other Kubernetes native methods to customize pods and other resources, you can not actually use those methods here.<\/p>\n\n\n\n

Let\u2019s see how to use these methods to implement a few types of customizations.<\/p>\n\n\n\n

Specifying Resource Requests and Limits<\/strong><\/h3>\n\n\n\n

When running the Actions Runner controller on a shared cluster, resource consumption and limits are important to keep in mind. To ensure that your runner pods have the necessary resources to execute workflows efficiently (and also to ensure that they do not hog up more resources than they need), you can specify resource requests and limits. This is particularly important for workflows that require significant CPU or memory resources.<\/p>\n\n\n\n

You can implement this via the values file. To do that, create a new file named values.yaml<\/code> in your current working directory and save the following contents in it:<\/p>\n\n\n\n

template:\n  spec:\n    containers:\n      - name: runner\n        image: ghcr.io\/actions\/actions-runner:latest\n        command: [\"\/home\/runner\/run.sh\"]\n        resources:\n          requests:\n            cpu: \"1000m\"\n            memory: \"2Gi\"\n          limits:\n            cpu: \"2000m\"\n            memory: \"4Gi\"<\/code><\/pre>\n\n\n\n
This configuration sets a CPU request of 1 core and a memory request of 2 GB, with a CPU limit of 2 cores and a memory limit of 4 GB. The $job<\/code> variable will be dynamically replaced by the runner controller.<\/p>\n\n\n\n
Now, apply the changes to the chart using the updated values.yaml<\/code> file by running the following command:<\/p>\n\n\n\n
INSTALLATION_NAME=\"arc-runner-set\"\nNAMESPACE=\"arc-runners\"\nGITHUB_CONFIG_URL=\"https:\/\/github.com\/<github-username>\/<github-repo-name>\"\nGITHUB_PAT=\"<YOUR_GITHUB_PAT>\"\n\nhelm upgrade --install \"${INSTALLATION_NAME}\" \\\n  --namespace \"${NAMESPACE}\" \\\n  --create-namespace \\\n  --set githubConfigUrl=\"${GITHUB_CONFIG_URL}\" \\\n  --set githubConfigSecret.github_token=\"${GITHUB_PAT}\" \\\n  -f values.yaml \\\n  oci:\/\/ghcr.io\/actions\/actions-runner-controller-charts\/gha-runner-scale-set<\/code><\/pre>\n\n\n\n
That\u2019s it! The workflow pods that are created now will have the resource limits applied to them as you specified in the values file above. You can try checking the configuration of the runner pods to confirm by running kubectl get pod <pod_name> -o yaml -n arc-runners<\/code>.<\/p>\n\n\n\n
Here\u2019s what a typical pod created using these values might look like:<\/p>\n\n\n\n
$ kubectl get pod\/arc-runner-set-c48pp-runner-s5b5t -o yaml -n arc-runners\n\napiVersion: v1\nkind: Pod\nmetadata:\n  annotations:\n    actions.github.com\/patch-id: \"2\"\n    # omitted other details...\nspec:\n  containers:\n  - command:\n    - \/home\/runner\/run.sh\n    env:\n    - name: ACTIONS_RUNNER_INPUT_JITCONFIG\n      valueFrom:\n        secretKeyRef:\n          key: jitToken\n          name: arc-runner-set-c48pp-runner-s5b5t\n    - name: GITHUB_ACTIONS_RUNNER_EXTRA_USER_AGENT\n      value: actions-runner-controller\/0.10.1\n    image: ghcr.io\/actions\/actions-runner:latest\n    imagePullPolicy: Always\n    name: runner\n    # Here are the limits you had specified in the values file\n    resources:\n      limits:\n        cpu: \"2\"\n        memory: 4Gi\n      requests:\n        cpu: \"1\"\n        memory: 2Gi\n    terminationMessagePath: \/dev\/termination-log\n    terminationMessagePolicy: File\n    volumeMounts:\n    - mountPath: \/var\/run\/secrets\/kubernetes.io\/serviceaccount\n      name: kube-api-access-spnzt\n      readOnly: true\n  dnsPolicy: ClusterFirst\n  # omitted other details...<\/code><\/pre>\n\n\n\n
You can fine-tune these limits based on your workload requirements and the other services running on the host cluster.<\/p>\n\n\n\n
Installing Additional Tools<\/strong><\/h3>\n\n\n\n
There are times when you create a runner type for particular use cases, such as running E2E tests on your app by building and hosting it on remote environments such as Kubernetes clusters. To be able to make these use cases work, you might need to install additional tools on the runner (such as kubectl for example).<\/p>\n\n\n\n
It is important to mention that you can always do this initial setup in your GitHub Actions workflow as well. However, if you have a large number of workflows following the same setup routine, it might make sense to design runners that implement that routine before picking up jobs to help keep the workflow scripts simple.<\/p>\n\n\n\n
You can do that by instructing the Actions Runner Controller to run your script before starting a job using the ACTIONS_RUNNER_HOOK_JOB_STARTED<\/code> environment variable in the values file.<\/p>\n\n\n\n
Also, you will need to supply the script file to the runner pods before they can try running the script. To do that, you will use a ConfigMap mounted as a volume on the runner pod.<\/p>\n\n\n\n
To start off, write your initialization script in a file named install-additional-tools.yaml<\/code>:<\/p>\n\n\n\n
apiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: init-script\n  namespace: arc-runners\ndata:\n  init.sh: |\n    #!\/bin\/bash\n    curl -LO \"https:\/\/dl.k8s.io\/release\/$(curl -L -s https:\/\/dl.k8s.io\/release\/stable.txt)\/bin\/linux\/amd64\/kubectl\"\n    sudo install -o root -g root -m 0755 kubectl \/usr\/local\/bin\/kubectl<\/code><\/pre>\n\n\n\n
Now, create the ConfigMap by applying this configuration to your cluster. Here\u2019s the command to do that:<\/p>\n\n\n\n
kubectl apply -f install-additional-tools.yaml<\/code><\/pre>\n\n\n\n
Next, update the values.yaml file to mount this ConfigMap as a volume and use the mounted address of the initialization script in the ACTIONS_RUNNER_HOOK_JOB_STARTED<\/code> path. Here\u2019s what your values.yaml<\/code> file should look like:<\/p>\n\n\n\n
template:\n    spec:\n      containers:\n      - name: runner\n        image: ghcr.io\/actions\/actions-runner:latest\n        command: [\"\/home\/runner\/run.sh\"]\n        env:\n          - name: ACTIONS_RUNNER_HOOK_JOB_STARTED\n            value: \/home\/runner\/init-script\/init.sh\n        volumeMounts:\n          - name: init-script\n            mountPath: \/home\/runner\/init-script\n      volumes:\n        - name: init-script\n          configMap:\n            name: init-script<\/code><\/pre>\n\n\n\n
Finally, apply the changes to the Actions Runner Controller by running the following command:<\/p>\n\n\n\n
INSTALLATION_NAME=\"arc-runner-set\"\nNAMESPACE=\"arc-runners\"\nGITHUB_CONFIG_URL=\"https:\/\/github.com\/<github-username>\/<github-repo-name>\"\nGITHUB_PAT=\"<YOUR_GITHUB_PAT>\"\n\nhelm upgrade --install \"${INSTALLATION_NAME}\" \\\n  --namespace \"${NAMESPACE}\" \\\n  --set githubConfigUrl=\"${GITHUB_CONFIG_URL}\" \\\n  --set githubConfigSecret.github_token=\"${GITHUB_PAT}\" \\\n  -f values.yaml \\\n  oci:\/\/ghcr.io\/actions\/actions-runner-controller-charts\/gha-runner-scale-set<\/code><\/pre>\n\n\n\n
And that\u2019s it! You can try creating a workflow such as this one and running it to see that kubectl has been set up before the job begins executing:<\/p>\n\n\n\n
name: ARC Demo\non:\n  workflow_dispatch:\n\njobs:\n  Test-Runner:\n    runs-on: arc-runner-set\n    steps:\n      - run: kubectl version --client --output=yaml<\/code><\/pre>\n\n\n\n
Here\u2019s what the output of the run looks like:<\/p>\n\n\n\n
\"-\"<\/figure>\n\n\n\n
You\u2019ll see logs from the initialization script under the Set up runner<\/strong> step and the expected output under the run steps.<\/p>\n\n\n\n
If you choose to allow running container jobs or container actions in your ARC runners, this method will not be able to supply initialization scripts to the containers created when jobs are run. This is because the containers created for the runner in those cases will be created via runner-container-hooks<\/a>. To supply customizations (such as setting resource limits or providing initialization scripts) to these containers, you will need to use container hook extensions<\/a>.<\/p>\n\n\n\n
To do that, you will need to create a ConfigMap that specifies the template that you would like to use with the containers that get created using the hooks. Here\u2019s what a typical ConfigMap would look like:<\/p>\n\n\n\n
apiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: hook-extension\n  namespace: arc-runners\ndata:\n  content: |\n    metadata:\n      annotations:\n        example: \"extension\"\n    spec:\n      containers:\n        - name: \"$job\" # Target the job container\n          env:\n            - name: ACTIONS_RUNNER_HOOK_JOB_STARTED # specify the init script path\n              value: \/home\/runner\/init-script\/init.sh\n            volumeMounts: # mount the init script\n              - name: init-script\n                mountPath: \/home\/runner\/init-script\n          resources: # set resource limits\n            requests:\n              cpu: \"1000m\"\n              memory: \"2Gi\"\n            limits:\n              cpu: \"2000m\"\n              memory: \"4Gi\"\n              \n      volumes: # set up the init script volume from its configmap\n        - name: init-script\n          configMap:\n            name: init-script<\/code><\/pre>\n\n\n\n
Now, you need to supply this ConfigMap in the env ACTIONS_RUNNER_CONTAINER_HOOK_TEMPLATE<\/code> in your values.yaml file. Here\u2019s what the file would look like (assuming you\u2019ve saved the ConfigMap above as resource-limits-extension.yaml<\/code>):<\/p>\n\n\n\n
template:\n    spec:\n      containers:\n      - name: runner\n        image: ghcr.io\/actions\/actions-runner:latest\n        command: [\"\/home\/runner\/run.sh\"]\n        env:\n          - name: ACTIONS_RUNNER_CONTAINER_HOOK_TEMPLATE\n            value: \/home\/runner\/pod-template\/content\n        volumeMounts:\n          - name: pod-template\n            mountPath: \/home\/runner\/pod-template\n      volumes:\n        - name: pod-template\n          configMap:\n            name: resource-limits-extension<\/code><\/pre>\n\n\n\n
The pods now created via the runner-container-hooks for container jobs and services and container actions will now have the customizations you\u2019ve passed above.<\/p>\n\n\n\n
Using Runner ScaleSet Names<\/strong><\/h3>\n\n\n\n
When working with workloads that have different resource requirements, it might make sense to create multiple runners based on these resource requirements. This can help in cases like memory-heavy build processes which you only want to run on (potentially expensive) machinery, but scale it down right after it\u2019s done; all this while keeping a regular runner available for general use.<\/p>\n\n\n\n
You can deploy multiple runner scalesets using the helm install<\/code> command, but you would need a way to pick which scaleset to run your workflow jobs on. Runner scaleset names help solve this problem. They act as the label<\/em> for the runner scaleset, allowing you to define the possible runner options for a workflow using the runs-on<\/code> node in the workflow configuration file.<\/p>\n\n\n\n
To try it out, simply deploy another runner scaleset with a different installation name, a different namespace, and your required resource limits in your values file:<\/p>\n\n\n\n
INSTALLATION_NAME=\"arc-runner-set-heavy\"\nNAMESPACE=\"arc-runners-heavy\"\nGITHUB_CONFIG_URL=\"https:\/\/github.com\/<github-username>\/<github-repo-name>\"\nGITHUB_PAT=\"<YOUR_GITHUB_PAT>\"\n\nhelm upgrade --install \"${INSTALLATION_NAME}\" \\\n  --namespace \"${NAMESPACE}\" \\\n  --set githubConfigUrl=\"${GITHUB_CONFIG_URL}\" \\\n  --set githubConfigSecret.github_token=\"${GITHUB_PAT}\" \\\n  -f values.yaml \\\n  oci:\/\/ghcr.io\/actions\/actions-runner-controller-charts\/gha-runner-scale-set<\/code><\/pre>\n\n\n\n
You can now use the arc-runner-set-heavy<\/code> label in your workflow configuration files, such as this one to run jobs specifically on this runner:<\/p>\n\n\n\n
name: ARC Demo\non:\n  workflow_dispatch:\n\njobs:\n  Test-Runner:\n    runs-on: arc-runner-set-heavy\n    steps:\n      - run: echo \"Heavy runner \ud83d\udcaa\"<\/code><\/pre>\n\n\n\n
Network and Security<\/strong><\/h2>\n\n\n\n
When deploying self-hosted GitHub Actions Runners on a Kubernetes cluster, network security is an important aspect to keep in mind. By default, Kubernetes allows all pods to communicate freely with each other, which can pose significant security risks. In this section, we\u2019ll explore the issues with the default Kubernetes network policy, key principles of Kubernetes network policies, and how to implement these policies to enhance security.<\/p>\n\n\n\n
Issues with the Default Kubernetes Network Policy<\/strong><\/h3>\n\n\n\n
Kubernetes operates on an \u201callow-any-any\u201d model by default, which means that all pods can communicate with each other freely. This flat network model simplifies cluster setup but lacks security, as it doesn\u2019t restrict traffic between pods. Without additional configuration, sensitive data could be exposed if a pod is compromised.<\/p>\n\n\n\n
Kubernetes network policies provide a way to control traffic flow within a cluster, enhancing security and helping adhere to compliance requirements. Here are a few key principles you should keep in mind for most CI\/CD setups on Kubernetes infrastructure:<\/p>\n\n\n\n