설치

경고: 기본 Operator 구성은 운영용으로 사용되지 않습니다. 기본 리소스는 모든 GitLab 서비스가 클러스터에 배포되는 구현을 생성하며, 이는 운영 워크로드에 적합하지 않습니다. 운영 배포를 위해 Cloud Native Hybrid 참조 아키텍처를 따르셔야 합니다.

참고: GitLab Operator는 활발히 개발 중이며 아직 운영용으로 적합하지 않습니다. 자세한 내용은 Minimal to Viable Epic을 확인하십시오.

이 문서에서는 Kubernetes 또는 OpenShift 클러스터의 manifest를 사용하여 GitLab Operator를 배포하는 방법에 대해 설명합니다.

OpenShift을 사용하는 경우, 최신 Operator 이미지를 테스트하려면 사용자들이 Operator 리포지토리에서 제공하는 배포 manifest를 사용하여 Operator를 설치해야 할 수 있습니다. 보통 이러한 단계는 Operator Lifecycle Manager (OLM)에서 처리됩니다.

전제 조건

  1. Kubernetes 또는 OpenShift 클러스터를 생성하거나 기존 클러스터를 사용
  2. 사전 필수 서비스 및 소프트웨어 설치
  3. 도메인 이름 서비스 구성

클러스터

Kubernetes

전통적인 Kubernetes 클러스터를 생성하려면 공식 도구나 선호하는 설치 방법을 고려하십시오.

GitLab Operator는 다음 Kubernetes 버전을 지원합니다:

Kubernetes 릴리스 상태 최소 Operator 버전 아키텍처 지원 종료일
1.27 지원됨 0.29.0 x86-64 2024-06-28
1.26 지원됨 0.24.0 x86-64 2024-02-28
1.25 지원됨 0.24.0 x86-64 2023-10-28
1.24 사용 중단됨 0.24.0 x86-64 2023-07-28
1.23 사용 중단됨 0.24.0 x86-64 2023-02-28
1.22 사용 중단됨 0.24.0 x86-64 2022-10-28
OpenShift

OpenShift 클러스터를 생성하려면 _개발 환경_을 만드는 예시인 OpenShift 클러스터 설정 문서를 참조하십시오.

GitLab Operator는 다음 OpenShift 버전을 지원합니다:

OpenShift 릴리스 상태 최소 Operator 버전 아키텍처 지원 종료일
4.15 개발/인증 중   x86-64 2025-08-27
4.14 지원됨 0.27.0 x86-64 2025-05-01
4.13 지원됨 0.24.0 x86-64 2024-11-17
4.12 지원됨 0.24.0 x86-64 2024-07-17
4.11 사용 중단됨 0.24.0 x86-64 2024-02-10

GitLab Operator는 초기 릴리즈로부터 3개월 후에 새로운 minor Kubernetes 및 OpenShift 버전을 지원할 계획입니다. 위에 나열된 것보다 최신 릴리즈에 대한 호환성 문제를 언제든지 우리의 이슈 트래커에서 알려주십시오.

고인도서 및 위에 나열된 버전보다 오래된 버전에서는 일부 GitLab 기능이 작동하지 않을 수 있습니다.

클러스터 버전 지원을 위한 Kubernetes용 에이전트GitLab 차트와 같은 몇 가지 구성 요소의 경우, GitLab은 다른 클러스터 버전을 지원할 수 있습니다.

16.7부터 Operator는 x86-64 및 arm64로 빌드되었습니다. arm64 이미지는 CI에서 테스트되지 않으며 운영용으로 권장되지 않습니다.

멀티-아키텍처 클러스터를 사용 중이라면 노드 선택자를 Operator 배포에 대한 values.yaml에 추가할 수 있습니다.

다음 명령을 사용하여 Operator 배포가 amd64 노드에 예약되도록 배포를 패치하십시오:

kubectl patch deployments gitlab-controller-manager \
  -p '{"spec": {"template": {"spec": {"nodeSelector": {"kubernetes.io/arch": "amd64"}}}}}'

Operator Helm 차트를 사용하는 경우 values.yaml에 노드 선택자를 추가할 수 있습니다:

nodeSelector:
  kubernetes.io/arch: amd64

현재 테스트 중인 플랫폼을 사용하여 Operator가 amd64 노드에서 실행되도록 보장합니다.

CNG 이미지의 arm64 지원에 대한 자세한 내용은 epic 10928을 참조하십시오.

인그레스 컨트롤러

응용 프로그램에 대한 외부 액세스 및 구성 요소 간 안전한 통신을 제공하려면 인그레스 컨트롤러가 필요합니다.

기본적으로 GitLab Operator는 GitLab Helm Chart의 fork된 NGINX 차트를 배포합니다.

외부 인그레스 컨트롤러를 사용하려면 쿠버네티스 커뮤니티의 NGINX Ingress를 사용하여 인그레스 컨트롤러를 배포하세요. 플랫폼 및 선호하는 도구에 따라 링크의 관련 지침을 따르세요. 나중에 사용할 인그레스 클래스 값을 주의하세요(일반적으로 nginx로 기본 설정됨). GitLab CR을 구성할 때 nginx-ingress.enabled=false로 설정하여 GitLab Helm Chart에서 NGINX 개체를 비활성화하세요.

TLS 인증서

오퍼레이터의 쿠버네티스 웹훅을 위해 cert-manager를 사용하여 인증서를 생성합니다. GitLab 인증서에도 cert-manager를 사용해야 합니다.

오퍼레이터가 쿠버네티스 웹훅을 위해 인증서가 필요하기 때문에 GitLab Chart에 번들된 cert-manager를 사용할 수 없습니다. 대신 오퍼레이터를 설치하기 전에 cert-manager를 설치하세요.

cert-manager를 설치하려면 플랫폼 및 도구에 대한 설치 문서를 참조하세요.

저희 코드베이스는 cert-manager 1.6.1을 대상으로 합니다.

참고: cert-manager 1.6는 일부 사용되지 않는 API를 삭제하여, cert-manager 1.6 이상을 배포하는 경우, 적어도 GitLab Operator 0.4가 필요합니다.

메트릭

Kubernetes

수평 팟 오토스케일러가 팟 메트릭을 검색할 수 있도록 메트릭 서버를 설치하세요.

OpenShift

오픈시프트는 기본적으로 Prometheus Adapter이 함께 제공되므로 여기서 수동 작업이 필요하지 않습니다.

도메인 이름 서비스 구성

DNS 레코드를 추가할 수 있는 인터넷 액세스 가능한 도메인이 필요합니다.

GitLab 구성 요소와 도메인을 연결하는 자세한 내용은 네트워킹 및 DNS 문서를 참조하세요. GitLab 사용자 지정 리소스(CR)를 정의할 때이 섹션에서 언급된 구성을 사용합니다.

오픈시프트에서의 인그레스는 추가 고려 사항이 필요합니다. 자세한 내용은 오픈시프트 인그레스에 대한 노트를 참조하세요.

GitLab Operator 설치

  1. GitLab Operator를 배포합니다.

    GL_OPERATOR_VERSION=<원하는_버전> # https://gitlab.com/gitlab-org/cloud-native/gitlab-operator/-/releases
    PLATFORM=kubernetes # 또는 "openshift"
    kubectl create namespace gitlab-system
    kubectl apply -f https://gitlab.com/api/v4/projects/18899486/packages/generic/gitlab-operator/${GL_OPERATOR_VERSION}/gitlab-operator-${PLATFORM}-${GL_OPERATOR_VERSION}.yaml
    

    이 명령은 우선 오퍼레이터가 사용하는 서비스 계정, 역할 및 역할 바인딩을 배포한 다음 오퍼레이터 자체를 배포합니다.

    기본적으로 Operator는 배포된 네임스페이스를 감시합니다. 대신 클러스터 범위에서 감시하려면 매니페스트의 Deployment에서 WATCH_NAMESPACE 환경 변수를 제거하고 위의 kubectl apply 명령을 다시 실행하세요.

    참고: 클러스터 범위에서 Operator를 실행하는 것은 실험적으로 간주됩니다. 자세한 정보는 이슈 #100를 참조하세요.

    실험적인: 또는 Helm을 통해 GitLab Operator를 배포하세요.

    helm repo add gitlab-operator https://gitlab.com/api/v4/projects/18899486/packages/helm/stable
    helm repo update
    helm install gitlab-operator gitlab-operator/gitlab-operator --create-namespace --namespace gitlab-system
    
  2. GitLab 사용자 지정 리소스(CR)를 생성합니다.

    mygitlab.yaml와 같은 이름으로 새 파일을 만듭니다.

    이 파일에 넣을 내용의 예는 다음과 같습니다.

    apiVersion: apps.gitlab.com/v1beta1
    kind: GitLab
    metadata:
      name: gitlab
    spec:
      chart:
        version: "X.Y.Z" # https://gitlab.com/gitlab-org/cloud-native/gitlab-operator/-/blob/0.8.1/CHART_VERSIONS
        values:
          global:
            hosts:
              domain: example.com # 실제 도메인을 사용하세요
            ingress:
              configureCertmanager: true
          certmanager-issuer:
            email: youremail@example.com # 실제 이메일 주소를 사용하세요
    

    spec.chart.values 아래에서 사용할 구성 옵션에 대한 자세한 내용은 GitLab Helm Chart 문서를 참조하세요.

  3. 새 GitLab CR을 사용하여 GitLab 인스턴스를 배포합니다.

    kubectl -n gitlab-system apply -f mygitlab.yaml
    

    이 명령은 GitLab CR을 클러스터로 보내어 GitLab Operator가 조정하도록 합니다. 컨트롤러 팟에서 로그를 테일링하여 진행 상황을 확인할 수 있습니다.

    kubectl -n gitlab-system logs deployment/gitlab-controller-manager -c manager -f
    

    또한 GitLab 리소스를 나열하여 상태를 확인할 수 있습니다.

    kubectl -n gitlab-system get gitlab
    NAME     STATUS   VERSION
    gitlab   Ready    5.2.4
    

    CR이 조정될 때(GitLab 리소스의 상태가 Running인 경우), 브라우저에서 https://gitlab.example.com으로 GitLab에 액세스할 수 있습니다.

로그인하려면 배포의 초기 루트 암호를 검색해야 합니다. 추가 지침은 Helm Chart 문서를 참조하세요.

추천하는 다음 단계

설치를 완료한 후, 인증 옵션 및 가입 제한 사항을 포함한 추천하는 다음 단계을 고려해 보세요.

OpenShift

OpenShift를 실행하는 경우 GitLab Operator의 승인 전략을 기본적으로 자동에서 수동으로 변경하세요. 이는 새로운 오퍼레이터 버전이 설치되지 않도록 하며 승인이 허용될 때까지의 과정을 방지합니다.

또한 오퍼레이터의 버전을 고정하거나 최신 버전이 아닌 다른 버전으로 업그레이드하려면 사용자 정의 startingCSV를 설정할 수 있습니다.

  • 승인 전략은 OpenShift 웹 콘솔에서 변경하거나 Subscription 편집을 통해 변경할 수 있습니다.
  • 수동 업그레이드를 승인하려면 InstallPlan.spec.approvedtrue로 설정하세요.
  • 각 GitLab Operator는 정의된 일부 GitLab 차트 버전을 지원하며, GitLab Operator의 업그레이드는 GitLab 사용자 정의 자원의 차트 버전 업데이트를 포함해야 합니다.
  • 오퍼레이터와 지정된 차트 버전이 호환되지 않으면 차트에 대한 구성 변경이 차트 버전과 관련된 오류로 실패할 수 있습니다.

참고: OLM은 현재 오퍼레이터 다운그레이드를 지원하지 않습니다.

GitLab Operator 제거

GitLab Operator 및 해당 리소스를 제거하려면 아래 단계를 따르세요.

오퍼레이터를 제거하기 전에 주의할 사항:

  • GitLab 인스턴스가 삭제될 때 오퍼레이터는 Persistent Volume Claims 또는 Secrets를 삭제하지 않습니다.
  • 오퍼레이터를 삭제할 때 오퍼레이터가 설치된 네임스페이스(기본적으로 gitlab-system)는 자동으로 삭제되지 않습니다. 이로 인해 영구 볼륨이 의도치 않게 손실되지 않습니다.

GitLab 인스턴스 제거

kubectl -n gitlab-system delete -f mygitlab.yaml

위 명령은 Persistent Volume Claims를 제외한 GitLab 인스턴스 및 모든 관련 객체를 제거합니다.

GitLab Operator 제거

GL_OPERATOR_VERSION=<설치된_버전> # https://gitlab.com/gitlab-org/cloud-native/gitlab-operator/-/releases
PLATFORM=kubernetes # 또는 "openshift"
kubectl delete -f https://gitlab.com/api/v4/projects/18899486/packages/generic/gitlab-operator/${GL_OPERATOR_VERSION}/gitlab-operator-${PLATFORM}-${GL_OPERATOR_VERSION}.yaml

위 명령은 오퍼레이터의 리소스를 삭제하며, 오퍼레이터의 실행 중인 배포를 포함합니다. 이는 GitLab 인스턴스와 관련된 객체를 삭제하지 않습니다.

GitLab Operator 문제 해결

오퍼레이터의 문제 해결 방법은 troubleshooting.md에서 찾을 수 있습니다.