• 요구 사항
• 구성
• 설치 명령줄 옵션
• 차트 구성 예시
  • extraEnv
  • extraEnvFrom
  • image.pullSecrets
  • serviceAccount
  • tolerations
  • annotations
  • strategy
  • TLS
    • gitlab-workhorse
    • webservice
• 본 차트의 Community Edition 사용하기
• 전역 설정
• 배포 설정
  • 배포 Ingress
• Ingress 설정
  • 주석
  • proxyBodySize
  • 추가 Ingress
• 리소스
  • 메모리 요청/제한
• 외부 서비스
  • Redis
  • PostgreSQL
  • Gitaly
  • MinIO
  • 레지스트리
• 차트 설정
  • 메트릭
  • GitLab Shell
  • 웹 서버 옵션
• networkpolicy 구성
  • 네트워크 정책 예제
  • 로드밸런서 서비스
• KEDA 구성

GitLab Webservice 차트 사용하기

webservice 서브 차트는 GitLab Rails 웹 서버에게 각 포드당 두 개의 Webservice 워커를 제공합니다. 이것은 단일 포드가 GitLab의 모든 웹 요청을 처리할 수 있는 데에 최소한으로 필요합니다.

이 차트의 포드는 gitlab-workhorse와 webservice 두 개의 컨테이너를 사용합니다. GitLab Workhorse는 8181 포트에서 수신 대상이 항상될 것으로 예정되며, webservice는 GitLab Rails 코드베이스가 들어있으며 8080 포트에서 듣고 있으며 메트릭 수집 목적으로 접근할 수 있습니다. webservice는 직접 일반 트래픽을 받아서는 안 됩니다.

요구 사항

이 차트는 완전한 GitLab 차트의 구성 요소로써 또는 이 차트가 배포된 Kubernetes 클러스터에서 액세스가 가능한 외부 서비스로써 Redis, PostgreSQL, Gitaly 및 Registry 서비스에 의존합니다.

구성

webservice 차트는 다음과 같이 구성됩니다: 전역 설정, 배포 설정, 인그레스 설정, 외부 서비스 및 차트 설정.

설치 명령줄 옵션

아래 표는 helm install 명령에 --set 플래그를 사용하여 제공할 수 있는 모든 차트 구성을 포함하고 있습니다.

(나머지 부분은 생략)

차트 구성 예시

extraEnv

extraEnv를 사용하면 파드의 모든 컨테이너에 추가 환경 변수를 노출시킬 수 있습니다.

아래는 extraEnv의 사용 예시입니다:

extraEnv:
  SOME_KEY: some_value
  SOME_OTHER_KEY: some_other_value

컨테이너가 시작되면 환경 변수가 노출되었는지 확인할 수 있습니다:

env | grep SOME
SOME_KEY=some_value
SOME_OTHER_KEY=some_other_value

extraEnvFrom

extraEnvFrom은 파드의 모든 컨테이너에 다른 데이터 소스에서 추가 환경 변수를 노출할 수 있게 합니다. 이후 변수는 배포당 재정의될 수 있습니다.

아래는 extraEnvFrom의 사용 예시입니다:

extraEnvFrom:
  MY_NODE_NAME:
    fieldRef:
      fieldPath: spec.nodeName
  MY_CPU_REQUEST:
    resourceFieldRef:
      containerName: test-container
      resource: requests.cpu
  SECRET_THING:
    secretKeyRef:
      name: special-secret
      key: special_token
      # optional: boolean
deployments:
  default:
    extraEnvFrom:
      CONFIG_STRING:
        configMapKeyRef:
          name: useful-config
          key: some-string
          # optional: boolean

image.pullSecrets

pullSecrets를 사용하면 파드에서 이미지를 끌어오기 위해 개인 레지스트리에 인증할 수 있습니다.

개인 레지스트리 및 해당 인증 방법에 대한 추가 세부 정보는 쿠버네티스 문서에서 확인할 수 있습니다.

아래는 pullSecrets의 사용 예시입니다:

image:
  repository: my.webservice.repository
  pullPolicy: Always
  pullSecrets:
    - name: my-secret-name
    - name: my-secondary-secret-name

serviceAccount

이 섹션은 ServiceAccount를 생성해야 하는지 여부 및 기본 액세스 토큰을 파드에 마운트해야 하는지 제어합니다.

tolerations

tolerations를 사용하면 오염된 워커 노드에 파드를 예약할 수 있습니다.

아래의 tolerations 사용 예시입니다:

tolerations:
  - key: "node_label"
    operator: "Equal"
    value: "true"
    effect: "NoSchedule"
  - key: "node_label"
    operator: "Equal"
    value: "true"
    effect: "NoExecute"

annotations

annotations를 사용하면 Webservice 파드에 주석을 추가할 수 있습니다. 아래는 예시입니다:

annotations:
  kubernetes.io/example-annotation: annotation-value

strategy

deployment.strategy를 사용하면 배포 업데이트 전략을 변경할 수 있습니다. 배포가 업데이트될 때 파드가 어떻게 다시 생성될지 정의합니다. 제공되지 않으면 클러스터 기본값을 사용합니다. 예를 들어, 롤링 업데이트 시작 시 추가 파드를 생성하고 최대 사용 불가능한 파드를 50%로 변경하고 싶지 않은 경우:

deployment:
  strategy:
    rollingUpdate:
      maxSurge: 0
      maxUnavailable: 50%

또한 업데이트 전략의 유형을 Recreate로 변경할 수도 있지만, 새로운 파드를 예약하기 전에 모든 파드를 종료시키므로 주의가 필요하며, 웹 UI는 새로운 파드가 시작될 때까지 이용할 수 없습니다. 이 경우 rollingUpdate를 정의할 필요가 없고 type만 정의하면 됩니다:

deployment:
  strategy:
    type: Recreate

자세한 내용은 쿠버네티스 문서를 참조하세요.

TLS

Webservice 파드는 두 가지 컨테이너를 실행합니다:

• gitlab-workhorse
• webservice

gitlab-workhorse

Workhorse는 웹 및 메트릭 엔드포인트에 대해 TLS를 지원합니다. 이는 Workhorse와 다른 컴포넌트 간의 통신을 보호하는 것인데, 특히 nginx-ingress, gitlab-shell, 및 gitaly와 같은 컴포넌트를 포함합니다. TLS 인증서에는 Workhorse 서비스 호스트 이름(예: RELEASE-webservice-default.default.svc)이 공통 이름(CN) 또는 서브젝트 대체 이름(SAN)에 포함되어야 합니다.

Webservice의 다중 배포가 존재할 수 있으므로 여러 서비스 이름에 대한 TLS 인증서를 준비해야 합니다. 이는 여러 SAN 또는 와일드카드 인증서로 구현할 수 있습니다.

TLS 인증서가 생성되면 쿠버네티스 TLS 시크릿을 생성하세요. 또한 TLS 인증서의 CA 인증서만을 포함하는 다른 시크릿을 만들어 ca.crt 키로만 포함해야 합니다.

global.workhorse.tls.enabled를 true로 설정하여 gitlab-workhorse 컨테이너에 대한 TLS를 활성화할 수 있습니다. 커스텀 시크릿 이름을 gitlab.webservice.workhorse.tls.secretName과 global.certificates.customCAs로 전달할 수 있습니다.

gitlab.webservice.workhorse.tls.verify가 true일 때(기본값), TLS 인증서를 NGINX가 확인하기 위해 CA 인증서 시크릿 이름을 gitlab.webservice.workhorse.tls.caSecretName에 전달해야 합니다. 이는 자체 서명된 인증서 및 사용자 지정 CA의 경우 필요합니다. 이 시크릿은 NGINX가 Workhorse의 TLS 인증서를 확인하는 데 사용됩니다.

global:
  workhorse:
    tls:
      enabled: true
  certificates:
    customCAs:
      - secret: gitlab-workhorse-ca
gitlab:
  webservice:
    workhorse:
      tls:
        verify: true
        # secretName: gitlab-workhorse-tls
        caSecretName: gitlab-workhorse-ca
      monitoring:
        exporter:
          enabled: true
          tls:
            enabled: true

gitlab-workhorse 컨테이너의 메트릭 엔드포인트에 대한 TLS는 global.workhorse.tls.enabled에서 상속됩니다. 메트릭 엔드포인트에 대한 TLS는 Workhorse에 대한 TLS가 활성화된 경우에만 사용 가능합니다. 메트릭 리스너는 gitlab.webservice.workhorse.tls.secretName에서 지정한 TLS 인증서를 사용합니다.

메트릭 엔드포인트를 위한 TLS 인증서는 포함된 Prometheus Helm 차트를 사용할 때 특히 추가 주제 대체 이름(SANs)에 대한 고려가 필요할 수 있습니다. 자세한 내용은 TLS 활성화 엔드포인트 스크래핑을 위한 Prometheus 구성하기를 참조하세요.

webservice

TLS를 활성화하는 주요 사용 사례는 Prometheus metrics를 스크래핑하기 위한 HTTPS를 통한 암호화를 제공하는 것입니다.

Prometheus가 HTTPS를 사용하여 /metrics/ 엔드포인트를 스크래핑하려면, 인증서의 CommonName 속성이나 SubjectAlternativeName 항목에 대한 추가 구성이 필요합니다. 이러한 요구 사항에 대해 알아보려면 Prometheus를 사용하여 TLS가 활성화된 엔드포인트를 구성하는 방법을 참조하세요.

TLS는 webservice 컨테이너에서 gitlab.webservice.tls.enabled 설정을 통해 활성화할 수 있습니다.

gitlab:
  webservice:
    tls:
      enabled: true
      # secretName: gitlab-webservice-tls

secretName은 Kubernetes TLS 시크릿을 가리켜야 합니다. 예를 들어, 로컬 인증서와 키로 TLS 시크릿을 생성하려면:

kubectl create secret tls <시크릿 이름> --cert=path/to/puma.crt --key=path/to/puma.key

본 차트의 Community Edition 사용하기

기본적으로 Helm 차트는 GitLab의 Enterprise Edition을 사용합니다. 원하는 경우 Community Edition을 대신 사용할 수 있습니다. 더 자세한 내용은 두 버전 간의 차이점을 확인하세요.

Community Edition을 사용하려면 image.repository를 registry.gitlab.com/gitlab-org/build/cng/gitlab-webservice-ce로, workhorse.image를 registry.gitlab.com/gitlab-org/build/cng/gitlab-workhorse-ce로 설정하세요.

전역 설정

차트 사이에서 공통의 전역 설정을 공유합니다. GitLab 및 Registry 호스트명과 같은 공통 구성 옵션에 대한 자세한 내용은 Globals Documentation을 참조하세요.

배포 설정

본 차트는 여러 배포 객체 및 관련 리소스를 생성할 수 있는 기능을 제공합니다. 이 기능을 사용하여 패스 기반 라우팅을 사용하여 GitLab 응용 프로그램에 대한 요청을 여러 세트의 Pod 간에 분산할 수 있습니다.

이 맵의 키(default는 이 예제에서 사용)는 각각의 “이름”입니다. default는 RELEASE-webservice-default로 생성된 배포, 서비스, HorizontalPodAutoscaler, PodDisruptionBudget 및 선택적 Ingress를 가집니다.

제공되지 않은 모든 속성은 gitlab-webservice 차트 기본값을 상속합니다.

deployments:
  default:
    ingress:
      path: # 상속되지 않거나 기본값으로 설정되지 않음. Ingress를 비활성화하려면 비워둡니다.
      pathType: Prefix
      provider: nginx
      annotations:
        # `ingress.anntoations`를 상속합니다.
      proxyConnectTimeout: # `ingress.proxyConnectTimeout`를 상속합니다.
      proxyReadTimeout: # `ingress.proxyReadTimeout`를 상속합니다.
      proxyBodySize: # `ingress.proxyBodySize`를 상속합니다.
    deployment:
      annotations: # 맵
      labels: # 맵
      # `deployment`를 상속합니다.
    pod:
      labels: # .podLabels에 추가 라벨
      annotations:# 맵
        # .Values.annotations에서 상속
    service:
      labels: # .serviceLabels에 추가 라벨
      annotations:# .service.annotations에 추가 주석
        # `service.annotations`를 상속합니다.
    hpa:
      minReplicas: # .minReplicas로 기본값 설정 (상속됨)
      maxReplicas: # .maxReplicas로 기본값 설정 (상속됨)
      metrics: # HPA 메트릭 정의의 선택적 대체 (상속됨)
      # `hpa`를 상속합니다.
    pdb:
      maxUnavailable: # `maxUnavailable`를 상속합니다.
    resources:# `webservice` 컨테이너에 대한 `resources`
      # `resources`를 상속합니다.
    workhorse:# 맵
      # `workhorse`를 상속합니다.
    extraEnv:#
      # `extraEnv`를 상속합니다.
    extraEnvFrom:#
      # `extraEnvFrom`를 상속합니다.
    puma:# 맵
      # `puma`를 상속합니다.
    workerProcesses: # `workerProcesses`를 상속합니다.
    shutdown:
      # `shutdown`를 상속합니다.
    nodeSelector:# 맵
      # `nodeSelector`를 상속합니다.
    tolerations:# 배열
      # `tolerations`를 상속합니다.

배포 Ingress

각 deployments 항목은 차트 전역 Ingress 설정을 상속합니다. 여기 제시된 값은 그 안에 제공된 값을 오버라이드합니다. path 외에는 모든 설정이 동일합니다.

webservice:
  deployments:
    default:
      ingress:
        path: /
   api:
     ingress:
       path: /api

path 속성은 Ingress의 path 속성에 직접 적용되며, 각 서비스로 이동하는 URI 경로를 제어합니다. 위의 예에서 default는 모든 트래픽을 받는 일반 경로를 나타내며, api는 /api 아래의 모든 트래픽을 받습니다.

path를 비워서 특정 배포가 연결된 Ingress 리소스를 가질 수 없도록 설정하여 주어진 배포에서 외부 트래픽을 받지 않도록 할 수 있습니다. 아래 예시에서는 internal-api가 외부 트래픽을 받지 않습니다.

webservice:
  deployments:
    default:
      ingress:
        path: /
   api:
     ingress:
       path: /api
   internal-api:
     ingress:
       path:

Ingress 설정

주석

annotations는 Webservice Ingress에 주석을 설정하는 데 사용됩니다.

우리는 기본적으로 한 개의 주석을 설정합니다: nginx.ingress.kubernetes.io/service-upstream: "true". NGINX에게 직접 서비스 자체를 업스트림으로 연락하도록 지시하여 Webservice pods로의 트래픽을 더 고르게 분배하여 도와줍니다. 자세한 정보는 NGINX 문서를 참조하세요.

이를 재정의하려면 다음을 설정하세요:

gitlab:
  webservice:
    ingress:
      annotations:
        nginx.ingress.kubernetes.io/service-upstream: "false"

proxyBodySize

proxyBodySize는 NGINX 프록시 최대 바디 크기를 설정하는 데 사용됩니다. 기본값보다 큰 Docker 이미지를 허용하는 데 일반적으로 필요합니다. 이는 Linux 패키지 설치에서의 nginx['client_max_body_size'] 구성과 동등합니다. 대안으로 다음 두 매개변수 중 하나로 바디 크기를 설정할 수 있습니다.

• gitlab.webservice.ingress.annotations."nginx\.ingress\.kubernetes\.io/proxy-body-size"
• global.ingress.annotations."nginx\.ingress\.kubernetes\.io/proxy-body-size"

추가 Ingress

extraIngress.enabled=true로 설정하여 추가 Ingress를 배포할 수 있습니다. Ingress는 기본 Ingress와 동일한 설정을 지원하며 -extra 접미사가 있는 이름으로 지정됩니다.

리소스

메모리 요청/제한

각 pod는 workerProcesses와 같은 양의 워커를 생성하며, 각각은 일부 기본 메모리를 사용합니다. 우리는 다음을 권장합니다:

• 워커 당 최소 1.25GB (requests.memory)
• 워커 당 최대 1.5GB와 기본에 추가 1GB (limits.memory)

사용자에 의해 생성된 작업 부하에 필요한 리소스가 의존하며 GitLab 애플리케이션의 변경 또는 업그레이드에 따라 미래에 변경될 수 있음에 유의하세요.

기본값:

workerProcesses: 2
resources:
  requests:
    memory: 2.5G # = 2 * 1.25G
# limits:
#   memory: 4G   # = (2 * 1.5G) + 950M

4개의 워커로 구성된 경우:

workerProcesses: 4
resources:
  requests:
    memory: 5G # = 4 * 1.25G
# limits:
#   memory: 7G   # = (4 * 1.5G) + 950M

외부 서비스

Redis

Redis 문서는 globals 페이지에 통합되었습니다. 최신 Redis 구성 옵션에 대해서는 이 페이지를 참조하세요.

PostgreSQL

PostgreSQL 문서는 globals 페이지에 통합되었습니다. 최신 PostgreSQL 구성 옵션에 대해서는 이 페이지를 참조하세요.

Gitaly

Gitaly는 전역 설정에 따라 구성됩니다. Gitaly 구성 문서를 참조하세요.

MinIO

minio:
  serviceName: "minio-svc"
  port: 9000

레지스트리

registry:
  host: registry.example.com
  port: 443
  api:
    protocol: http
    host: registry.example.com
    serviceName: registry
    port: 5000
  tokenIssuer: gitlab-issuer
  certificate:
    secret: gitlab-registry
    key: registry-auth.key

차트 설정

다음 값은 웹 서비스 팟을 구성하는 데 사용됩니다.

메트릭

메트릭은 metrics.enabled 값을 사용하여 활성화할 수 있으며 GitLab 모니터링 익스포터를 사용하여 메트릭 포트를 노출시킵니다. 팟에는 Prometheus 주석이 부여되거나 metrics.serviceMonitor.enabled가 true로 설정되면 Prometheus Operator ServiceMonitor가 생성됩니다. 또는 메트릭은 /metrics 엔드포인트에서 스크랩되지만 이를 위해 관리자 영역에서 GitLab Prometheus 메트릭을 활성화해야 합니다. GitLab Workhorse 메트릭은 workhorse.metrics.enabled를 통해 노출될 수 있지만 Prometheus 주석을 사용하여 수집할 수 없으므로 workhorse.metrics.serviceMonitor.enabled가 true로 설정되거나 외부 Prometheus 구성이 필요합니다.

GitLab Shell

GitLab Shell은 Webservice와의 통신에 Auth Token을 사용합니다. Auth Token을 GitLab Shell 및 Webservice에 공유하려면 공유 시크릿을 사용하세요.

shell:
  authToken:
    secret: gitlab-shell-secret
    key: secret
  port:

웹 서버 옵션

현재 버전의 차트는 Puma 웹 서버를 지원합니다.

Puma 고유 옵션:

networkpolicy 구성

이 섹션은 NetworkPolicy 를 제어합니다. 이 구성은 선택 사항이며 팟의 Egress 및 Ingress를 특정 엔드포인트로 제한하는 데 사용됩니다.

네트워크 정책 예제

웹 서비스 서비스는 활성화된 경우 Prometheus 익스포터를 통해서만 Ingress 연결을 필요로하며, NGINX Ingress에서 오는 트래픽이 필요하며 일반적으로 여러 곳으로부터 Egress 연결이 필요합니다. 이 예제에서 다음 네트워크 정책을 추가합니다.

• TCP 10.0.0.0/8의 네트워크에서의 모든 Ingress 요청은 메트릭 익스포팅을 위해 포트 8080으로, NGINX Ingress를 위해 허용됩니다.
• 모든 Ingress 요청에 대해 포트 8181로 일반 서비스 작업을 허용합니다.
• UDP 10.0.0.0/8의 네트워크로의 모든 Egress 요청은 DNS를 위해 포트 53으로 허용됩니다.
• TCP 10.0.0.0/8의 네트워크로의 모든 Egress 요청은 PostgreSQL을 위해 포트 5432로 허용됩니다.
• TCP 10.0.0.0/8의 네트워크로의 모든 Egress 요청은 Redis를 위해 포트 6379로 허용됩니다.
• TCP 10.0.0.0/8의 네트워크로의 모든 Egress 요청은 Gitaly를 위해 포트 8075로 허용됩니다.
• 10.0.0.0/8의 로컬 네트워크로의 기타 Egress 요청은 제한됩니다.
• 10.0.0.0/8의 외부 네트워크로의 Egress 요청은 허용됩니다.

제공된 예제는 단순히 일부 요약이므로 완전하지 않을 수 있습니다.

웹 서비스는 외부 객체 저장소의 이미지를 위해 공개 인터넷에 대한 아웃바운드 연결이 필요합니다

networkpolicy:
  enabled: true
  ingress:
    enabled: true
    rules:
      - from:
          - ipBlock:
              cidr: 10.0.0.0/8
        ports:
          - port: 8080
      - from:
        ports:
          - port: 8181
  egress:
    enabled: true
    rules:
      - to:
          - ipBlock:
              cidr: 10.0.0.0/8
        ports:
          - port: 53
            protocol: UDP
      - to:
          - ipBlock:
              cidr: 10.0.0.0/8
        ports:
          - port: 5432
            protocol: TCP
      - to:
          - ipBlock:
              cidr: 10.0.0.0/8
        ports:
          - port: 6379
            protocol: TCP
      - to:
          - ipBlock:
              cidr: 10.0.0.0/8
        ports:
          - port: 8075
            protocol: TCP
      - to:
          - ipBlock:
              cidr: 0.0.0.0/0
              except:
                - 10.0.0.0/8

로드밸런서 서비스

만약 service.type가 LoadBalancer로 설정된 경우, 클라우드 공급업체가 지원하는 경우에는 선택적으로 service.loadBalancerIP를 지정하여 사용자가 지정한 IP로 LoadBalancer를 생성할 수 있습니다.

service.type를 LoadBalancer로 설정하는 경우, 클라우드 공급업체가 지원하는 경우에 service.loadBalancerSourceRanges도 설정해야 합니다. 이를 통해 LoadBalancer에 액세스할 수 있는 CIDR 범위를 제한할 수 있습니다. 현재 이 설정은 metric ports are exposed 문제 때문에 필요합니다.

LoadBalancer 서비스 유형에 대한 추가 정보는 Kubernetes 문서에서 확인할 수 있습니다.

service:
  type: LoadBalancer
  loadBalancerIP: 1.2.3.4
  loadBalancerSourceRanges:
    - 10.0.0.0/8

KEDA 구성

이 keda 섹션은 일반적인 HorizontalPodAutoscalers 대신 KEDA ScaledObjects의 설치를 가능하게 합니다. 이 구성은 선택 사항이며, 사용자 지정 또는 외부 메트릭을 기반으로 자동 스케일링이 필요한 경우에 사용할 수 있습니다.

대부분의 설정은 해당되는 경우 hpa 섹션에 설정된 값으로 기본 설정됩니다.

다음 조건이 충족되는 경우 CPU 및 메모리 트리거가 hpa 섹션에 설정된 CPU 및 메모리 임계값에 따라 자동으로 추가됩니다.

• triggers가 설정되지 않았을 경우.
• 해당하는 request.cpu.request 또는 request.memory.request 설정도 0이 아닌 값으로 설정된 경우.

트리거가 설정되지 않은 경우, ScaledObject가 생성되지 않습니다.

더 자세한 정보는 KEDA 문서를 참조하세요.