• 전제 조건
  • 클러스터
  • 인그레스 컨트롤러
  • TLS 인증서
  • 메트릭
  • 도메인 네임 서비스 구성
• GitLab Operator 설치
• GitLab 설치
• 권장되는 다음 단계
  • OpenShift
• GitLab Operator 제거
  • GitLab 인스턴스 제거
  • GitLab 오퍼레이터 제거
• GitLab 오퍼레이터 문제 해결

설치

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

OpenShift을 사용하는 경우, 설치는 일반적으로 Operator Lifecycle Manager (OLM)에 의해 처리됩니다. OLM을 사용한 설치는 실험적으로 간주됩니다. GitLab은 OLM을 사용하여 배포된 인스턴스와 관련된 어떠한 문제도 지원하지 않습니다. OLM에 대한 잠재적인 문제에 대한 자세한 내용은 이슈 241을 참조하세요.

전제 조건

1. Kubernetes 또는 OpenShift 클러스터를 생성하거나 기존 클러스터를 사용합니다(#cluster).
2. 전제 서비스 및 소프트웨어를 설치합니다
   • 인그레스 컨트롤러
   • cert-manager
   • 메트릭 서버
3. 도메인 이름 서비스 구성

클러스터

GitLab Operator는 초기 릴리스 후 3개월 이후에 새로운 마이너 Kubernetes 및 OpenShift 버전을 지원하도록 목표로 합니다. 우리는 위에 나열된 버전보다 최신인 릴리스와의 호환성 문제를 이슈 트래커에서 환영합니다.

일부 GitLab 기능은 더 이상 사용되지 않는 버전 및 위의 버전보다 오래된 버전에서는 작동하지 않을 수 있습니다.

쿠버네티스용 에이전트 및 GitLab Charts와 같은 일부 컴포넌트의 경우 GitLab은 다른 클러스터 버전을 지원할 수 있습니다.

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

멀티-아키텍처 클러스터를 사용 중이라면 Operator 배포에 대한 노드 선택기를 추가하는 것이 좋을 수 있습니다. 최신 플랫폼을 사용하며 amd64 노드에만 Operator를 스케줄링하도록 Deployment를 패치합니다.

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

Operator Helm 차트를 사용 중이라면 values.yaml에 노드 선택기를 추가할 수 있습니다.

nodeSelector:
  kubernetes.io/arch: amd64

이렇게 하면 현재 테스트하는 플랫폼인 amd64 노드에서 Operator가 실행됨이 보장됩니다.

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

인그레스 컨트롤러

양방향 커뮤니케이션 및 외부 액세스를 제공하기 위해 인그레스 컨트롤러가 필요합니다.

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

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

TLS 인증서

operator의 Kubernetes webhook을 위한 인증서를 생성하기 위해 cert-manager가 사용됩니다. GitLab 인증서에 대해서도 cert-manager를 사용해야 합니다.

인증서 매니저의 중요 버전은 cert-manager 1.6.1을 대상으로 합니다.

메트릭

도메인 네임 서비스 구성

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

GitLab 컴포넌트에 도메인을 연결하는 자세한 내용은 저희의 네트워킹 및 DNS 설명서를 참조하세요. 이 섹션에서 언급된 구성은 GitLab 사용자 정의 자원(CR)을 정의할 때 사용합니다.

OpenShift에서는 Ingress를 설정하는 데 추가 고려 사항이 필요합니다. 자세한 내용은 OpenShift Ingress에 대한 노트를 확인하세요.

GitLab Operator 설치

먼저 설치 방법을 선택하세요.

kubectl create namespace gitlab-system

kubectl apply -f gitlab-operator-<platform>.yaml

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

helm install gitlab-operator gitlab/gitlab-operator \
  --create-namespace \
  --namespace gitlab-system

오퍼레이터 배포 상태를 확인하여 설치를 확인하세요.

kubectl -n gitlab-system get deployment gitlab-controller-manager

GitLab 설치

1. 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/<OPERATOR_VERSION>/CHART_VERSIONS
       values:
         global:
           hosts:
             domain: example.com # 여기에 실제 도메인을 사용하세요
           ingress:
             configureCertmanager: true
         certmanager-issuer:
           email: youremail@example.com # 여기에 실제 이메일 주소를 사용하세요
   

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

2. 새로운 GitLab CR을 사용하여 GitLab 인스턴스를 배포하세요.

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

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

   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 차트 문서를 확인하세요.

권장되는 다음 단계

설치를 완료한 후 권장되는 다음 단계를 고려해보세요. 인증 옵션 및 가입 제한을 포함합니다.

OpenShift

OpenShift를 사용 중이라면 GitLab Operator의 승인 전략을 자동 (기본값)에서 매뉴얼으로 변경하세요. 이렇게 하면 승인이 부여될 때까지 OpenShift가 새 오퍼레이터 버전을 설치하는 것을 방지할 수 있습니다.

사용자 지정 startingCSV를 설정하여 오퍼레이터 버전을 고정하거나 최신 버전 이외의 버전으로 업그레이드할 수도 있습니다.

• 승인 전략은 OpenShift 웹 콘솔에서 변경하거나 Subscription 편집을 통해 변경할 수 있습니다.
• InstallPlan의 .spec.approved를 true로 설정하여 매뉴얼 업그레이드를 승인할 수 있습니다.
• 각 GitLab Operator는 정의된 일부 GitLab 차트 버전을 지원합니다. GitLab Operator의 업그레이드는 GitLab 사용자 정의 자원의 차트 버전도 업데이트해야 합니다.
• 오퍼레이터 및 지정된 차트 버전이 호환되지 않으면 차트의 구성 변경이 실패할 수 있으며, 차트 버전에 관한 오류가 발생할 수 있습니다.

GitLab Operator 제거

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

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

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

GitLab 인스턴스 제거

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

이 명령은 GitLab 인스턴스와 연관된 모든 객체를 제거하지만, 위에서 언급한 Persistent Volume Claims는 제외됩니다).

GitLab 오퍼레이터 제거

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 오퍼레이터 문제 해결

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