• 요구 사항
• 디자인 선택 사항
• 구성
• 설치 명령줄 옵션
• 차트 구성 예시
  • 리소스
  • extraEnv
  • extraEnvFrom
  • extraVolumes
  • extraVolumeMounts
  • image.pullSecrets
  • tolerations
  • annotations
• 이 차트의 Community Edition 사용
• 외부 서비스
  • Redis
  • PostgreSQL
  • Gitaly
• 메트릭스
• 차트 전역 기본값
• 파드별 설정
  • 대기열
  • negateQueues (폐지됨)
  • pod 항목의 예
  • Sidekiq 구성의 전체 예
• networkpolicy 구성
  • 네트워크 정책의 예
• KEDA 구성

GitLab-Sidekiq 차트 사용하기

서브 차트 sidekiq은 여러 개의 Deployment을 통해 각각의 확장성과 구성을 가진 Sidekiq 워커를 유연하게 배포할 수 있도록 구성할 수 있도록 하고 있습니다.

이 차트는 기본 pods: 선언을 제공하지만, 빈 정의를 제공할 경우 어떤 워커도 갖지 않게 됩니다.

요구 사항

이 차트는 완전한 GitLab 차트의 일부로서 또는 이 차트가 배포되는 Kubernetes 클러스터에서 도달할 수 있는 외부 서비스로서 Redis, PostgreSQL, 그리고 Gitaly에 의존합니다.

디자인 선택 사항

이 차트는 여러 개의 Deployment와 관련된 ConfigMap을 생성합니다. 컨테이너의 command에 대한 추가 인자나 environment 속성을 사용하는 대신 ConfigMap 동작을 이용하도록 선택되었으며, 이는 명령어 길이에 대한 걱정을 피하기 위함입니다.

구성

sidekiq 차트는 세 부분으로 구성됩니다: 차트 전역의 외부 서비스, 차트 전역의 기본값들, 그리고 각 pod의 정의.

설치 명령줄 옵션

다음 표에 helm install 명령을 통해 --set 플래그를 사용하여 제공할 수 있는 가능한 차트 구성을 모두 포함하고 있습니다:

차트 구성 예시

리소스

resources를 사용하여 Sidekiq pod가 소비할 수 있는 리소스(메모리 및 CPU)의 최솟값과 최댓값을 구성할 수 있습니다.

Sidekiq pod 워크로드는 배포마다 크게 다릅니다. 일반적으로 각 Sidekiq 프로세스는 약 1 vCPU 및 2GB의 메모리를 소비한다고 이해됩니다. 수직 스케일링은 일반적으로 이 1:2 비율의 vCPU:메모리에 맞게 구성되어야 합니다.

아래는 resources를 사용한 예시입니다:

resources:
  limits:
    memory: 5G
  requests:
    memory: 2G
    cpu: 900m

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

특정 pod에 대해 extraEnv를 설정할 수도 있습니다:

extraEnv:
  SOME_KEY: some_value
  SOME_OTHER_KEY: some_other_value
pods:
  - name: mailers
    queues: mailers
    extraEnv:
      SOME_POD_KEY: some_pod_value
  - name: catchall
    negateQueues: mailers

이렇게 하면 mailers pod의 애플리케이션 컨테이너에만 SOME_POD_KEY가 설정됩니다. Pod 수준의 ‘extraEnv’ 설정은 init containers에 추가되지 않습니다.

extraEnvFrom

extraEnvFrom을 사용하여 모든 pod의 모든 컨테이너에서 다른 데이터 소스에서 추가 환경 변수를 노출할 수 있습니다. 이후에 Sidekiq pod별로 변수를 재정의할 수 있습니다.

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
pods:
  - name: immediate
    extraEnvFrom:
      CONFIG_STRING:
        configMapKeyRef:
          name: useful-config
          key: some-string
          # optional: boolean

extraVolumes

extraVolumes를 사용하여 차트 전역으로 추가 볼륨을 구성할 수 있습니다.

extraVolumes를 사용한 예시는 다음과 같습니다:

extraVolumes: |
  - name: example-volume
    persistentVolumeClaim:
      claimName: example-pvc

extraVolumeMounts

extraVolumeMounts를 사용하여 차트 전역의 모든 컨테이너에 대해 추가 볼륨 마운트를 구성할 수 있습니다.

extraVolumeMounts를 사용한 예시는 다음과 같습니다:

extraVolumeMounts: |
  - name: example-volume-mount
    mountPath: /etc/example

image.pullSecrets

pullSecrets를 사용하여 pod에서 이미지를 가져오기 위해 개인 레지스트리에 인증할 수 있습니다.

개인 레지스트리 및 해당 인증 방법에 대한 추가 자세한 내용은 Kubernetes 문서에서 찾을 수 있습니다.

pullSecrets를 사용한 예시는 다음과 같습니다:

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

tolerations

tolerations을 사용하여 tainted worker 노드에 pod를 예약할 수 있습니다.

tolerations을 사용한 예시는 다음과 같습니다:

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

annotations

annotations을 사용하여 Sidekiq pod에 주석을 추가할 수 있습니다.

annotations을 사용한 예시는 다음과 같습니다:

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

이 차트의 Community Edition 사용

기본적으로 Helm 차트는 GitLab의 Enterprise Edition을 사용합니다. 원하는 경우 Community Edition을 대신 사용할 수 있습니다. 두 버전 간의 차이점에 대해 자세히 알아보세요.

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

외부 서비스

이 차트는 Webservice 차트와 동일한 Redis, PostgreSQL 및 Gitaly 인스턴스에 연결해야 합니다. 외부 서비스의 값은 모든 Sidekiq pods 간에 공유되는 ConfigMap에 채워집니다.

Redis

redis:
  host: rank-racoon-redis
  port: 6379
  sentinels:
    - host: sentinel1.example.com
      port: 26379
  password:
    secret: gitlab-redis
    key: redis-password

참고: 현재 Redis Sentinel 지원은 별도로 GitLab 차트에서 배포된 Sentinel을 지원합니다. 결과적으로, GitLab 차트를 사용하여 배포하는 Redis가 비활성화되어야 합니다. Redis 비밀번호를 포함하는 시크릿은 GitLab 차트를 배포하기 전에 수동으로 생성되어야 합니다.

PostgreSQL

psql:
  host: rank-racoon-psql
  serviceName: pgbouncer
  port: 5432
  database: gitlabhq_production
  username: gitlab
  preparedStatements: false
  password:
    secret: gitlab-postgres
    key: psql-password

Gitaly

gitaly:
  internal:
    names:
      - default
      - default2
  external:
    - name: node1
      hostname: node1.example.com
      port: 8079
  authToken:
    secret: gitaly-secret
    key: token

메트릭스

기본적으로, 각 pod에 대해 Prometheus 메트릭스 익스포터가 활성화됩니다. 메트릭스는 GitLab Prometheus metrics이 관리자 영역에서 활성화된 경우에만 사용할 수 있습니다. 익스포터는 포트 3807에서 /metrics 엔드포인트를 노출합니다. 메트릭스가 활성화된 경우, 각 pod에 주석이 추가되어 Prometheus 서버가 노출된 메트릭스를 찾고 스크래핑할 수 있도록합니다.

차트 전역 기본값

다음 값은 각 pod별로 제공되지 않을 경우 차트 전체에서 사용됩니다.

참고: Linux 패키지 문서에서 Sidekiq memory killer의 자세한 설명을 확인할 수 있습니다.

파드별 설정

pods 선언은 워커 파드의 모든 속성을 선언하는 데 사용됩니다. 이러한 내용은 Deployment에 템플릿화되며, 개별 ConfigMap은 해당 Sidekiq 인스턴스에 대해 생성됩니다.

참고: 설정은 모든 대기열을 모니터링하도록 설정된 단일 파드를 기본값으로 사용합니다. 파드 섹션을 수정하면 기본 파드가 아닌 다른 파드 구성으로 덮어씁니다. 이로써 새 파드가 추가되는 것이 아니라 기본 파드가 덮어쓰입니다.

대기열

queues 값은 처리해야 하는 큐의 쉼표로 구분된 목록을 포함하는 문자열입니다. 기본적으로 설정되어 있지 않으며, 이는 모든 대기열이 처리됨을 의미합니다.

문자열에는 공백을 포함해서는 안 됩니다. merge,post_receive,process_commit는 작동하지만 merge, post_receive, process_commit은 작동하지 않습니다.

작업이 추가되지만 적어도 하나의 pod 항목으로 나타나지 않는 대기열은 처리되지 않을 것입니다. 모든 큐의 완전한 목록은 GitLab 소스의 다음 파일에서 확인할 수 있습니다.

1. app/workers/all_queues.yml
2. ee/app/workers/all_queues.yml

gitlab.sidekiq.pods[].queues를 구성하는 것 외에도 global.appConfig.sidekiq.routingRules를 구성해야 합니다. 자세한 정보는 Sidekiq 라우팅 규칙 설정을 참조하십시오.

negateQueues (폐지됨)

폐지에 대한 자세한 정보는 폐지된 Negate 설정을 참조하십시오.

negateQueues는 queues와 동일한 형식입니다. 그러나 처리하는 대신 무시할 큐를 나타냅니다.

문자열에는 공백을 포함해서는 안 됩니다. merge,post_receive,process_commit는 작동하지만 merge, post_receive, process_commit은 작동하지 않습니다.

이 기능은 중요한 대기열을 처리하는 pod와 다른 대기열을 처리하는 다른 pod가 있는 경우 유용합니다. 동일한 큐 목록을 사용하되 하나는 queues에 있고 다른 하나는 negateQueues에 있는 경우입니다.

참고: negateQueues는 queues와 함께 제공되어서는 안 되며, 그렇게 할 경우 영향을 미치지 않습니다.

pod 항목의 예

pods:
  - name: immediate
    concurrency: 10
    minReplicas: 2  # 상속된 값의 기본값
    maxReplicas: 10 # 상속된 값의 기본값
    maxUnavailable: 5 # 상속된 값의 기본값
    queues: merge,post_receive,process_commit
    extraVolumeMounts: |
      - name: example-volume-mount
        mountPath: /etc/example
    extraVolumes: |
      - name: example-volume
        persistentVolumeClaim:
          claimName: example-pvc
    resources:
      limits:
        cpu: 800m
        memory: 2Gi
    hpa:
      cpu:
        targetType: Value
        targetAverageValue: 350m

Sidekiq 구성의 전체 예

다음은 가져오기 관련 작업을 위한 별도의 Sidekiq pod와 기타 모든 작업을 위한 다른 pod를 사용하는 Sidekiq 구성의 전체 예입니다.

...
global:
  appConfig:
    sidekiq:
      routingRules:
      - ["feature_category=importers", "import"]
      - ["*", "default"]
...
gitlab:
  sidekiq:
    pods:
    - name: import
      queues: import
    - name: default
...

networkpolicy 구성

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

네트워크 정책의 예

Sidekiq 서비스는 활성화된 경우 Prometheus exporter를 위해 Ingress 연결만 필요로하며 일반적으로 다양한 마계지로의 Egress 연결이 필요합니다. 이 예제는 다음과 같은 네트워크 정책을 추가합니다.

• TCP 10.0.0.0/8 포트 3807에서 네트워크로부터의 모든 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를 위해 허용됩니다.
• 로컬 네트워크인 10.0.0.0/8로의 다른 Egress 요청은 제한됩니다.
• 10.0.0.0/8 외부의 Egress 요청은 허용됩니다.

제공된 예제는 단순한 예제일 뿐이며 완전하지 않을 수 있음에 유의하세요.

메모: Sidekiq 서비스는 외부 객체 저장소의 이미지를 위해 공개 인터넷과의 외부 연결성이 필요합니다.

networkpolicy:
  enabled: true
  ingress:
    enabled: true
    rules:
      - from:
        - ipBlock:
            cidr: 10.0.0.0/8
        ports:
        - port: 3807
  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: 0.0.0.0/0
            except:
            - 10.0.0.0/8

KEDA 구성

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

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

다음이 모두 참인 경우 CPU 및 메모리 트리거가 자동으로 추가됩니다. 이는 triggers가 설정되지 않았거나, 해당하는 request.cpu.request 또는 request.memory.request 설정이 0이 아닌 값으로 설정된 경우입니다.

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

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

이러한 설정에 대해 더 자세히 알아보려면 KEDA 문서를 참조하십시오.