Cannot launch job in k8s runner due to underscore in image name

Hi there,

I am trying to run a Github Actions job on a kubernetes runner. The job relies on some background services which run using a custom image. That image name contains an underscore character.

When the job is translated into a pod, the Kubernetes API rejects it due to the container name containing the underscore from the image name:

Error: failed to create job pod: Pod "mycluster-hw6sk-runner-8hv7x-workflow" is invalid: [spec.containers[3].name: Invalid value: "my_image": a lowercase RFC 1123 label must consist of lower case alphanumeric characters or '-', and must start and end with an alphanumeric character (e.g. 'my-name',  or '123-abc', regex used for validation is '[a-z0-9]([-a-z0-9]*[a-z0-9])?')

Setting --name or --hostname in the options field seems to have no effect.

The offending line seems to be here:
https://github.com/actions/runner-container-hooks/blob/main/packages/k8s/src/hooks/prepare-job.ts#L61

Blindly using the image name as the container name seems problematic for other reasons too.
e.g. what happens if you want to launch two background services that use the same image? Or two services with the same registry but different tags?

I am surprised that the key in the services: section is not used by default as this is the documented behaviour when running background services on the standard docker-based runners:

https://docs.github.com/en/actions/use-cases-and-examples/using-containerized-services/about-service-containers#running-jobs-in-a-container

I propose making a change to use the services key instead of the container registry name as the default container name in the kubernetes runner.

Example:

.github/workflows/my_job.yml
---
jobs:
  my_job:
      services:
        my-service:
          image: image_repo_cursed_with_underscores:latest
          ...

generated_podfile.yaml
---
spec:
  containers
    - name: my-service
      image: image_repo_cursed_with_underscores:latest

Start in packages/k8s/src/hooks/prepare-job.ts at the linked line, then reproduce the workflow using a service image with an underscore and inspect the generated pod definition. Confirm how service names are selected and make the result valid for Kubernetes, including multiple services, then verify that the example workflow produces the intended container names.