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

GitLab Webservice 차트 사용하기

webservice 하위 차트는 GitLab Rails 웹서버에 두 개의 Webservice 워커를 제공하여, 단일 pod가 GitLab의 모든 웹 요청을 처리할 수 있는 최소한의 요구 사항입니다.

이 차트의 pods는 gitlab-workhorse와 webservice 두 개의 컨테이너를 사용합니다. GitLab Workhorse는 8181 포트에서 듣고 있으며, 항상 pod로 들어오는 트래픽의 대상이어야 합니다. webservice는 GitLab Rails codebase를 포함하고 있으며 8080 포트에서 듣고 있으며 메트릭 수집 목적으로 접근할 수 있습니다. webservice는 절대로 직접 일반 트래픽을 수신해서는 안 됩니다.

요구 사항

이 차트는 Redis, PostgreSQL, Gitaly, 등과 같은 서비스들에 의존하며, GitLab 차트 전체의 일부로 제공되거나 이 차트가 배포된 Kubernetes 클러스터에서 접근 가능한 외부 서비스를 제공해야 합니다.

구성

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

설치 명령줄 옵션

다음 표는 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를 사용하여 파드에 이미지를 끌어오기 위해 개인 레지스트리에 인증할 수 있습니다.

개인 레지스트리와 그들의 인증 방법에 대한 추가적인 정보는 Kubernetes 문서에서 찾을 수 있습니다.

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

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

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 파드를 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 인증서에는 Workhorse 서비스 호스트 이름(예: RELEASE-webservice-default.default.svc)이 공통 이름(CN) 또는 대체 이름(SAN)에 포함되어야 합니다.

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

TLS 인증서가 생성되면, Kubernetes 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일 때(기본값임), 자체 서명된 인증서와 사용자 지정 CA를 위해 CA 인증서 시크릿 이름을 gitlab.webservice.workhorse.tls.caSecretName에 전달해야 합니다. 이것은 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 인증서는 포함된 서브젝트 대체 이름(SANs)에 대해 추가적인 고려사항이 필요할 수 있습니다, 특히 포함된 Prometheus Helm 차트를 사용하는 경우. 자세한 정보는 TLS 활성화된 엔드포인트의 Prometheus 스크랩 구성을 참조하세요.

webservice

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

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

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

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 및 레지스트리 호스트명)에 대한 Globals Documentation를 참조하세요.

배포 설정

이 차트에는 여러 배포 객체 및 이에 관련된 리소스를 생성할 수 있는 기능이 있습니다. 이 기능을 통해 경로 기반 라우팅을 사용하여 GitLab 애플리케이션으로의 요청을 여러 세트의 Pods 사이에 분산할 수 있습니다.

이 Map의 키(default는 이 예제에서)는 각각의 “이름”입니다. default는 RELEASE-webservice-default로 생성되는 배포, 서비스, HorizontalPodAutoscaler, PodDisruptionBudget, 그리고 선택적으로 Ingress를 가집니다.

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

deployments:
  default:
    ingress:
      path: # 상속하지 않음 또는 기본값 없음. 비활성화하려면 비워 두세요.
      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 아래의 모든 트래픽을 받습니다.

지정된 배포가 연결된 Ingress 리소스를 가질 수 없도록 비워 두어 트래픽을 받을 수 없도록 설정할 수 있습니다. 아래 예에서 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는 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"

추가 인그레스

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

리소스

메모리 요청/한도

각 파드는 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

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 팟을 구성하는 데 사용됩니다.

메트릭

메트릭은 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을 사용합니다. GitLab Shell과 Webservice간에 공유하는 Secret을 사용하여 토큰을 공유하세요.

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

WebServer 옵션

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

Puma 고유 옵션:

networkpolicy 구성

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

네트워크 정책 예시

웹서비스 서비스는 활성화된 경우 Prometheus 익스포터 및 NGINX Ingress에서만 Ingress 연결을 필요로 하며 일반적으로 다양한 위치로의 Egress 연결이 필요합니다. 이 예시는 다음과 같은 네트워크 정책을 추가합니다.

• TCP 10.0.0.0/8 네트워크에서 메트릭 익스포팅과 NGINX Ingress를 위한 모든 Ingress 요청이 허용됩니다.
• 일반 서비스 운영을 위해 포트 8181로의 모든 Ingress 요청이 허용됩니다.
• UDP 10.0.0.0/8 네트워크로의 모든 DNS에 대한 Egress 요청이 허용됩니다.
• TCP 10.0.0.0/8 네트워크로의 모든 PostgreSQL에 대한 Egress 요청이 허용됩니다.
• TCP 10.0.0.0/8 네트워크로의 모든 Redis에 대한 Egress 요청이 허용됩니다.
• TCP 10.0.0.0/8 네트워크로의 모든 Gitaly에 대한 Egress 요청이 허용됩니다.
• 로컬 네트워크의 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로 설정되어 있다면, 클라우드 프로바이더가 지원하는 경우 사용자가 지정한 IP로 LoadBalancer를 생성할 수 있는 service.loadBalancerIP를 선택적으로 지정할 수 있습니다.

service.type이 LoadBalancer로 설정되어 있는 경우에는 클라우드 프로바이더가 지원하는 경우에 service.loadBalancerSourceRanges를 설정하여 LoadBalancer에 액세스할 수 있는 CIDR 범위를 제한해야 합니다. 현재 이 작업은 메트릭 포트가 노출되는 문제 때문에 필수입니다.

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

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

KEDA 구성

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

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

다음과 같은 경우 CPU 및 메모리 트리거가 자동으로 추가되며, 해당 트리거가 활성화됩니다. 이는 triggers가 설정되지 않은 경우나 해당하는 request.cpu.request 또는 request.memory.request 설정이 0이 아닌 값으로 설정되어 있는 경우에 해당합니다.

• triggers가 설정되어 있지 않은 경우
• 해당하는 request.cpu.request 또는 request.memory.request 설정이 0이 아닌 값으로 설정되어 있는 경우

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

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