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

GitLab-Sidekiq 차트 사용

sidekiq 서브 차트는 Sidekiq 워커의 구성 가능한 배포를 제공하며 여러 Deployment간에 대기열을 분리하여 독립적인 확장성과 구성을 명확하게 제공하기 위해 명시 적으로 설계되었습니다.

이 차트에서는 기본 pods: 선언을 제공하지만, 빈 정의를 제공하는 경우 worker가 없게 됩니다.

요구 사항

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

설계 선택 사항

이 차트는 여러 Deployment와 관련된 ConfigMap을 생성합니다. 환경 변수를 사용하는 대신 컨테이너의 command에 추가 인수를 사용하는 대신 ConfigMap 동작을 활용하는 것이 명확하다고 판단되어 결정되었으며, 이 선택은 많은 수의 ConfigMap을 야기하지만 각 pod가 무엇을 수행해야 하는지에 대한 매우 명확한 정의를 제공합니다.

구성

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

설치 명령 줄 옵션

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

차트 구성 예시

리소스

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

Sidekiq pod의 작업 부하는 배포 사이에 크게 다릅니다. 일반적으로 각 Sidekiq 프로세스는 약 1 vCPU 및 2GB의 메모리를 사용한다는 것으로 이해됩니다. 수직 스케일링은 일반적으로이 1:2의 vCPU:Memory 비율을 따르는 것이 좋습니다.

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

이렇게 하면 mailers pod의 응용프로그램 컨테이너에만 SOME_POD_KEY가 설정됩니다. Pod 수준의 extraEnv 설정은 init containers에 추가되지 않습니다.

extraEnvFrom

extraEnvFrom을 사용하면 팟의 모든 컨테이너에서 다른 데이터 소스의 추가 환경 변수를 노출시킬 수 있습니다. 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는 팟에서 이미지를 끌어오기 위해 개인 레지스트리에 인증하는 데 사용됩니다.

개인 레지스트리 및 인증 방법에 대한 자세한 내용은 Kubernetes 문서에서 확인할 수 있습니다.

아래는 pullSecrets의 예시입니다:

image:
  repository: my.sidekiq.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를 사용하면 Sidekiq 팟에 주석을 추가할 수 있습니다.

아래는 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 팟 간에 공유되는 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 차트에서 별도로 배포된 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 기반으로 제공되지 않은 경우에 차트 전역에서 사용될 것입니다.

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

Pod별 설정

pods 선언은 각 worker pod의 모든 속성을 선언할 수 있도록 합니다. 이러한 속성들은 개별 ConfigMaps에 템플릿에 들어가게 되며 각각의 Deployment로 템플릿화됩니다. 이 설정은 모든 큐를 모니터링하는 단일 pod를 포함하도록 기본값으로 설정됩니다. pods 섹션에 변경을 가하면 디폴트 pod 덮어쓰기를 하지 않습니다. 다른 pod 설정에 새로운 pod를 추가하지 않습니다.

| 이름 | 타입 | 기본값 | 설명 | | :— | :–: | :—– | :— |

• lines are cut due to the length. Maybe the description is not properly translated. Can you add newline and put the remaining lines correctly?

Note: The rest of the content is not translated. So include the remaining lines properly and please add newline between the remaining sentences and paragraphs as much as possible.

큐

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 구성의 전체 예제

다음은 별도의 Redis 인스턴스를 사용하는 가져오기 관련 작업을위한 별도의 Sidekiq Pod, 다른 모든 작업을위한 별도의 Redis 인스턴스 및 다른 Pod를 사용하는 내보내기 관련 작업을위한 Sidekiq 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 서비스는 활성화된 경우 프로메테우스 익스포터만을 위해 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 섹션은 일반 HorizontalPodAutoscalers 대신 KEDA ScaledObjects의 설치를 가능하게 합니다. 이 구성은 선택 사항이며 사용자 정의 또는 외부 메트릭에 기반한 오토스케일링이 필요할 때 사용할 수 있습니다.

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

다음 조건이 참이면, CPU 및 메모리 트리거는 자동으로 추가됩니다. 해당 조건은 triggers가 설정되지 않았으며, request.cpu.request 또는 request.memory.request 설정도 0이 아닌 값으로 설정되어 있는 경우입니다.

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

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