Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

gha-runner-scale-set-0.9.x: Volume /var/run and /var/run/secrets/kubernetes.io/serviceaccount Conflict #3465

Open
4 tasks done
JohnYoungers opened this issue Apr 24, 2024 · 3 comments
Labels
bug Something isn't working gha-runner-scale-set Related to the gha-runner-scale-set mode needs triage Requires review from the maintainers

Comments

@JohnYoungers
Copy link

JohnYoungers commented Apr 24, 2024

Checks

Controller Version

0.9.1

Deployment Method

Helm

Checks

  • This isn't a question or user support case (For Q&A and community support, go to Discussions).
  • I've read the Changelog before submitting this issue and I'm sure it's not due to any recently-introduced backward-incompatible changes

To Reproduce

When using the gha-runner-scale-set to specify a custom template.spec.containers value containing the defaults from the documentation:

...
serviceAccountName: my-sa,
containers:
- name: runner
  image: ghcr.io/actions/actions-runner:latest
  command: ["/home/runner/run.sh"]
  env:
    - name: DOCKER_HOST
      value: unix:///var/run/docker.sock
  volumeMounts:
    - name: work
      mountPath: /home/runner/_work
    - name: dind-sock
      mountPath: /var/run
...

When this runner type is created, the pod fails to start with the following message:

Error: failed to create containerd task: 
failed to create shim task: OCI runtime create failed: 
runc create failed: unable to start container process: 
error during container init: 
error mounting "/var/lib/kubelet/pods/{id}/volumes/kubernetes.io~projected/kube-api-access-{id}" 
to rootfs at "/var/run/secrets/kubernetes.io/serviceaccount": 
mkdir /run/containerd/io.containerd.runtime.v2.task/k8s.io/runner/rootfs/run/secrets: read-only file system: unknown

Describe the bug

It looks like the /var/run volume is conflicting with the attempt to mount the serviceaccount token at the /var/run/secrets/... subpath

Describe the expected behavior

The pod to start without error: does the secrets mount need to be specified manually?

Additional Context

The cluster is version 1.28, running in AWS (EKS)

Controller Logs

N/A

Runner Pod Logs

N/A
@JohnYoungers JohnYoungers added bug Something isn't working gha-runner-scale-set Related to the gha-runner-scale-set mode needs triage Requires review from the maintainers labels Apr 24, 2024
@danielhabakkuk
Copy link

danielhabakkuk commented May 10, 2024

Facing the same issue after upgrading the gha-runner-scale-set to 0.9.0. Did someone find a fix for this?

@AmitBenAmi
Copy link

I am having the same issue with version 0.8.3 chart on EKS version 1.27

@AmitBenAmi
Copy link

@JohnYoungers I found out the root cause for this issue in my case.
For the runner container, I mounted the /var/run volumeMount with readyOnly: true, which eventually caused the mounting of the ServiceAccount token (on /var/run/secrets) to fail - it is a read-only file-system.

Changing /var/run mount to /run/docker path (or any other) specifically for mounting the docker.sock fixed the issue - just note that you need to change this path on both containers.

I did not dig into the option of only mounting the specific docker.sock file, but eventually that did the trick

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working gha-runner-scale-set Related to the gha-runner-scale-set mode needs triage Requires review from the maintainers
Projects
None yet
Development

No branches or pull requests

3 participants