GitLab Runner Helm Chart

Tier: Free, Premium, Ultimate Offering: GitLab.com, Self-Managed

Kubernetes 클러스터로 GitLab Runner 인스턴스를 배포하는 공식 방법은 gitlab-runner Helm 차트를 사용하는 것입니다.

이 차트는 GitLab Runner를 다음과 같이 구성합니다:

  • GitLab Runner를 위한 Kubernetes executor를 사용하여 실행합니다.
  • GitLab CI/CD로부터 받은 각 새 작업에 대해 지정된 네임스페이스 내에서 새로운 파드를 프로비저닝하여 실행합니다.

전제 조건

  • 클러스터에서 GitLab 서버의 API에 접근할 수 있어야 합니다.
  • Kubernetes 1.4+ 및 Beta API가 활성화되어 있어야 합니다.
  • 로컬로 kubectl CLI가 설치되어 있고 클러스터에 대한 인증이 되어 있어야 합니다.
  • Helm 클라이언트가 로컬 머신에 설치되어 있어야 합니다.

Helm 차트를 사용하여 GitLab Runner 설치

GitLab Helm 리포지터리를 추가하세요: 

helm repo add gitlab https://charts.gitlab.io

Helm 2를 사용하는 경우 Helm을 초기화해야 합니다: 

helm init

만약 최신 버전의 GitLab Runner에 접근할 수 없는 경우 차트를 업데이트해야 합니다. 차트를 업데이트하려면 다음을 실행하세요: 

helm repo update gitlab

접근할 수 있는 GitLab Runner 버전 디렉터리을 보려면 다음을 실행하세요: 

helm search repo -l gitlab/gitlab-runner

values.yaml 파일에서 GitLab Runner를 구성한 후 다음을 실행하세요: 

# Helm 2를 위한
helm install --namespace <NAMESPACE> --name gitlab-runner -f <CONFIG_VALUES_FILE> gitlab/gitlab-runner

# Helm 3을 위한
helm install --namespace <NAMESPACE> gitlab-runner -f <CONFIG_VALUES_FILE> gitlab/gitlab-runner

여기서:

  • <NAMESPACE>는 GitLab Runner를 설치하려는 Kubernetes 네임스페이스입니다.
  • <CONFIG_VALUES_FILE>은 사용자 정의 구성을 담은 값 파일의 경로입니다. 이를 생성하려면 Helm 차트를 사용하여 GitLab Runner 구성 섹션을 참조하세요.

특정 버전의 GitLab Runner Helm 차트를 설치하려면 --version <RUNNER_HELM_CHART_VERSION>을 helm install 명령에 추가하세요. 이 방법으로 차트의 모든 버전을 설치할 수 있지만 더 최근의 values.yml이 이전 버전의 차트와 호환되지 않을 수 있습니다.

Helm 차트를 사용하여 GitLab Runner 업그레이드

GitLab Runner를 업그레이드하기 전에 GitLab에서 Runner를 일시 중지하고 모든 작업이 완료되었는지 확인하세요. Runner를 일시 중지하면 작업이 완료될 때 발생할 수 있는 권한 오류와 같은 문제를 방지할 수 있습니다.

GitLab Runner 차트가 설치되면 구성 변경 및 차트 업데이트는 helm upgrade를 사용하여 수행해야 합니다: 

helm upgrade --namespace <NAMESPACE> -f <CONFIG_VALUES_FILE> <RELEASE-NAME> gitlab/gitlab-runner

여기서:

가장 최신 버전이 아닌 특정 버전의 GitLab Runner Helm 차트로 업데이트하려면 --version <RUNNER_HELM_CHART_VERSION>를 helm upgrade 명령에 추가하세요.

사용 가능한 GitLab Runner Helm 차트 버전 확인

Helm 차트와 GitLab Runner 버전은 동일한 버전 체계를 따르지 않습니다. 다음 명령을 사용하여 Helm 차트와 GitLab Runner 간의 버전 매핑을 확인하세요: 

# Helm 2를 위한
helm search -l gitlab/gitlab-runner

# Helm 3을 위한
helm search repo -l gitlab/gitlab-runner

다음은 출력 예시입니다: 

NAME                  CHART VERSION APP VERSION DESCRIPTION
gitlab/gitlab-runner  0.64.0        16.11.0     GitLab Runner
gitlab/gitlab-runner  0.63.0        16.10.0     GitLab Runner
gitlab/gitlab-runner  0.62.1        16.9.1      GitLab Runner
gitlab/gitlab-runner  0.62.0        16.9.0      GitLab Runner
gitlab/gitlab-runner  0.61.3        16.8.1      GitLab Runner
gitlab/gitlab-runner  0.61.2        16.8.0      GitLab Runner
...

Helm 차트를 사용하여 GitLab Runner 구성

GitLab Runner 구성을 위한 values.yaml 파일을 만들어야 합니다. 값 파일이 기본값을 덮어쓰는 방식에 대한 정보는 Helm 문서를 참조하세요.

GitLab Runner가 작동하려면 구성 파일에 반드시 다음을 지정해야 합니다:

  • gitlabUrl: Runner를 등록할 GitLab 서버의 전체 URL입니다. 예: https://gitlab.example.com.
  • rbac: { create: true }: GitLab Runner가 작업을 실행하는 데 필요한 RBAC 규칙을 생성합니다. 사용하려는 기존 serviceAccount가 있는 경우 rbac: { serviceAccountName: "SERVICE_ACCOUNT_NAME" }도 설정해야 합니다. serviceAccount에 필요한 최소 권한에 대한 자세한 정보는 Runner API 권한 구성을 참조하세요.
  • runnerToken:

    - 또는 -

  • runnerRegistrationToken (deprecated in GitLab 15.6):
    • GitLab 인스턴스에서 검색한 등록 토큰입니다.
    • 토큰을 직접 지정하거나 시크릿에 저장할 수 있습니다.
    • 등록 토큰은 GitLab 17.0에서 제거될 예정입니다.

추가 구성을 지정할 필요가 없는 경우, 이제 GitLab Runner를 설치할 준비가 되었습니다.

추가 구성

구성 템플릿 파일을 사용하여 Kubernetes 내에서 GitLab Runner 빌드 파드의 동작을 구성할 수 있습니다. 이 구성 템플릿을 사용하면 Helm 차트가 특정 Runner 구성 옵션을 인식할 필요 없이 Runner 빌드 파드의 동작을 구성할 수 있습니다.

차트 리포지터리의 values.yaml 파일에 있는 기본 설정의 일부가 여기에 나와 있습니다. config: 섹션에서 config.toml을 values.yaml에 포함시키는 관계로, 이것이 toml 형식이어야 한다는 점에 유의해야 합니다(<parameter> = <value> 대신 <parameter>: <value>를 사용). 

runners:
  config: |
    [[runners]]
      [runners.kubernetes]
        image = "ubuntu:22.04"

Executor별 구성에 대한 정보는 values.yaml에 문서화되어 있습니다.

구성 템플릿을 사용하여 캐시 활용하기

구성 템플릿에서 캐시를 사용하려면 values.yaml에서 다음 변수를 설정하세요:

  • runners.cache.secretName: 오브젝트 스토리지 공급업체(s3access, gcsaccess, google-application-credentials, 또는 azureaccess)의 비밀 이름으로 설정합니다.
  • runners.config: 다른 캐시 설정을 사용합니다. toml 형식을 사용하세요.

S3

예를 들어 정적 자격 증명으로 S3를 구성하는 예는 다음과 같습니다: 

runners:
  config: |
    [[runners]]
      [runners.kubernetes]
        image = "ubuntu:22.04"
      [runners.cache]
        Type = "s3"
        Path = "runner"
        Shared = true
        [runners.cache.s3]
          ServerAddress = "s3.amazonaws.com"
          BucketName = "my_bucket_name"
          BucketLocation = "eu-west-1"
          Insecure = false
          AuthenticationType = "access-key"
  
  cache:
      secretName: s3access

다음으로, s3access 쿠버네티스 시크릿을 생성하고 accesskey와 secretkey를 포함시킵니다: 

kubectl create secret generic s3access \
    --from-literal=accesskey="YourAccessKey" \
    --from-literal=secretkey="YourSecretKey"

Google Cloud Storage (GCS)

정적 자격 증명 직접 구성

다음 예는 액세스 ID 및 개인 키로 GCS를 구성하는 방법을 보여줍니다: 

runners:
  config: |
    [[runners]]
      [runners.kubernetes]
        image = "ubuntu:22.04"
      [runners.cache]
        Type = "gcs"
        Path = "runner"
        Shared = true
        [runners.cache.gcs]
          BucketName = "runners-cache"
  
  cache:
    secretName: gcsaccess

다음으로, gcsaccess 쿠버네티스 시크릿을 생성하고 gcs-access-id와 gcs-private-key를 포함시킵니다: 

kubectl create secret generic gcsaccess \
    --from-literal=gcs-access-id="YourAccessID" \
    --from-literal=gcs-private-key="YourPrivateKey"

GCP에서 JSON 파일로 다운로드한 정적 자격 증명

다음 예는 GCP에서 JSON 파일로 정적 자격 증명을 구성하는 방법을 보여줍니다: 

runners:
  config: |
    [[runners]]
      [runners.kubernetes]
        image = "ubuntu:22.04"
      [runners.cache]
        Type = "gcs"
        Path = "runner"
        Shared = true
        [runners.cache.gcs]
          BucketName = "runners-cache"
  
  cache:
      secretName: google-application-credentials

secrets:
  - name: google-application-credentials

다음으로, google-application-credentials 쿠버네티스 시크릿을 생성하고 JSON 파일을 로드합니다: 

kubectl create secret generic google-application-credentials \
    --from-file=gcs-application-credentials-file=./path-to-your-google-application-credentials-file.json

Azure

다음 예는 Azure Blob Storage를 구성하는 방법을 보여줍니다: 

runners:
  config: |
    [[runners]]
      [runners.kubernetes]
        image = "ubuntu:22.04"
      [runners.cache]
        Type = "azure"
        Path = "runner"
        Shared = true
        [runners.cache.azure]
          ContainerName = "CONTAINER_NAME"
          StorageDomain = "blob.core.windows.net"
  
  cache:
      secretName: azureaccess

다음으로, azureaccess 쿠버네티스 시크릿을 생성하고 azure-account-name과 azure-account-key를 포함시킵니다: 

kubectl create secret generic azureaccess \
    --from-literal=azure-account-name="YourAccountName" \
    --from-literal=azure-account-key="YourAccountKey"

헬름 차트에서 캐싱에 대해 자세히 알아보려면 values.yaml를 확인하세요.

RBAC 지원 활성화

클러스터에서 RBAC를 활성화한 경우 차트가 자체 서비스 계정을 만들거나 직접 제공할 수 있습니다.

차트가 대신 서비스 계정을 생성하도록 하려면 rbac.create를 true로 설정하세요: 

rbac:
  create: true

기존의 서비스 계정을 사용하려면 다음을 사용하세요: 

rbac:
  create: false
  serviceAccountName: your-service-account

최대 Runner 동시성 제어

쿠버네티스에 배포된 단일 GitLab Runner는 여러 작업을 병렬로 실행하여 자동으로 추가 Runner 파드를 시작할 수 있습니다. concurrent 설정은 한 번에 허용되는 최대 파드 수를 제어하며 기본값은 10입니다: 

## 최대 동시 작업 수를 구성합니다
## ref: https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-global-section
##
concurrent: 10

GitLab Runner에서 Docker-in-Docker 컨테이너 실행

Docker-in-Docker로 컨테이너를 실행하는 것을 보려면 러너용 권한이 있는 컨테이너 실행을 참조하고, GitLab Runner 문서에서 dind를 실행하는 내용을 확인하세요(../executors/kubernetes/index.md#using-docker-in-builds).

러너용 권한이 있는 컨테이너 실행

GitLab Runner에게 권한이 있는 컨테이너를 실행하도록 지시할 수 있습니다. GitLab CI/CD 작업에서 Docker 실행 파일을 사용해야 하는 경우에는 이를 활성화해야 할 수 있습니다.

Risk란?에 대한 정보를 읽으세요.

리스크를 받아들일 수 있고 GitLab Runner 인스턴스가 신뢰할 수 있는 GitLab의 특정 프로젝트에 등록되어 있다면, values.yaml에서 권한 있는 모드를 활성화할 수 있습니다: 

runners:
  config: |
    [[runners]]
      [runners.kubernetes]
        # 모든 컨테이너를 권한 있는 플래그로 실행합니다.
        # 자세한 내용은 https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-runnerskubernetes-section에서 확인하세요.
        privileged = true
        ...

권한이 있는 모드 없이 컨테이너 빌드하는 모베애트

Docker-in-Docker로 컨테이너 내에서 컨테이너를 빌드하려면 Docker에 권한이 필요합니다. 구글의 Kaniko는 권한이 없이 작동하는 대안이며, 쿠버네티스 GitLab Runner에서 테스트되었습니다.

GitLab에서 Kaniko를 사용한 최소 권한 컨터이너 빌드 동영상은 Kaniko Docker Build 작업 예제 프로젝트의 안내를 제공합니다. Kaniko와 GitLab CI/CD를 사용한 이미지 빌드 문서의 내용을 사용합니다.

동작하는 예제 프로젝트는 테스트를 위해 자신의 그룹이나 인스턴스로 복사할 수 있습니다. 기타 GitLab CI 패턴에 대한 자세한 내용은 프로젝트 페이지 Kaniko Docker Build에서 확인할 수 있습니다.

사설 레지스트리에서 이미지 사용

사설 레지스트리에서 이미지를 사용하려면 imagePullSecrets의 구성이 필요합니다. imagePullSecrets를 생성하는 방법에 대한 자세한 내용은 문서를 참조하세요.

CI/CD 작업에 사용되는 Kubernetes 네임스페이스에 하나 이상의 시크릿을 생성해야 합니다.

다음 명령을 사용하여 image_pull_secrets와 호환되는 시크릿을 생성할 수 있습니다: 

kubectl create secret docker-registry <SECRET_NAME> \
  --namespace <NAMESPACE> \
  --docker-server="https://<REGISTRY_SERVER>" \
  --docker-username="<REGISTRY_USERNAME>" \
  --docker-password="<REGISTRY_PASSWORD>"

GitLab Runner Helm Chart v0.53.x 이상에서는 values.yaml 및 runners.imagePullSecrets에서 더 이상 사용되지 않는 속성을 지원하지 않습니다. 그 중 하나가 image_pull_secrets입니다. 사용자는 runners.config에서 제공된 config.toml 템플릿에 설정해야 합니다. 

runners:
  config: |
    [[runners]]
      [runners.kubernetes]
        ## 하나 이상의 imagePullSecrets를 지정합니다
        ## 참조: https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/
        ##
        image_pull_secrets = [your-image-pull-secret]

GitLab Runner Helm Chart v0.52.x 및 이전 버전에서는 runners.imagePullSecrets를 구성하면 컨테이너가 이미지 entrypoint 스크립트에 --kubernetes-image-pull-secrets "<SECRET_NAME>"를 추가합니다. 이로써 Kubernetes 실행기 config.toml 설정에서 image_pull_secrets 매개변수를 구성할 필요가 없어집니다. 

runners:
  imagePullSecrets: [your-image-pull-secret]

형식에 유의하십시오. 값은 Kubernetes 리소스에서의 규칙인 name 태그로 시작되지 않습니다. 다중 레지스트리 자격 증명을 사용하든 사용하지 않든 하나 이상의 시크릿 이름 배열이 필요합니다.

GitLab 액세스를 위한 사용자 정의 인증서 제공

GitLab Runner Helm Chart에 Kubernetes Secret를 제공하여 컨테이너의 /home/gitlab-runner/.gitlab-runner/certs 디렉터리를 채울 수 있습니다.

시크릿의 각 키 이름은 디렉터리의 파일 이름으로 사용되며, 파일 내용은 키와 관련된 값입니다:

  • 사용된 키/파일 이름은 <gitlab.hostname>.crt 형식이어야 합니다. 예를 들어 gitlab.your-domain.com.crt입니다.
  • 중간 인증서는 서버 인증서와 동일한 파일에 연결해야 합니다.
  • 사용된 호스트 이름은 인증서가 등록된 호스트 이름이어야 합니다.

GitLab Helm Chart를 자동 생성된 자체 서명 와일드카드 인증서 방법으로 설치한 경우 자동으로 시크릿이 생성됩니다. 

## GitLab Runner가 사용할 커스텀 인증서를 전달하려면 certsSecretName을 설정합니다
## 동일한 네임스페이스에서 Kubernetes Secret Object의 리소스 이름을 제공합니다
## 이것은 /home/gitlab-runner/.gitlab-runner/certs/ 디렉터리를 채우는 데 사용됩니다
## 참조: https://docs.gitlab.com/runner/configuration/tls-self-signed.html#supported-options-for-self-signed-certificates-targeting-the-gitlab-server
##
certsSecretName: RELEASE-wildcard-tls-chain

GitLab Runner Helm Chart는 시크릿을 자동으로 생성하지 않습니다. 시크릿을 생성하려면 Kubernetes에게 인증서를 시크릿으로 저장하도록 지시하고 해당 인증서를 GitLab Runner 컨테이너에 파일로 제공합니다. 이를 위해 다음 명령을 실행하세요: 

kubectl create secret generic <SECRET_NAME> \
  --namespace <NAMESPACE> \
  --from-file=<CERTIFICATE_FILENAME>

여기서:

  • <NAMESPACE>는 GitLab Runner를 설치할 Kubernetes 네임스페이스입니다.
  • <SECRET_NAME>은 Kubernetes 시크릿 리소스 이름입니다. (예: gitlab-domain-cert).
  • <CERTIFICATE_FILENAME>은 시크릿으로 가져올 현재 디렉터리의 인증서 파일 이름입니다.

소스 파일 <CERTIFICATE_FILENAME>이 현재 디렉터리에 없거나 <gitlab.hostname.crt> 형식을 따르지 않는 경우 대상에 사용할 파일 이름을 지정해야 합니다: 

kubectl create secret generic <SECRET_NAME> \
  --namespace <NAMESPACE> \
  --from-file=<TARGET_FILENAME>=<CERTIFICATE_FILENAME>

여기서:

  • <TARGET_FILENAME>은 Runner 컨테이너에 제시된 인증서 파일 이름입니다. (예: gitlab.hostname.crt).
  • <CERTIFICATE_FILENAME>은 시크릿으로 가져올 현재 디렉터리 상대 경로의 인증서 파일 이름입니다. (예: cert-directory/my-gitlab-certificate.crt)

그런 다음 시크릿 이름을 GitLab Runner 차트에 제공해야 합니다. 다음과 같이 values.yaml에 추가하세요: 

## GitLab Runner가 사용할 커스텀 인증서를 전달하려면 certsSecretName을 설정합니다
## 동일한 네임스페이스에 있는 Kubernetes Secret Object의 리소스 이름을 제공합니다
## 이것은 /home/gitlab-runner/.gitlab-runner/certs/ 디렉터리를 채우는 데 사용됩니다
## 참조: https://docs.gitlab.com/runner/configuration/tls-self-signed.html#supported-options-for-self-signed-certificates
##
certsSecretName: <SECRET NAME>

여기서:

  • <SECRET NAME>은 위의 예제와 같이 Kubernetes 시크릿 리소스 이름입니다.

GitLab Runner가 이러한 인증서를 어떻게 사용하는지에 대한 자세한 정보는 Runner Documentation에서 찾을 수 있습니다.

Pod 라벨을 CI 환경 변수 키로 설정

현재 values.yaml 파일에서 환경 변수를 pod 라벨로 사용하는 것은 불가능합니다. 우리는 이 이슈에서 작업 중입니다: 환경 변수 키를 pod 라벨로 설정할 수 없음. 일시적인 해결책으로 작업에 설명된 해결 방법을 사용하세요.

등록 토큰 또는 러너 토큰을 시크릿에 저장

  • 16.1에서 소개되었습니다.

GitLab UI에서 생성된 러너를 등록하려면 values.yml에서 runnerToken을 지정합니다. runnerToken은 러너를 생성할 때 UI에 잠시 표시됩니다.

values.yml에 토큰을 저장하는 것은 특히 git에 이러한 값을 커밋하는 경우 보안 위험을 초래할 수 있습니다. 대신 이러한 토큰의 값을 Kubernetes 시크릿에 저장한 후 values.yml의 runners.secret 값을 해당 시크릿의 이름으로 업데이트할 수 있습니다.

기존에 등록된 러너를 사용하려면 runner-token으로 해당 러너를 식별하는 데 사용된 토큰을 설정하세요. 새 러너를 등록하려면 registration token (deprecated)인 runner-registration-token을 설정할 수 있습니다.

예를 들어:

  1. 등록 토큰과 함께 시크릿 생성 
apiVersion: v1
kind: Secret
metadata:
  name: gitlab-runner-secret
type: Opaque
data:
  runner-registration-token: "" # 호환성 문제로 비어 있는 문자열로 남겨야 함
  runner-token: "REDACTED"

kubectl apply --namespace <NAMESPACE> -f gitlab-runner-secret.yaml
  1. 다음을 values.yaml에 구성하세요: 
runners:
  secret: gitlab-runner-secret

이 예제는 시크릿 gitlab-runner-secret을 사용하고 runner-token의 값을 러너 등록에 사용합니다.

note
시크릿 관리 솔루션이 runner-registration-token에 빈 문자열을 설정할 수 없는 경우 임의의 문자열로 설정할 수 있습니다. 이 경우 runner-token이 존재할 때 무시될 것입니다.

Ubuntu 기반 gitlab-runner 도커 이미지로 변경

기본적으로 GitLab 러너 Helm 차트는 gitlab/gitlab-runner 이미지의 Alpine 버전을 사용하며, 해당 이미지는 musl libc를 사용합니다. 경우에 따라 Ubuntu 기반 이미지를 사용하고 싶을 수 있으며, 이 이미지는 glibc를 사용합니다.

이를 위해 다음과 같이 values.yaml 파일을 업데이트하세요: 

# Ubuntu 이미지를 지정합니다. 버전을 설정하는 것을 잊지 마세요. `ubuntu` 또는 `latest` 태그를 사용할 수도 있습니다.
image: gitlab/gitlab-runner:v16.5.0

# 보안 컨텍스트 값을 Ubuntu 이미지의 사용자 ID로 업데이트합니다.
securityContext:
  fsGroup: 999
  runAsUser: 999

루트가 아닌 사용자로 실행

기본적으로 GitLab 러너 이미지는 루트가 아닌 사용자와 함께 작동하지 않습니다. GitLab 러너 UBI 및 GitLab 러너 Helper UBI 이미지는 이러한 시나리오를 고려하여 설계되었습니다. 이를 위해 GitLab 러너 및 GitLab 러너 Helper 이미지를 변경하세요:

:::노트 run_as_user가 nonroot 사용자(59417)의 사용자 ID를 가리키더라도 이미지는 모든 사용자 ID와 작동합니다. 이 사용자 ID가 루트 그룹의 일부인 것이 중요합니다. 루트 그룹에 속해 있는 것은 특정 권한을 부여해 주지는 않습니다. 

image:
  registry: registry.gitlab.com
  image: gitlab-org/ci-cd/gitlab-runner-ubi-images/gitlab-runner-ocp
  tag: v16.11.0

securityContext:
    runAsNonRoot: true
    runAsUser: 999

runners:
    config: |
        [[runners]]
          [runners.kubernetes]
            helper_image = "registry.gitlab.com/gitlab-org/ci-cd/gitlab-runner-ubi-images/gitlab-runner-helper-ocp:x86_64-v16.11.0"
            [runners.kubernetes.pod_security_context]
              run_as_non_root = true
              run_as_user = 59417

FIPS(연방 정보 처리 표준) 호환 GitLab 러너 사용

FIPS(연방 정보 처리 표준) 호환 GitLab 러너를 사용하려면 다음과 같이 GitLab 러너 이미지 및 Helper 이미지를 변경하세요: 

image:
  registry: docker.io
  image: gitlab/gitlab-runner
  tag: ubi-fips

runners:
    config: |
        [[runners]]
          [runners.kubernetes]
            helper_image_flavor = "ubi-fips"

Helm 차트를 사용하여 GitLab 러너 제거

GitLab 러너를 제거하기 전에 GitLab에서 러너를 일시 중지하고 모든 작업이 완료되었는지 확인하세요. 러너를 일시 중지하면 작업이 완료될 때 발생할 수 있는 권한 에러와 같은 문제를 예방할 수 있습니다.

GitLab 러너 Helm 차트를 제거하려면 다음을 실행하세요: 

helm delete --namespace <NAMESPACE> <RELEASE-NAME>

여기서:

  • <NAMESPACE>은 GitLab 러너가 설치된 Kubernetes 네임스페이스입니다.
  • <RELEASE-NAME>은 설치할 때 차트에 지정한 이름입니다. Helm 차트를 사용하여 GitLab 러너 설치 섹션에서는 gitlab-runner로 지정했습니다.

Kubernetes 설치 문제 해결

ERROR: Job failed (system failure): secrets is forbidden

다음과 같은 오류가 표시된다면: 

Alpine 이미지를 사용하여 Kubernetes 실행기를 사용 중...
ERROR: Job failed (system failure): secrets is forbidden: User "system:serviceaccount:gitlab:default" cannot create resource "secrets" in API group "" in the namespace "gitlab"

오류를 수정하려면 RBAC 지원 활성화하세요.

Unable to mount volumes for pod

필요한 시크릿을 위한 마운트 볼륨 오류가 발생한다면, 등록 토큰이나 러너 토큰을 시크릿에 저장했는지 확인하세요.

Google Cloud Storage로의 느린 아티팩트 업로드

Google Cloud Storage로의 아티팩트 업로드는 러너 도우미 파드가 CPU에 바인딩되어 성능이 저하될 수 있습니다. 이것은 느린 대역폭 속도로 나타납니다.

이를 완화하기 위해 도우미 파드 CPU 한도를 높이세요: 

runners:
  config: |
    [[runners]]
      [runners.kubernetes]
        helper_cpu_limit = "250m"

PANIC: creating directory: mkdir /nonexistent: permission denied

이 오류를 해결하려면 Ubuntu 기반 GitLab 러너 도커 이미지로 전환하세요.

FATAL: Runner configuration other than name and executor configuration is reserved (specifically –locked, –access-level, –run-untagged, –maximum-timeout, –paused, –tag-list, and –maintenance-note) and cannot be specified when registering with a runner authentication token. This configuration is specified on the GitLab server. Please try again without specifying any of those arguments

이 오류는 GitLab 러너 Helm 차트를 설치한 후에 파드 로그에서 발생할 수 있습니다. 이것은 인증 토큰을 사용하고 시크릿을 통해 토큰을 제공했을 때 발생합니다. 이 오류를 해결하려면 값을 YAML 파일을 검토하고 사용되지 않는 값을 사용하지 않도록 확인하세요. 사용되지 않는 값을 확인하는 데 도움이 되는 정보에 대해서는 Helm 차트를 사용하여 GitLab 러너 설치를 참조하세요.