GitLab Runner Helm Chart

티어: Free, Premium, Ultimate 제공: GitLab.com, Self-managed

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

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

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

전제 조건

  • 클러스터에서 GitLab 서버의 API에 접근 가능해야 합니다.
  • Beta API가 활성화된 Kubernetes 1.4+가 필요합니다.
  • 로컬에 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

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

# 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.58.2        16.5.0      GitLab Runner
gitlab/gitlab-runner 0.58.1        16.5.0      GitLab Runner
gitlab/gitlab-runner 0.58.0        16.5.0      GitLab Runner
gitlab/gitlab-runner 0.57.2        16.4.2      GitLab Runner
gitlab/gitlab-runner 0.57.1        16.4.1      GitLab Runner
gitlab/gitlab-runner 0.57.0        16.4.0      GitLab Runner
...

Helm 차트를 사용하여 GitLab 러너 구성하기

GitLab 러너 구성을 위한 values.yaml 파일을 작성합니다. 기본값을 재정의하는 방법에 대한 정보는 Helm 문서를 참조하십시오.

기본 구성은 차트 저장소의 values.yaml에서 항상 찾을 수 있습니다.

필수 구성

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

추가 구성을 지정할 필요가 없는 경우, 이제 Helm 차트를 사용하여 GitLab 러너를 설치할 준비가 되었습니다.

추가 구성

구성 템플릿 파일을 사용하여 러너의 동작을 구성할 수 있으며, Helm 차트가 특정 러너 구성 옵션을 인식할 필요가 없습니다.

차트 저장소의 values.yaml 파일에서 찾을 수 있는 기본 설정의 일부입니다. config: 섹션의 경우, 형식은 toml이어야 합니다 (<parameter> = <value> 대신 <parameter>: <value>로 표시하지 않아야 합니다) config.toml을 values.yaml에 임베딩하고 있기 때문입니다. 

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

특정 실행자 구성은 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

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

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

Google Cloud Storage (GCS)

정적 자격 증명 직접 구성

다음 예는 액세스 ID 및 개인 키로 자격 증명을 구성하는 방법을 보여줍니다. GCS with credentials with an access ID and a private key : 

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

다음으로 gcs-access-id 및 gcs-private-key를 포함하는 gcsaccess 쿠버네티스 시크릿을 만듭니다. 

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

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

다음 예는 구글 클라우드 플랫폼에서 다운로드한 JSON 파일로 GCS를 구성하는 방법을 보여줍니다. configure GCS with credentials in a JSON file : 

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

다음으로 azure-account-name 및 azure-account-key를 포함하는 azureaccess 쿠버네티스 시크릿을 만듭니다. 

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

Helm Chart에서 캐싱에 대해 자세히 알아보려면 values.yaml을 참조하십시오.

RBAC 지원 활성화

클러스터에 RBAC가 활성화되어 있는 경우 차트가 자체 서비스 계정을 만들도록 하거나 별도로 제공할 수 있습니다.

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

rbac:
  create: true

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

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

최대 Runner 동시성 제어

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

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

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

dind를 실행하는 권한이있는 컨테이너에서 활성화하는 방법 및 Docker에서 dind 실행에 대한 GitLab Runner 문서를 참조하세요.

런너를 위한 권한 있는 컨테이너 실행

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

이것은 GitLab CI/CD Runner 문서에서 읽을 수있는 여러 위험과 함께 제공됩니다.

위험을 인정하고 GitLab Runner 인스턴스가 신뢰하는 특정 프로젝트의 CI 작업을 허용하는 경우 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의 권한이 상승된 상태여야 합니다. Google의 Kaniko는 권한이 상승되지 않은 상태에서 작동하는 대체품으로, Kubernetes GitLab Runner에서 테스트되었습니다.

GitLab에서 Kaniko로 최소 권한 컨테이너 빌드 동영상은 Kaniko Docker 빌드 실제 작업 예제 프로젝트를 안내합니다. 이 프로젝트는 Kaniko 및 GitLab CI/CD를 사용하여 이미지 빌드에 대한 문서를 활용합니다.

실제 작업 예제 프로젝트는 테스트를 위해 고객 자신의 그룹이나 인스턴스로 복사할 수 있습니다. 다른 GitLab CI 패턴이 프로젝트 페이지 Kaniko Docker Build에서 시연되는 자세한 내용을 확인할 수 있습니다.

비공개 레지스트리에서 이미지 사용

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

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

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

kubectl create secret docker-registry <시크릿_이름> \
  --namespace <네임스페이스> \
  --docker-server="https://<레지스트리_서버>" \
  --docker-username="<레지스트리_사용자명>" \
  --docker-password="<레지스트리_비밀번호>"

GitLab Runner Helm 차트 v0.53.x 이상에서는 values.yaml에서 더 이상 사용되지 않는 속성을 지원하지 않으며, runners.imagePullSecrets가 그 중 하나입니다. image_pull_secret를 구성하려면 사용자가 제공된 runners.config 템플릿에 설정해야 합니다. 

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

GitLab Runner Helm 차트 v0.52.x 이하에서는 runners.imagePullSecrets를 구성하면 컨테이너가 이미지 엔트리포인트 스크립트에 --kubernetes-image-pull-secrets "<시크릿_이름>"을 추가합니다. 이렇게 하면 Kubernetes 실행기 config.toml 설정에서 image_pull_secrets 매개변수를 구성할 필요가 없어집니다. 

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

형식에 주목하세요. 한 개 이상의 시크릿 이름의 배열이 필요합니다. 여러 레지스트리 자격 증명을 사용하더라도 반드시 필요합니다.

GitLab에 액세스하는 사용자 정의 인증서 제공

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

시크릿의 각 키 이름은 디렉터리에서의 파일 이름으로 사용되며, 파일 내용은 해당 키와 연결된 값입니다:

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

GitLab Helm 차트를 자동 생성된 와일드카드 자체 서명 인증서 방법을 사용하여 설치했다면 시크릿이 자동으로 생성됩니다. 

## certsSecretName을 설정하여 GitLab Runner에서 사용할 사용자 정의 인증서 전달
## 동일한 네임스페이스 내에서 Kubernetes Secret Object의 리소스 이름을 제공합니다.
## ref: 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 차트에서는 시크릿을 자동으로 생성하지 않습니다. 시크릿을 생성하려면 Kubernetes에게 인증서를 시크릿으로 저장하고 컨테이너에 파일로 제공하도록 지시해야 합니다. 이를 위해 다음 명령을 실행하세요: 

kubectl create secret generic <시크릿_이름> \
  --namespace <네임스페이스> \
  --from-file=<인증서_파일이름>

여기서:

  • <네임스페이스>는 GitLab Runner를 설치할 Kubernetes 네임스페이스입니다.
  • <시크릿_이름>은 Kubernetes Secret 리소스 이름입니다. (예: gitlab-domain-cert.)
  • <인증서_파일이름>은 현재 디렉터리에 있는 인증서의 파일 이름입니다. (예: cert-directory/my-gitlab-certificate.crt)

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

kubectl create secret generic <시크릿_이름> \
  --namespace <네임스페이스> \
  --from-file=<타겟_파일이름>=<인증서_파일이름>

여기서:

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

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


## GitLab 러너가 사용할 사용자 정의 인증서를 전달하도록 certsSecretName을 설정합니다
## 동일한 네임스페이스 내에서 Kubernetes Secret Object의 리소스 이름을 제공합니다.
## 이는 /home/gitlab-runner/.gitlab-runner/certs/ 디렉토리를 채우는 데 사용됩니다
## ref: https://docs.gitlab.com/runner/configuration/tls-self-signed.html#supported-options-for-self-signed-certificates
##
certsSecretName: <SECRET NAME>

여기서:

  • <SECRET_NAME>은 Kubernetes Secret 리소스 이름으로, 위 예제에서는 gitlab-domain-cert와 같습니다.

GitLab 러너가 이러한 인증서를 사용하는 방법에 대한 자세한 정보는 러너 문서에서 찾을 수 있습니다.

CI 환경 변수 키로 pod 레이블 설정

현재 values.yaml 파일 내에서 환경 변수를 pod 레이블로 사용하는 것은 불가능합니다. 우리는 이 문제에 대해 작업 중입니다: 환경 변수 키를 pod 레이블로 설정할 수 없음. 일시적인 해결책으로 이 문제에 설명된 워크어라운드를 사용하세요.

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

  • 16.1에서 도입되었습니다.

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

values.yml에 토큰을 저장하면 보안 위험이 될 수 있습니다, 특히 이를 git에 커밋하는 경우 더 그렇습니다. 대신 Kubernetes 시크릿 내에 이러한 토큰 값을 저장한 후, values.yml의 runners.secret 값을 시크릿의 이름으로 업데이트하세요.

이미 등록된 러너를 사용하려면 해당 러너를 식별하는 데 사용된 토큰으로 runner-token을 설정하세요. 새 러너를 등록하려면 runner-registration-token에 등록 토큰 (deprecated)을 설정하세요.

예:

  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의 값을 러너 등록에 사용합니다.

참고: 시크릿 관리 솔루션이 runner-registration-token에 빈 문자열을 설정할 수 없는 경우, 어떤 문자열이라도 설정할 수 있습니다 - 이는 runner-token이 있을 때 무시될 것입니다.

Ubuntu 기반의 gitlab-runner Docker 이미지로 전환

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

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

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

# 보안 컨텍스트 값을 Ubuntu 이미지의 사용자 ID로 업데이트하세요
securityContext:
  fsGroup: 999
  runAsUser: 999

root가 아닌 사용자로 실행

기본적으로 GitLab 러너 이미지는 root가 아닌 사용자로는 작동하지 않습니다. GitLab 러너 UBI 및 GitLab 러너 Helper UBI 이미지는 해당 시나리오를 위해 설계되었습니다. 이들을 사용하려면 GitLab 러너 및 GitLab 러너 Helper 이미지를 변경하세요:

참고: run_as_user가 nonroot 사용자(59417)의 사용자 ID를 가리키더라도, 이미지는 어떤 사용자 ID에서도 작동합니다. 이 사용자 ID가 root 그룹의 일부인 것이 중요합니다. root 그룹의 일부일 뿐이므로 특정 권한을 부여하지는 않습니다. 

image: registry.gitlab.com/gitlab-org/ci-cd/gitlab-runner-ubi-images/gitlab-runner-ocp:v16.5.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.5.0"
            [runners.kubernetes.pod_security_context]
              run_as_non_root = true
              run_as_user = 59417

FIPS 호환 GitLab 러너 사용하기

FIPS 호환 GitLab 러너를 사용하려면 다음과 같이 GitLab 러너 이미지와 헬퍼 이미지를 변경하세요: 

image: gitlab/gitlab-runner:ubi-fips

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

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

GitLab 러너를 제거하기 전에 GitLab에서 러너를 일시 중지하고 모든 작업이 완료되었는지 확인하세요. 러너를 일시 중지하면 작업 완료시 인가 오류와 같은 문제가 발생하는 것을 방지합니다.

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

helm delete --namespace <NAMESPACE> <릴리스 이름>

여기서:

Kubernetes 설치 문제 해결

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

다음 오류가 표시되면: 

Using Kubernetes executor with image alpine ...
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 파일을 확인하고 사용되지 않는 값을 사용하지 않도록 하세요. 사용되지 않는 값에 대한 자세한 내용은 GitLab Runner와 Helm 차트 설치하기를 참고하세요.