• 필수 조건
• 구성
• 설치 명령줄 옵션
• 차트 구성 예제
  • extraEnv
  • extraEnvFrom
  • image.pullSecrets
  • serviceAccount
  • tolerations
  • annotations
  • strategy
  • TLS
    • gitlab-workhorse
    • webservice
• 이 차트의 커뮤니티 에디션 사용하기
• 전역 설정
• 배포 설정
  • 배포 Ingress
• 인그레스 설정
  • 주석
  • proxyBodySize
  • 추가 Ingress
• 리소스
  • 메모리 요청/제한
• 외부 서비스
  • Redis
  • PostgreSQL
  • Gitaly
  • MinIO
  • 레지스트리
• 차트 설정
  • 메트릭스
  • GitLab 셸
  • 웹 서버 옵션
• networkpolicy 구성
  • 예제 네트워크 정책
  • LoadBalancer 서비스
• KEDA 구성

GitLab Webservice 차트 사용하기

webservice 서브 차트는 GitLab Rails 웹 서버에 두 개의 Webservice 작업자를 제공하며, 이는 단일 포드가 GitLab에서 모든 웹 요청을 처리할 수 있게 하기 위한 최소 요구 사항입니다.

이 차트의 포드는 두 개의 컨테이너: gitlab-workhorse 및 webservice를 사용합니다.
GitLab Workhorse는 포트 8181에서 수신하며, 항상 포드로 들어오는 트래픽의 목적지가 되어야 합니다.
webservice는 GitLab Rails 코드베이스를 보유하고 있으며, 8080에서 수신하고 메트릭 수집을 위해 접근할 수 있습니다.
webservice는 일반 트래픽을 직접 수신해서는 안 됩니다.

필수 조건

이 차트는 Redis, PostgreSQL, Gitaly 및 Registry 서비스에 의존하며, 이는 완전한 GitLab 차트의 일부로 제공되거나 이 차트를 배포하는 Kubernetes 클러스터에서 접근 가능한 외부 서비스로 제공됩니다.

구성

webservice 차트는 다음과 같이 구성됩니다: Global settings,
Deployments settings, Ingress settings,
External services, 그리고 Chart settings.

설치 명령줄 옵션

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

차트 구성 예제

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은 다른 데이터 소스에서 모든 컨테이너에 추가 환경 변수를 노출할 수 있도록 합니다.

후속 변수는 각 deployment마다 덮어 쓸 수 있습니다.

다음은 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
      # 선택 사항: boolean
deployments:
  default:
    extraEnvFrom:
      CONFIG_STRING:
        configMapKeyRef:
          name: useful-config
          key: some-string
          # 선택 사항: boolean

image.pullSecrets

pullSecrets는 개인 레지스트리에 인증하여 파드의 이미지를 가져올 수 있도록 합니다.

개인 레지스트리 및 해당 인증 방법에 대한 추가 세부 정보는 Kubernetes 문서를 참조하세요.

다음은 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는 배포 업데이트 전략을 변경할 수 있게 합니다. 이는 배포가 업데이트될 때 파드가 어떻게 재생성될지를 정의합니다. 제공되지 않는 경우 클러스터 기본값이 사용됩니다.

예를 들어, 롤링 업데이트가 시작될 때 추가 파드를 생성하지 않으려면 max unavailable pods를 50%로 변경하세요:

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

업데이트 전략의 유형을 Recreate로 변경할 수도 있지만, 이 경우 모든 파드를 제외한 후 새로운 파드를 예약할 것이므로 주의해야 하며, 새로운 파드가 시작될 때까지 웹 UI를 사용할 수 없습니다. 이 경우 rollingUpdate를 정의할 필요는 없으며, type만 정의하면 됩니다:

deployment:
  strategy:
    type: Recreate

자세한 내용은 Kubernetes 문서를 참조하세요.

TLS

Webservice 포드는 두 개의 컨테이너를 실행합니다:

• gitlab-workhorse
• webservice

gitlab-workhorse

Workhorse는 웹 및 메트릭 엔드포인트 모두에 대해 TLS를 지원합니다. 이는 Workhorse와 다른 구성 요소 간의 통신을 보호하며, 특히 nginx-ingress, gitlab-shell 및 gitaly와의 통신입니다. TLS 인증서는 Common Name (CN) 또는 Subject Alternate Name (SAN)에서 Workhorse 서비스 호스트 이름(예: RELEASE-webservice-default.default.svc)을 포함해야 합니다.

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

TLS 인증서가 생성되면, 이를 위해 Kubernetes TLS 비밀을 생성합니다. 또한 ca.crt 키가 있는 TLS 인증서의 CA 인증서만 포함된 다른 비밀을 생성해야 합니다.

gitlab-workhorse 컨테이너에 대해 TLS를 활성화하려면 global.workhorse.tls.enabled를 true로 설정합니다. 사용자 지정 비밀 이름을 gitlab.webservice.workhorse.tls.secretName 및 global.certificates.customCAs에 맞게 전달할 수 있습니다.

gitlab.webservice.workhorse.tls.verify가 true일 때(기본값으로 해당) 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 인증서는 포함된 주체 대체 이름(SAN)에 대해 추가 고려 사항이 필요할 수 있습니다. 특히 포함된 Prometheus Helm 차트를 사용할 경우 말입니다. 자세한 내용은 TLS가 활성화된 엔드포인트를 스크랩하도록 Prometheus 구성하기를 참조하세요.

webservice

TLS를 활성화하는 주요 사용 사례는 Prometheus 메트릭 스크랩을 위해 HTTPS를 통한 암호화를 제공하는 것입니다.

Prometheus가 HTTPS를 사용하여 /metrics/ 엔드포인트를 스크랩하려면 인증서의 CommonName 속성 또는 SubjectAlternativeName 항목에 대한 추가 구성이 필요합니다. 이에 대한 요구 사항은 TLS가 활성화된 엔드포인트를 스크랩하도록 Prometheus 구성하기를 참조하세요.

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

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

secretName은 Kubernetes TLS 비밀을 가리켜야 합니다. 예를 들어, 로컬 인증서와 키로 TLS 비밀을 생성하는 방법은 다음과 같습니다:

kubectl create secret tls <secret name> --cert=path/to/puma.crt --key=path/to/puma.key

이 차트의 커뮤니티 에디션 사용하기

기본적으로 Helm 차트는 GitLab의 엔터프라이즈 에디션을 사용합니다. 필요한 경우, 커뮤니티 에디션을 대신 사용할 수 있습니다. 두 에디션 간의 차이점에 대해 알아보세요.

커뮤니티 에디션을 사용하려면 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 및 레지스트리 호스트 이름과 같은 공통 구성 옵션에 대해서는 Globals Documentation를 참조하세요.

배포 설정

이 차트는 여러 Deployment 객체와 관련 리소스를 생성할 수 있는 기능을 제공합니다. 이 기능은 GitLab 애플리케이션에 대한 요청을 경로 기반 라우팅을 사용하여 여러 세트의 Pod 사이에 분배할 수 있게 합니다.

이 맵의 키(default 예제) 각각에 대한 “이름”입니다. default는 RELEASE-webservice-default로 생성된 Deployment, Service, 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 아래의 모든 트래픽을 수신합니다.

주어진 Deployment가 관련 Ingress 리소스를 생성하지 않도록 하려면 path를 비워주세요. 아래에서 internal-api는 외부 트래픽을 수신하지 않을 것입니다.

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

인그레스 설정

주석

annotations는 웹서비스 인그레스에 대한 주석을 설정하는 데 사용됩니다.

기본적으로 하나의 주석을 설정합니다: nginx.ingress.kubernetes.io/service-upstream: "true".

이 설정은 NGINX에게 서비스 자체를 업스트림으로 직접 연락하도록 지시하여 웹서비스 포드에 대한 트래픽을 더 고르게 분산하는 데 도움을 줍니다. 자세한 내용은 NGINX 문서를 참조하세요.

이를 재정의하려면 다음을 설정하십시오:

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

proxyBodySize

proxyBodySize는 NGINX 프록시 최대 본문 크기를 설정하는 데 사용됩니다. 이는 일반적으로 기본값보다 큰 Docker 이미지를 허용하기 위해 필요합니다.

이는 리눅스 패키지 설치에서 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 접미사가 추가되며 기본 Ingress와 동일한 설정을 지원합니다.

리소스

메모리 요청/제한

각 팟은 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는 global settings로 구성됩니다. 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

차트 설정

다음 값들은 Webservice Pods 구성을 위해 사용됩니다.

메트릭스

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 셸

GitLab Shell은 Webservice와의 통신에서 Auth Token을 사용합니다. 공유된 비밀을 사용하여 GitLab Shell과 Webservice에 토큰을 공유합니다.

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

웹 서버 옵션

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

Puma 고유 옵션:

networkpolicy 구성

이 섹션은 NetworkPolicy를 제어합니다.

이 구성은 선택 사항이며, Pods의 Egress와 Ingress를 특정 엔드포인트로 제한하는 데 사용됩니다.

예제 네트워크 정책

웹 서비스는 Prometheus exporter가 활성화된 경우에만 Ingress 연결을 필요로 하며, NGINX Ingress에서 오는 트래픽을 수신하고, 일반적으로 다양한 장소로 Egress 연결이 필요합니다. 이 예제는 다음 네트워크 정책을 추가합니다:

• TCP 10.0.0.0/8 포트 8080에서 네트워크의 모든 Ingress 요청이 메트릭 내보내기 및 NGINX Ingress를 위해 허용됩니다.
• 포트 8181로의 모든 Ingress 요청은 일반 서비스 운영을 위해 허용됩니다.
• UDP 10.0.0.0/8 포트 53에서 네트워크로의 모든 Egress 요청이 DNS를 위해 허용됩니다.
• TCP 10.0.0.0/8 포트 5432에서 네트워크로의 모든 Egress 요청이 PostgreSQL을 위해 허용됩니다.
• TCP 10.0.0.0/8 포트 6379에서 네트워크로의 모든 Egress 요청이 Redis를 위해 허용됩니다.
• TCP 10.0.0.0/8 포트 8075에서 네트워크로의 모든 Egress 요청이 Gitaly를 위해 허용됩니다.
• 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

LoadBalancer 서비스

service.type이 LoadBalancer로 설정되면, 클라우드 공급자가 지원하는 경우 사용자 지정 IP를 사용하여 LoadBalancer를 생성하기 위해 선택적으로 service.loadBalancerIP를 지정할 수 있습니다.

service.type이 LoadBalancer로 설정되면, 클라우드 공급자가 지원하는 경우 LoadBalancer에 접근할 수 있는 CIDR 범위를 제한하기 위해 service.loadBalancerSourceRanges도 설정해야 합니다. 이는 현재 메트릭 포트가 노출되는 문제 때문에 필요합니다.

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

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

KEDA 구성

이 keda 섹션은 일반 HorizontalPodAutoscalers 대신 KEDA ScaledObjects의 설치를 가능하게 합니다.

이 구성은 선택 사항이며 사용자 정의 또는 외부 메트릭을 기반으로 자동 확장에서 필요할 때 사용할 수 있습니다.

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

다음이 true인 경우, CPU 및 메모리 임계값에 따라 CPU 및 메모리 트리거가 자동으로 추가됩니다:

• triggers가 설정되지 않음.
• 해당 request.cpu.request 또는 request.memory.request 설정도 0이 아닌 값으로 설정됨.

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

자세한 내용은 KEDA 문서를 참조하세요.