mirror of
https://gitea.com/gitea/act_runner.git
synced 2026-10-29 03:16:43 +08:00
755af87095
On Kubernetes a service is reached by its id made a DNS label, so some service ids might become unreachable. For example, the `devstoreaccount1.azurite.local` service of Gitea's [MSSQL tests](2fe74d3cdd/.github/workflows/pull-db-tests.yml (L229)) is only in the pod's hosts as `devstoreaccount1-azurite-local`, while the tests connect to the id as written. Container names must be DNS labels, but `hostAliases` accepts DNS subdomains, so an id that is one is now added there too, and to `no_proxy`, as on Docker where a service is reached by its id.
The warning for a service not reachable by its id now also covers ids that differ only in case, as Kubernetes hostnames are lowercase.
---------
Co-authored-by: silverwind <me@silverwind.io>
Reviewed-on: https://gitea.com/gitea/runner/pulls/1320
Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com>
Reviewed-by: bircni <bircni@icloud.com>
Reviewed-by: silverwind <2021+silverwind@noreply.gitea.com>
Co-authored-by: Zettat123 <39446+zettat123@noreply.gitea.com>
59 lines
3.4 KiB
Markdown
59 lines
3.4 KiB
Markdown
# Jobs as Kubernetes pods
|
|
|
|
A `kubernetes` label runs each job as a pod, without a Docker daemon:
|
|
|
|
```text
|
|
ubuntu-latest:kubernetes://docker.gitea.com/runner-images:ubuntu-latest
|
|
```
|
|
|
|
The pod has a `job` container from the label's image or the job's `container.image`, plus one container per service.
|
|
|
|
## Setup
|
|
|
|
In a cluster, the runner uses its pod's service account and namespace. [`examples/kubernetes/kubernetes-pods.yaml`](../examples/kubernetes/kubernetes-pods.yaml) deploys a runner with these permissions:
|
|
|
|
| Resource | Verbs |
|
|
| --- | --- |
|
|
| `pods` | `create`, `get`, `list`, `delete` |
|
|
| `pods/exec` | `create`, `get` |
|
|
| `pods/log` | `get` |
|
|
| `secrets` | `create`, `delete` |
|
|
|
|
Outside a cluster, it uses the current context of the first file in `$KUBECONFIG`, or of `~/.kube/config`, which must authenticate with a token, token file or client certificate. The cluster must run Kubernetes 1.30 or later, and job images need `sh`, `tar`, `tail` and `env`.
|
|
|
|
## Configuration
|
|
|
|
```yaml
|
|
kubernetes:
|
|
kubeconfig: "" # instead of the service account
|
|
namespace: "" # defaults to the service account's, the kubeconfig context's, or default
|
|
pod_template: # merged under each job pod, a container named job merges into the job container, one named $services into each service container
|
|
spec:
|
|
containers:
|
|
- name: job
|
|
resources:
|
|
limits:
|
|
memory: 4Gi
|
|
- name: $services
|
|
resources:
|
|
limits:
|
|
memory: 1Gi
|
|
pod_templates: # merged over pod_template for jobs whose runs-on has the label they are keyed by
|
|
gpu:
|
|
spec:
|
|
nodeSelector:
|
|
nvidia.com/gpu.present: "true"
|
|
```
|
|
|
|
A job with `runs-on: [linux, gpu]` gets the `linux` and then the `gpu` entry of `pod_templates` merged over `pod_template`, while its image comes from the first of its labels the runner has. A template volume named `workspace` or `act` replaces the `emptyDir` the runner mounts at the workspace or at `/var/run/act`, for example to limit its size. Images are pulled by the cluster's `imagePullPolicy` default, a template's, or always with `container.force_pull`. Like every config value, templates expand `${NAME}` from the runner's environment, so a shell command in a template writes `$${NAME}` for the pod's own variable.
|
|
|
|
Job pods mount no service account token unless the template sets `automountServiceAccountToken: true`. Job pods and their Secrets are labeled `app.kubernetes.io/managed-by: gitea-runner` and `com.gitea.runner.uuid: <runner UUID>`. The idle cleanup removes those the runner did not get to remove, once they are older than `runner.workdir_cleanup_age`.
|
|
|
|
## Services
|
|
|
|
Services share the pod's network, so a step reaches one by its id or `localhost`, and two services cannot listen on the same port. An id that is not a valid hostname is sanitized, so `my_db` is reached as `my-db`. Pass secrets to services through `env`, as `command` is visible in the pod spec. Of `options`, only `--health-*` is supported. They become a startup probe with Docker's defaults, which stops a service that fails its retries, so the job fails as on Docker.
|
|
|
|
## Unsupported
|
|
|
|
Docker actions, `docker://` steps, and the `options`, `volumes` and `credentials` of the job container fail the job, as do `volumes` and `credentials` of services. Run such workflows on a [Docker in Docker](../examples/kubernetes/README.md) runner. Pull private images with `imagePullSecrets` in `pod_template`.
|