• 전제 조건
  • kubectl
  • Helm
  • PostgreSQL
  • Redis
  • Gitaly
• 다른 옵션 결정
  • 비밀
  • 네트워킹 및 DNS
    • external-dns를 사용하는 동적 IP 주소
    • 정적 IP 주소
    • Istio 프로토콜 선택과의 호환성
  • 지속성
  • TLS 인증서
  • 프로메테우스
    • TLS가 활성화된 엔드포인트를 스크랩하도록 프로메테우스 구성하기
    • 수출업체 엔드포인트
  • 외부 이메일
  • 수신 이메일
  • 서비스 데스크 이메일
  • RBAC
• 다음 단계

GitLab 차트 전제 조건

GitLab을 Kubernetes 클러스터에 배포하기 전에, 다음 전제 조건을 설치하고 설치 시 사용할 옵션을 결정해야 합니다.

전제 조건

kubectl

kubectl을 설치하려면 Kubernetes 문서를 따르세요.

설치하는 버전은 클러스터에서 실행 중인 버전과 한 개의 마이너 릴리스 범위 이내여야 합니다.

Helm

Helm 문서를 따라 Helm v3.10.3 이상을 설치하세요.

PostgreSQL

기본적으로 GitLab 차트에는 bitnami/PostgreSQL에서 제공하는 클러스터 내 PostgreSQL 배포가 포함되어 있습니다.

이 배포는 시험 목적만을 위한 것이며, 프로덕션에서 사용하기에는 권장되지 않습니다.

외부의 프로덕션 준비가 완료된 PostgreSQL 인스턴스를 설정해야 합니다.

권장 기본 버전:

• GitLab 차트 6.0부터 PostgreSQL 13
• GitLab 차트 8.0부터 PostgreSQL 14

GitLab 차트 4.0.0부터 내부적으로 복제가 가능하지만 기본적으로 활성화되어 있지 않습니다.

이러한 기능은 GitLab에 의해 부하 테스트가 이루어지지 않았습니다.

Redis

기본적으로 GitLab 차트에는 bitnami/Redis에서 제공하는 클러스터 내 Redis 배포가 포함되어 있습니다.

이 배포는 시험 목적만을 위한 것이며, 프로덕션에서 사용하기에는 권장되지 않습니다.

외부의 프로덕션 준비가 완료된 Redis 인스턴스를 설정해야 합니다.
사용할 수 있는 모든 구성 설정은 Redis 글로벌 문서를 참조하세요.

GitLab 차트 4.0.0부터 내부적으로 복제가 가능하지만 기본적으로 활성화되어 있지 않습니다.

이러한 기능은 GitLab에 의해 부하 테스트가 이루어지지 않았습니다.

Gitaly

기본적으로 GitLab 차트에는 클러스터 내 Gitaly 배포가 포함되어 있습니다.

프로덕션에서는 Kubernetes에서 Gitaly 실행이 지원되지 않습니다.
Gitaly는 기존 가상 머신에서만 지원됩니다.

외부의 프로덕션 준비가 완료된 Gitaly 인스턴스를 설정해야 합니다.
사용할 수 있는 모든 구성 설정은 Gitaly 글로벌 문서를 참조하세요.

다른 옵션 결정

GitLab을 배포할 때 helm install로 다음 옵션을 사용합니다.

비밀

SSH 키와 같은 비밀을 생성해야 합니다.
기본적으로 이러한 비밀은 배포 중에 자동으로 생성되지만, 이를 지정하려면 비밀 문서를 따를 수 있습니다.

네트워킹 및 DNS

기본적으로 서비스를 노출하기 위해 GitLab은 Ingress 객체로 구성된 이름 기반 가상 서버를 사용합니다.
이 객체들은 type: LoadBalancer의 Kubernetes Service 객체입니다.

gitlab, registry, minio(사용하는 경우)에 대한 기록이 포함된 도메인을 지정해야 합니다.
이를 적절한 IP 주소로 해결하기 위해 차트가 필요합니다.

예를 들어 helm install로 다음을 사용할 수 있습니다:

--set global.hosts.domain=example.com

사용자 도메인 지원이 활성화되면 *.<pages domain> 하위 도메인이 기본적으로 <pages domain>이 되며, pages.<global.hosts.domain>이 됩니다.
도메인은 --set global.pages.externalHttp 또는 --set global.pages.externalHttps에 의해 Pages에 할당된 외부 IP로 해결됩니다.

사용자 도메인을 사용하려면 GitLab Pages는 CNAME 레코드를 사용할 수 있으며, 이는 사용자 도메인을 해당 <namespace>.<pages domain> 도메인으로 포인팅합니다.

external-dns를 사용하는 동적 IP 주소

자동 DNS 등록 서비스인 external-dns를 사용할 계획이라면,

GitLab에 대한 추가 DNS 구성은 필요하지 않습니다. 하지만,

클러스터에 external-dns를 배포해야 합니다. 프로젝트 페이지는

각 지원 공급자에 대한 종합 가이드를 제공합니다.

Pages 도메인(pages.<global.hosts.domain> 기본값)에 대해 작동하지 않습니다.

DNS 항목을 수동으로 구성하여 도메인이 Pages에 전용된

외부 IP 주소를 가리키도록 해야 합니다.

제공된 스크립트를 사용하여 GKE 클러스터를 프로비저닝하면,

external-dns가 클러스터에 자동으로 설치됩니다.

정적 IP 주소

DNS 레코드를 수동으로 구성할 계획이라면, 모든 레코드는

정적 IP 주소를 가리켜야 합니다. 예를 들어, example.com을 선택하고

정적 IP 주소가 10.10.10.10이라면, gitlab.example.com,

registry.example.com 및 minio.example.com (MinIO 사용 시)은

모두 10.10.10.10으로 해석되어야 합니다.

GKE를 사용하고 있다면, 외부 IP 및 DNS 항목 생성에 대해

더 많은 내용을 읽어보세요.

이 프로세스에 대한 추가 도움을 위해 클라우드 또는 DNS 공급자 문서를 참조하세요.

예를 들어, helm install과 함께 다음을 사용하세요:

--set global.hosts.externalIP=10.10.10.10

Istio 프로토콜 선택과의 호환성

서비스 포트 이름은 Istio의 명시적 포트 선택과 호환되는 규칙을 따릅니다.

포트 이름은 <protocol>-<suffix> 형식이며, 예를 들어 tls-gitaly 또는 https-metrics와 같습니다.

Gitaly와 KAS는 gRPC를 사용하지만, 문제 #3822와

문제 #4908에서의 발견으로 인해

tcp 접두사를 사용합니다.

지속성

기본적으로 GitLab 차트는 동적 프로비저너가

기본 영구 볼륨을 생성할 것으로 예상하며 볼륨 청구를 만듭니다.

storageClass를 사용자 정의하거나 수동으로 볼륨을 생성하고 할당하려면,

스토리지 문서를 검토하세요.

객체를 수동으로 편집해야 합니다. 따라서, 추가 스토리지 마이그레이션 작업을 피하기 위해

프로덕션 인스턴스를 배포하기 전에 미리 계획하는 것이 좋습니다.

TLS 인증서

HTTPS로 GitLab을 실행해야 하며, 이는 TLS 인증서가 필요합니다. 기본적으로,

GitLab 차트는 무료 TLS 인증서를 얻기 위해

cert-manager를 설치하고 구성합니다.

자신의 와일드카드 인증서가 있거나, cert-manager가 이미 설치되어 있거나,

TLS 인증서를 얻는 다른 방법이 있는 경우,

TLS 옵션에 대해 더 읽어보세요.

기본 구성의 경우, TLS 인증서를 등록하기 위해 이메일 주소를 지정해야 합니다.

예를 들어, helm install과 함께 다음을 사용하세요:

--set certmanager-issuer.email=me@example.com

프로메테우스

우리는 업스트림 프로메테우스 차트를 사용하며, 사용자 정의된 prometheus.yml 파일을 제외하고는 기본값에서 값을 재정의하지 않습니다. 이 파일은 메트릭 수집을 Kubernetes API와 GitLab 차트에 의해 생성된 객체로 제한합니다. 그러나 기본적으로 alertmanager, nodeExporter, 및 pushgateway는 비활성화되어 있습니다.

prometheus.yml 파일은 프로메테우스에게 gitlab.com/prometheus_scrape 주석이 있는 리소스에서 메트릭을 수집하도록 지시합니다. 또한 gitlab.com/prometheus_path 및 gitlab.com/prometheus_port 주석을 사용하여 메트릭이 발견되는 방식도 구성할 수 있습니다. 이러한 주석은 prometheus.io/{scrape,path,port} 주석에 해당합니다.

프로메테우스를 사용하여 GitLab 애플리케이션을 모니터링하거나 모니터링하려는 경우, 원래의 prometheus.io/* 주석이 적절한 Pods와 서비스에 여전히 추가됩니다. 이는 기존 사용자에 대한 메트릭 수집의 연속성을 보장하고, Kubernetes 클러스터에서 실행 중인 GitLab 애플리케이션 메트릭과 다른 애플리케이션 모두를 캡처하기 위해 기본 프로메테우스 구성을 사용할 수 있는 능력을 제공합니다.

구성 옵션의 포괄적인 목록에 대해서는 업스트림 프로메테우스 차트 문서를 참조하고, 이 항목들이 prometheus의 하위 키가 되도록 합니다. 우리는 이를 요구사항 차트로 사용합니다.

예를 들어, 영구 저장소에 대한 요청은 다음과 같이 제어할 수 있습니다:

prometheus:
  alertmanager:
    enabled: false
    persistentVolume:
      enabled: false
      size: 2Gi
  pushgateway:
    enabled: false
    persistentVolume:
      enabled: false
      size: 2Gi
  server:
    persistentVolume:
      enabled: true
      size: 8Gi

TLS가 활성화된 엔드포인트를 스크랩하도록 프로메테우스 구성하기

프로메테우스는 주어진 익스포터가 TLS를 허용하고 차트 구성이 익스포터의 엔드포인트를 위한 TLS 구성을 노출하는 경우, TLS가 활성화된 엔드포인트에서 메트릭을 스크랩하도록 구성할 수 있습니다.

프로메테우스 스크랩 구성을 위한 TLS 및 Kubernetes 서비스 발견 사용 시 몇 가지 주의 사항이 있습니다:

• pod 및 service endpoints 검색 역할의 경우, 프로메테우스는 스크랩 대상을 설정하기 위해 Pod의 내부 IP 주소를 사용합니다. TLS 인증서를 확인하기 위해 프로메테우스는 메트릭 엔드포인트를 위한 인증서에서 설정된 공통 이름(CN)이나 주제 대체 이름(SAN) 확장에 포함된 이름으로 구성되어야 합니다. 이름은 해석될 필요가 없고, 유효한 DNS 이름이 될 수 있는 임의의 문자열이면 됩니다.
• 익스포터의 엔드포인트에 사용된 인증서가 자체 서명되었거나 프로메테우스 기본 이미지에 존재하지 않는 경우, 프로메테우스 Pod는 익스포터의 엔드포인트에 사용된 인증서에 서명한 인증 기관(CA)의 인증서를 마운트해야 합니다. 프로메테우스는 기본 이미지에서 Debian의 ca-bundle을 사용합니다.
• 프로메테우스는 각 스크랩 구성에 적용되는 tls_config을 사용하여 두 항목 모두 설정하는 것을 지원합니다. 프로메테우스는 Pod 주석 및 다른 발견된 속성을 기반으로 프로메테우스 대상 레이블을 설정하기 위한 강력한 relabel_config 메커니즘을 가지고 있지만, tls_config.server_name 및 tls_config.ca_file을 relabel_config를 사용하여 설정하는 것은 불가능합니다. 자세한 내용은 이 프로메테우스 프로젝트 문제를 참조하세요.

이러한 주의 사항을 감안할 때, 가장 단순한 구성은 모든 익스포터 엔드포인트에 사용될 “이름”과 CA를 공유하는 것입니다:

1. tls_config.server_name에 사용할 단일 임의의 이름을 선택합니다(예: metrics.gitlab).
2. 익스포터 엔드포인트를 TLS로 암호화하는 데 사용되는 각 인증서의 SAN 목록에 해당 이름을 추가합니다.
3. 모든 인증서를 동일한 CA에서 발행합니다:
   • 클러스터 비밀로 CA 인증서를 추가합니다.
   • 프로메테우스 차트의 extraSecretMounts: 구성을 사용하여 해당 비밀을 프로메테우스 서버 컨테이너에 마운트합니다.
   • 프로메테우스 scrape_config의 tls_config.ca_file로 설정합니다.

프로메테우스 TLS 값 예제는 다음과 같이 이 공유 구성을 제공하는 예를 보여줍니다:

1. pod/endpoint scrape_config 역할에 대해 tls_config.server_name을 metrics.gitlab로 설정합니다.
2. metrics.gitlab가 익스포터 엔드포인트에 사용되는 각 인증서의 SAN 목록에 추가되었다고 가정합니다.
3. CA 인증서가 metrics.gitlab.tls-ca라는 비밀에 추가되었고, 이 비밀 키 또한 metrics.gitlab.tls-ca로 동일한 네임스페이스에 생성되었다고 가정합니다(예: kubectl create secret generic --namespace=gitlab metrics.gitlab.tls-ca --from-file=metrics.gitlab.tls-ca=./ca.pem).
4. 해당 metrics.gitlab.tls-ca 비밀을 /etc/ssl/certs/metrics.gitlab.tls-ca에 마운트합니다. extraSecretMounts: 항목을 사용합니다.
5. tls_config.ca_file을 /etc/ssl/certs/metrics.gitlab.tls-ca로 설정합니다.

수출업체 엔드포인트

모든 메트릭 엔드포인트가 GitLab 차트에 포함되어 있지는 않으며 TLS를 지원합니다.

엔드포인트가 TLS 사용 가능하고 TLS 사용이 설정된 경우,

gitlab.com/prometheus_scheme: "https" 주석과 함께

prometheus.io/scheme: "https" 주석도 설정됩니다.

이 주석들은 relabel_config와 함께 사용되어 Prometheus의

__scheme__ 대상 레이블을 설정할 수 있습니다.

Prometheus TLS 값 예시

에는

gitlab.com/prometheus_scheme: "https" 주석을 사용하여 __scheme__를 타겟으로 하는

relabel_config이 포함되어 있습니다.

다음 표는

gitlab.com/prometheus_scrape: true 주석이 적용된 배포(또는 Gitaly 및 Praefect를 사용하는 경우: StatefulSets) 및 서비스 엔드포인트를 나열합니다.

아래 문서 링크에서 구성 요소가 SAN 항목 추가를 언급하는 경우,

Prometheus tls_config.server_name에 사용할 SAN도 추가해야 합니다.

웹 서비스 포드의 경우 노출된 포트는 웹 서비스 컨테이너의 독립 실행형 webrick 수출업체입니다.

워크호스 컨테이너 포트는 스크랩되지 않습니다. 추가 세부정보는

Webservice Metrics 문서를 참조하세요.

외부 이메일

기본적으로 외부 이메일은 비활성화되어 있습니다. 이를 활성화하려면 global.smtp 및 global.email 설정을 사용하여 SMTP 서버의 세부정보를 제공하세요. 이러한 설정에 대한 세부정보는 명령줄 옵션에서 확인할 수 있습니다.

SMTP 서버에 인증이 필요한 경우, 비밀 문서에서 비밀번호 제공 섹션을 읽으세요. --set global.smtp.authentication=""을 사용하여 인증 설정을 비활성화할 수 있습니다.

귀하의 Kubernetes 클러스터가 GKE에 있는 경우, SMTP 포트 25가 차단되어 있다는 점에 유의하세요.

수신 이메일

수신 이메일의 구성은 메일룸 차트에서 문서화되어 있습니다.

서비스 데스크 이메일

수신 이메일의 구성은 메일룸 차트에서 문서화되어 있습니다.

RBAC

GitLab 차트는 기본적으로 RBAC를 생성하고 사용하도록 설정되어 있습니다. 클러스터에 RBAC가 활성화되어 있지 않은 경우, 이러한 설정을 비활성화해야 합니다:

--set certmanager.rbac.create=false
--set nginx-ingress.rbac.createRole=false
--set prometheus.rbac.create=false
--set gitlab-runner.rbac.create=false

다음 단계

클라우드 공급자를 설정하고 클러스터를 생성하세요.