Charts should provide ability to configure resources for containers

[Nuru]

Checks

• [X] I've already read https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners-with-actions-runner-controller/troubleshooting-actions-runner-controller-errors and I'm sure my issue is not covered in the troubleshooting guide.
• [X] I am using charts that are officially provided

Controller Version

0.8.3

Deployment Method

Helm

Checks

• [X] This isn't a question or user support case (For Q&A and community support, go to Discussions).
• [X] 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

See https://github.com/actions/actions-runner-controller/issues/3257

Describe the bug

Without the ability to configure resource (in particular, memory) requests for containers, runner pods can get into situations where the runner runs but the dind container does not, causing the job to fail.

Describe the expected behavior

Like pretty much every other Helm chart, these Helm charts should provide a way for the user to configure the CPU and Memory requests and limits for every container. If the containers use ephemeral storage, those requests and limits should be configurable as well.

Additional Context

https://github.com/actions/actions-runner-controller/issues/3257 shows what happens when runners run but the `dind` container does not, and the fix is to configure resource requests for both containers. Note that even though #3257 was opened against the Summerwind runner, that was fixed in Summerwind by moving the `dind` service into the runner container, so that Pods only have on running container and it has resource requests and limits.

Controller Logs

See #3257

Runner Pod Logs

See #3257

[nikola-jokic]

Hey @Nuru,

We do provide a way for you to configure runner pod spec. As specified here, the template is PodSpec definition, so you can customize it based on your needs. For dind, we documented here that container mode only provides the out-of-box spec, and if you need to customize it, we provided the expanded spec that you can use as a starting point.

Basically, you can control your runner pod definition however you'd like. The container mode only provides a shortcut, so you don't have to specify everything if the out-of-box implementation works for you.