• 사전 요구 사항
  • 클러스터
  • 인그레스 컨트롤러
  • TLS 인증서
  • 메트릭
  • 도메인 이름 서비스 구성
• GitLab Operator 설치
• GitLab 설치
• 권장 다음 단계
  • OpenShift
• GitLab Operator 제거
  • GitLab 인스턴스 제거
  • GitLab Operator 제거
• GitLab Operator 문제 해결

설치

참고:
GitLab Operator는 알려진 제한 사항이 있으며, 생산 환경에서 특정 시나리오에만 적합합니다.

경고:
GitLab 사용자 정의 리소스_의 기본값은 생산 환경에서 사용하도록 설계되지 않았습니다.
이 값으로 GitLab Operator는 _모든 서비스가 영구 데이터를 포함하여
Kubernetes 클러스터에 배포되는 GitLab 인스턴스를 생성합니다. 이는 생산 환경 작업에 적합하지 않습니다.
생산 배포를 위해서는 클라우드 네이티브 하이브리드 참조 아키텍처를 따라야 합니다.
GitLab은 Kubernetes 클러스터 내에 배포된 PostgreSQL, Redis, Gitaly, Praefect 또는 MinIO와 관련된 문제를 지원하지 않습니다.

이 문서에서는 Kubernetes 또는 OpenShift 클러스터에서 매니페스트를 사용하여 GitLab Operator를 배포하는 방법을 설명합니다.

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

사전 요구 사항

1. 기존 Kubernetes 또는 OpenShift 클러스터 생성 또는 사용
2. 필수 서비스 및 소프트웨어 설치
   • Ingress 컨트롤러
   • cert-manager
   • Metrics 서버
3. 도메인 이름 서비스 구성

클러스터

GitLab Operator는 새 마이너 Kubernetes 및 OpenShift 버전을 초기 릴리스 후 3개월 이내에 지원하는 것을 목표로 합니다.
우리는 이슈 트래커에서 상기 목록에 없는 최신 릴리스에 대한 호환성 문제를 환영합니다.

일부 GitLab 기능은 더 이상 지원되지 않는 버전 및 위에 나열된 버전 이전의 버전에서는 제대로 작동하지 않을 수 있습니다.

agent for Kubernetes 및 GitLab Charts와 같은 일부 구성 요소에 대해 GitLab은 다른 클러스터 버전을 지원할 수 있습니다.

16.7부터 Operator는 x86-64 및 arm64용으로 빌드됩니다.
arm64 이미지는 CI에서 테스트되지 않으며 생산 환경 사용을 권장하지 않습니다.

멀티 아키텍처 클러스터에 있는 경우, Operator 배포에 대해 kubernetes.io/arch 레이블에 대한 노드 선택기를 추가하는 것이 좋습니다.

Deployment를 x86-64/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 노드에서 실행됩니다.

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

인그레스 컨트롤러

인그레스 컨트롤러는 애플리케이션에 대한 외부 액세스를 제공하고 구성 요소 간의 보안 통신을 위한 필수 요소입니다.

GitLab Operator는 기본적으로 GitLab Helm Chart에서 포크한 NGINX 차트를 배포합니다.

외부 인그레스 컨트롤러를 사용하려면 Kubernetes 커뮤니티의 NGINX Ingress를 사용하여 인그레스 컨트롤러를 배포하십시오. 플랫폼 및 선호하는 도구에 따라 링크에서 관련 지침을 따르십시오. 나중에 사용할 인그레스 클래스 값을 기억하십시오(일반적으로 기본 값은 nginx입니다).

GitLab CR을 구성할 때 nginx-ingress.enabled=false를 설정하여 GitLab Helm Chart에서 NGINX 개체를 비활성화해야 합니다.

TLS 인증서

운영자의 Kubernetes 웹훅을 위해 인증서를 생성하기 위해 cert-manager를 사용합니다. GitLab 인증서에도 cert-manager를 사용해야 합니다.

운영자가 Kubernetes 웹훅을 위한 인증서가 필요하므로 GitLab Chart와 함께 번들된 cert-manager를 사용할 수 없습니다. 대신, 운영자를 설치하기 전에 cert-manager를 설치하십시오.

플랫폼 및 도구에 맞는 지원되는 cert-manager 릴리스를 설치하기 위한 문서를 참조하십시오.

메트릭

도메인 이름 서비스 구성

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

도메인을 GitLab 구성 요소에 연결하는 방법에 대한 자세한 내용은 네트워킹 및 DNS 문서를 참조하십시오. 이 섹션에서 언급된 구성을 사용하여 GitLab 커스텀 리소스(CR)를 정의합니다.

OpenShift의 인그레스는 추가 고려가 필요합니다. 자세한 내용은 OpenShift 인그레스에 대한 추가 정보를 참조하십시오.

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

Operator 배포 상태를 확인하여 설치를 확인합니다:

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 Chart 문서를 참조하세요.

2. 새 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이 조정되면(상태가 Running일 때) 브라우저에서 GitLab에 접속할 수 있습니다: https://gitlab.example.com.

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

권장 다음 단계

설치를 완료한 후, 권장 다음 단계를 고려하세요, 인증 옵션과 회원 가입 제한 사항을 포함하여.

OpenShift

OpenShift를 사용하는 경우 GitLab Operator에 대한 승인 전략을 자동(기본값)에서 수동으로 변경합니다. 이렇게 하면 OpenShift가 새 Operator 버전을 설치하지 않도록 방지합니다 승인이 주어질 때까지.

또한 커스텀 startingCSV를 설정하여 Operator의 버전을 고정하거나 최신 버전이 아닌 버전으로 업그레이드할 수 있습니다.

• 승인 전략은 OpenShift 웹 콘솔에서 변경하거나 구독 편집으로 변경할 수 있습니다.
• 수동 업그레이드를 승인하려면 InstallPlan의 .spec.approved를 true로 설정합니다.
• 각 GitLab Operator는 정의된 GitLab 차트 버전의 하위 집합을 지원합니다: GitLab Operator로의 업그레이드는 GitLab 사용자 정의 리소스에서 차트 버전을 업데이트해야 합니다.
• Operator와 지정된 차트 버전이 호환되지 않으면, 차트에 대한 구성 변경이 차트 버전 오류와 함께 실패할 수 있습니다.

참고: OLM은 현재 Operator를 다운그레이드하는 것을 지원하지 않습니다.

GitLab Operator 제거

GitLab Operator 및 관련 리소스를 제거하기 위해 아래 단계를 따르십시오.

운영자를 제거하기 전에 유의할 사항:

• GitLab 인스턴스가 삭제될 때 운영자가 지속적 볼륨 청구(Persistent Volume Claims) 또는 비밀(Secrets)을 삭제하지 않습니다.
• 운영자를 삭제할 때 기본적으로 설치된 네임스페이스(gitlab-system)는 자동으로 삭제되지 않습니다. 이는 지속적 볼륨이 의도치 않게 손실되지 않도록 보장합니다.

GitLab 인스턴스 제거

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

이 명령어는 GitLab 인스턴스와 위에서 언급한 지속적 볼륨 청구를 제외한 모든 관련 객체를 제거합니다.

GitLab Operator 제거

GL_OPERATOR_VERSION=<your_installed_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

이 명령어는 운영자의 리소스를 삭제하며, 여기에는 운영자의 실행 중인 배포(Deployment)가 포함됩니다. 이는 GitLab 인스턴스와 관련된 객체는 삭제하지 않습니다.

GitLab Operator 문제 해결

운영자 문제 해결에 대한 내용은 troubleshooting.md에서 확인할 수 있습니다.