Modifying pod templates with containermode.type=kubernetes

[nikolamarunic]

Hello,

My current understanding of containermode.type=kubernetes is that there is essentially two pods that are spun up by the action, one being the 'runner' that communicates with GitHub and the other the 'worker' which is where the actual job will run.

My question is related to modifying the pod template for the worker (for example, if we want to add some sort of resource requests/limits/etc). I think this would also be useful i.e to inject Kubernetes secrets into the worker pods.

Is it currently possible to modify this worker pod template? I know we can modify the values.yml which will affect the runner pod, but it doesn't seem to apply the same fields to the other pod that is created. I see some similar discussions but don't see any official solution.

Thanks in advance!

[nikola-jokic]

Hey @nikolamarunic,

You can use hook extensions to customize job pods that are created by the kubernetes hook. Probably the best way to do so is to create a config map and mount it on the runner. Set the env to point to the hook extension file and the hook should apply the spec according to the ADR. ☺️

[nikolamarunic]

Thank you Nikola - will look into using this :)

[David9902]

@nikola-jokic
It would be great if an example could be added to the documentation on how to add resource limits (cpu and memory) to the workflow container that is spawened by the runner.

[rteeling-evernorth]

@David9902
For posterity, this is in the examples folder of the runner container hooks repo here: https://github.com/actions/runner-container-hooks/blob/main/examples/extension.yaml

[jonwest]

Thanks for that @rteeling-evernorth!

I'm confused by the implementation, based on the documentation. 😅

In the limitations section of the README it says:

• Container actions will not have access to the services network or job container network

In the example you provided, there is a redis service mentioned.

I've got a couple of questions regarding the two links above, and how they correspond with each other:

• If the container action doesn't have access to the services network, or the job container network, then how does it communicate with the redis service?
• If the container action cannot communicate with the redis service, then what would the redis service be used for?
• Related to the second question—what would be the use case for any sidecars alongside the runner if they cannot be used by the action? Metrics, maybe?

[cgiraldo]

The redis service container and the job container will be part of the same pod, so they share the network namespace.

You can access redis port from the job container using localhost or 127.0.0.1.