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

GitLab-Sidekiq 차트 사용하기

sidekiq 서브 차트는 Sidekiq 워커를 유연하게 배포하기 위해 설계된 것으로, 여러 Deployment 간에 큐를 분리하고 개별 확장성과 구성을 제공하는 것을 명확히하도록 명시적으로 구현되었습니다.

요구 사항

이 차트는 완전한 GitLab 차트의 일부로서 또는 이 차트가 배포된 Kubernetes 클러스터에서 도달 가능한 외부 서비스로서 Redis, PostgreSQL 및 Gitaly 서비스에 의존합니다.

설계 선택 사항

이 차트는 여러 Deployment 및 관련 ConfigMap을 생성합니다. 커맨드의 길이에 대한 우려를 피하기 위해 환경 특성이나 컨테이너의 추가적인 인자를 사용하는 대신 ConfigMap 동작을 사용하는 것이 더 명확하다고 결정되었습니다. 이 선택은 많은 수의 ConfigMap을 유발하지만, 각 Pod가 무엇을 수행해야 하는지 매우 명확하게 정의합니다.

구성

sidekiq 차트는 세 가지 부분으로 구성됩니다: 차트 전체적인 외부 서비스, 차트 전체적인 기본값, 각 Pod의 정의.

설치 명령줄 옵션

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

| 매개변수 | 기본값 | 설명 | | —————————————— | ———————————————————— | ———————————————————————————————————————————————————————————————— | | annotations | | Pod annotations | | podLabels | | 부가적인 Pod 라벨. 선택기에 사용되지 않음. | 모든 이에 해당하는 데이터들을 제외하고 번역될 것입니다.

차트 구성 예시

리소스

resources를 사용하면 Sidekiq pod가 사용할 수있는 리소스 (메모리 및 CPU)의 최소 및 최대량을 구성할 수 있습니다.

Sidekiq pod 작업 부하는 배포간에 크게 다릅니다. 일반적으로 각 Sidekiq 프로세스가 약 1 vCPU 및 2GB의 메모리를 사용한다는 것으로 이해됩니다. 대부분의 경우 수직 스케일링은 vCPU:메모리의 1:2 비율에 일반적으로 정렬해야합니다.

아래는 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

이렇게하면 SOME_POD_KEY가 mailers pod의 응용 프로그램 컨테이너에만 설정됩니다. 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를 사용하면 차트 전체의 모든 컨테이너에 대해 추가 volumeMounts를 구성할 수 있습니다.

아래는 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로 설정하십시오.

외부 서비스

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

Redis

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

참고 : 현재 Redis Sentinel 지원은 별도로 배포된 Sentinels 만 지원합니다. 결과적으로 GitLab 차트를 통한 Redis 배포는 redis.install=false로 매뉴얼으로 비활성화해야합니다. 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별로 제공되지 않은 경우 차트 전반에 걸쳐 사용될 기본값은 다음과 같습니다.

pod별 설정

pods 선언은 각 워커 pod의 모든 속성을 선언하기 위한 것으로, 이들은 개별 ConfigMap을 갖는 Deployment로 템플릿화될 것입니다.

대기열

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 라우팅 규칙 설정을 참조하세요.

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, 별도의 Redis 인스턴스를 사용하는 내보내기 작업에 대한 Sidekiq pod, 그리고 나머지 모든 작업에 대한 다른 pod를 사용하여 Sidekiq 구성의 전체 예시입니다.

...
global:
  appConfig:
    sidekiq:
      routingRules:
      - ["feature_category=importers", "import"]
      - ["feature_category=exporters", "export", "queues_shard_extra_shard"]
      - ["*", "default"]
  redis:
    redisYmlOverride:
      queues_shard_extra_shard: ...
...
gitlab:
  sidekiq:
    pods:
    - name: import
      queues: import
    - name: export
      queues: export
      extraEnv:
        SIDEKIQ_SHARD_NAME: queues_shard_extra_shard # global.redis.redisYmlOverride의 키와 일치하도록 설정
    - name: default
...

networkpolicy 구성

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

네트워크 정책 예시

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

• TCP 10.0.0.0/8의 네트워크에서의 모든 Ingress 요청은 메트릭 익스포팅을 위해 허용됩니다.
• UDP 10.0.0.0/8의 네트워크로의 모든 Egress 요청은 DNS를 위해 허용됩니다.
• TCP 10.0.0.0/8의 네트워크로의 모든 Egress 요청은 PostgreSQL을 위해 허용됩니다.
• TCP 10.0.0.0/8의 네트워크로의 모든 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/8
        ports:
        - port: 5432
          protocol: TCP
      - to:
        - ipBlock:
            cidr: 10.0.0/8
        ports:
        - port: 6379
          protocol: TCP
      - to:
        - ipBlock:
            cidr: 0.0.0.0/0
            except:
            - 10.0.0.0/8

KEDA 구성

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

대부분의 설정은 적용 가능한 경우 hpa 섹션에 설정된 값의 기본값과 동일합니다.

다음 사항이 사실인 경우, CPU 및 메모리 트리거가 자동으로 추가됩니다:

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

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

이러한 설정에 대한 자세한 내용은 KEDA 설명서를 참조하세요.