GitLab-Spamcheck 차트 사용하기

Tier: 프리미엄, 얼티메이트 Offering: Self-managed

spamcheck 하위 차트는 Spamcheck을(를) 배포합니다. 이는 GitLab이 처음에 GitLab.com의 스팸 증가량에 대항하기 위해 개발한 안티 스팸 엔진으로, 나중에는 Self-managed GitLab 인스턴스에서 사용할 수 있도록 공개되었습니다.

요구 사항

이 차트는 GitLab API에 액세스해야합니다.

구성

Spamcheck 활성화

spamcheck는 기본적으로 비활성화되어 있습니다. GitLab 인스턴스에서 이를 활성화하려면 Helm 속성 global.spamcheck.enabled를 true로 설정하십시오. 예를 들어:

helm upgrade --force --install gitlab . \
--set global.hosts.domain='your.domain.com' \
--set global.hosts.externalIP=XYZ.XYZ.XYZ.XYZ \
--set certmanager-issuer.email='me@example.com' \
--set global.spamcheck.enabled=true

GitLab에서 Spamcheck 사용 설정

왼쪽 사이드바에서 맨 아래에서 관리 영역을 선택합니다.
설정 > 보고를 선택합니다.
스팸 및 안티봇 보호를 확장합니다.
스팸 확인 설정을 업데이트합니다:
1. “외부 API 엔드포인트를 통한 스팸 확인 활성화” 확인란을 체크합니다.
2. 외부 스팸 확인 엔드포인트의 URL로 grpc://gitlab-spamcheck.default.svc:8001을 사용하고, 여기서 default는 GitLab이 배포된 Kubernetes 네임스페이스로 대체됩니다.
3. “스팸 확인 API 키”를 비워 둡니다.
변경 사항 저장을 선택합니다.

설치 명령줄 옵션

아래 표에는 helm install 명령을 사용하여 제공할 수 있는 모든 차트 구성이 포함되어 있습니다.

| 매개변수 | 기본값 | 설명 | | ————————————————- | ——————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————– | ——————————————————————————————————————————————————————————————————————————————————————– | | affinity | {} | Pod 할당을 위한 관련 규칙 | | annotations | {} | Pod 주석 | | common.labels | {} | 이 차트에서 생성된 모든 객체에 적용되는 보조 레이블 | | deployment.livenessProbe.initialDelaySeconds | 20 | Liveness 프로브가 시작되기 전의 지연 | | deployment.livenessProbe.periodSeconds | 60 | Liveness 프로브를 수행하는 빈도 | | deployment.livenessProbe.timeoutSeconds | 30 | Liveness 프로브가 타임아웃되는 시간 | | deployment.livenessProbe.successThreshold | 1 | Liveness 프로브가 실패한 후에 성공으로 간주되기 위한 최소 연속 성공 횟수 | | deployment.livenessProbe.failureThreshold | 3 | Liveness 프로브가 성공한 후에 실패로 간주되기 위한 최소 연속 실패 횟수 | | deployment.readinessProbe.initialDelaySeconds | 0 | Readiness 프로브가 시작되기 전의 지연 | | deployment.readinessProbe.periodSeconds | 10 | Readiness 프로브를 수행하는 빈도 | | deployment.readinessProbe.timeoutSeconds | 2 | Readiness 프로브가 타임아웃되는 시간 | | deployment.readinessProbe.successThreshold | 1 | Readiness 프로브가 실패한 후에 성공으로 간주되기 위한 최소 연속 성공 횟수 | | deployment.readinessProbe.failureThreshold | 3 | Readiness 프로브가 성공한 후에 실패로 간주되기 위한 최소 연속 실패 횟수 | | deployment.strategy | {} | 배포에 의해 사용되는 업데이트 전략을 구성 | | hpa.behavior | {scaleDown: {stabilizationWindowSeconds: 300 }} | 확장 및 축소 동작 사양(‘autoscaling/v2beta2또는 그 이상이 필요) | |hpa.customMetrics | [] | 배포된 오브젝트의 원하는 레플리카 수 계산에 사용할 지표의 사양(기본값으로 targetAverageUtilization에 구성된 평균 CPU 이용률 사용을 무시함) | |hpa.cpu.targetType | AverageValue | 오토스케일링 CPU 대상 유형 설정, Utilization 또는 AverageValue중 하나여야 함 | |hpa.cpu.targetAverageValue | 100m| 오토스케일링 CPU 대상 값 설정 | |hpa.cpu.targetAverageUtilization| | 오토스케일링 CPU 대상 활용도 설정 | |hpa.memory.targetType | | 오토스케일링 메모리 대상 유형 설정, Utilization 또는 AverageValue중 하나여야 함 | |hpa.memory.targetAverageValue| | 오토스케일링 메모리 대상 값 설정 | |hpa.memory.targetAverageUtilization| | 오토스케일링 메모리 대상 활용도 설정 | |hpa.targetAverageValue| | **사용 중단** 오토스케일링 CPU 대상 값 설정 | |image.registry| | Spamcheck 이미지 레지스트리 | |image.repository | registry.gitlab.com/gitlab-com/gl-security/engineering-and-research/automation-team/spam/spamcheck| Spamcheck 이미지 저장소 | |image.tag| | Spamcheck 이미지 태그 | |image.digest| | Spamcheck 이미지 다이제스트 | |keda.enabled | false | [KEDA](https://keda.sh/) ScaledObjects를 HorizontalPodAutoscalers대신 사용 | |keda.pollingInterval | 30| 각 트리거를 확인하는 간격 | |keda.cooldownPeriod | 300| 스케일링 리소스를 다시 0으로 스케일링하기 전에 마지막 트리거가 활성 상태로 보고된 후 대기할 기간 | |keda.minReplicaCount | | KEDA가 리소스를 축소할 때 사용하는 최소 레플리카 수, 기본값은 hpa.minReplicas| |keda.maxReplicaCount | | KEDA가 리소스를 확장할 때 사용하는 최대 레플리카 수, 기본값은 hpa.maxReplicas| |keda.fallback| | KEDA 후속 구성, [문서](https://keda.sh/docs/2.10/concepts/scaling-deployments/#fallback) 참조 | |keda.hpaName | | KEDA가 생성할 HPA 리소스의 이름, 기본값은 keda-hpa-{scaled-object-name}| |keda.restoreToOriginalReplicaCount| | ScaledObject가 삭제된 후 대상 리소스를 원래 레플리카 수로 스케일링해야 하는지 여부 지정 | |keda.behavior | | 확장 및 축소 동작 사양, 기본값은 hpa.behavior| |keda.triggers | | 대상 리소스의 스케일링을 활성화하기 위한 트리거 목록, 기본값은 hpa.cpu와 hpa.memory에서 계산된 트리거 | |logging.level | info| 로그 레벨 | |maxReplicas | 10 | HPA maxReplicas| |maxUnavailable | 1 | HPA maxUnavailable| |minReplicas | 2 | HPA maxReplicas| |podLabels | {}| 보청 Pod 레이블. 셀렉터에 사용되지 않음 | |resources.requests.cpu | 100m| Spamcheck 최소 CPU | |resources.requests.memory | 100M| Spamcheck 최소 메모리 | |securityContext.fsGroup | 1000| Pod가 시작될 그룹 ID | |securityContext.runAsUser | 1000| Pod가 시작될 사용자 ID | |securityContext.fsGroupChangePolicy| | 볼륨의 소유권 및 권한 변경 정책 (Kubernetes 1.23 이상 필요) | |serviceLabels | {}| 보조 서비스 레이블 | |service.externalPort | 8001| Spamcheck 외부 포트 | |service.internalPort | 8001| Spamcheck 내부 포트 | |service.type | ClusterIP| Spamcheck 서비스 유형 | |serviceAccount.automountServiceAccountToken | false| 기본 ServiceAccount 접근 토큰을 파드에 탑재할지 여부를 나타냄 | |serviceAccount.create | false| ServiceAccount를 생성할지 여부를 나타냄 | |serviceAccount.enabled | false| ServiceAccount의 사용 여부를 나타냄 | |tolerations | []| 할당을 위한 Toleration 레이블 | |extraEnvFrom | {}| 노출할 다른 데이터 원본에서의 추가 환경 변수 목록 | |priorityClassName` | | Pod에 할당된 Priority class |

KEDA 구성

이 keda 섹션은 일반적인 HorizontalPodAutoscalers 대신 KEDA ScaledObjects의 설치를 가능하게 합니다. 이 구성은 선택 사항이며, 사용자 지정 또는 외부 지표에 기반한 오토 스케일링이 필요할 때 사용할 수 있습니다.

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

다음 사항이 참이면 CPU 및 메모리 트리거가 자동으로 추가되며 hpa 섹션에서 설정된 CPU 및 메모리 임계값에 따라 설정됩니다: - triggers이 설정되지 않았을 때. - 해당 request.cpu.request 또는 request.memory.request 설정도 0이 아닌 값으로 설정되었을 때.

트리거가 설정되지 않으면 ScaledObject가 생성되지 않습니다.

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

이름	유형	기본값	설명
`enabled`	부울	`false`	KEDA `ScaledObjects`를 `HorizontalPodAutoscalers` 대신 사용합니다.
`pollingInterval`	정수	`30`	각 트리거를 확인하는 간격
`cooldownPeriod`	정수	`300`	최후의 트리거가 활성화된 후 해당 기간 동안 대상 리소스를 다시 0으로 축소하기 전에 기다릴 기간
`minReplicaCount`	정수		KEDA가 리소스를 축소하는 데 사용할 최소 복제본 수. 기본값은 `hpa.minReplicas`로 설정됩니다.
`maxReplicaCount`	정수		KEDA가 리소스를 확장하는 데 사용할 최대 복제본 수. 기본값은 `hpa.maxReplicas`로 설정됩니다.
`fallback`	맵		KEDA 예비 구성에 대한 내용은 문서를 참조하십시오.
`hpaName`	문자열		KEDA가 생성할 HPA 리소스의 이름. 기본값은 `keda-hpa-{scaled-object-name}`으로 설정됩니다.
`restoreToOriginalReplicaCount`	부울		`ScaledObject`가 삭제된 후 대상 리소스를 원래 복제본 수로 축소해야 하는지 여부를 지정합니다.
`behavior`	맵		확장 및 축소 동작에 대한 사양. 기본값은 `hpa.behavior`로 설정됩니다.
`triggers`	배열		대상 리소스의 스케일링을 활성화하는 트리거 목록. 기본값은 `hpa.cpu` 및 `hpa.memory`에서 계산된 트리거 목록입니다.

차트 구성 예시

serviceAccount

이 섹션은 ServiceAccount를 만들어야 하는지 및 기본 액세스 토큰을 포드에 마운트해야 하는지를 제어합니다.

이름	유형	기본값	설명
`automountServiceAccountToken`	부울	`false`	기본 ServiceAccount 액세스 토큰을 포드에 마운트해야 하는지 여부를 제어합니다. 필요한 경우에만 활성화해야 합니다(예: Istio의 경우 특정 사이드카가 제대로 작동하려면 활성화해야 함).
`create`	부울	`false`	ServiceAccount를 만들어야 할지 여부를 나타내는 지시값.
`enabled`	부울	`false`	ServiceAccount를 사용할지 여부를 나타내는 지시값.

tolerations

tolerations을 사용하여 오염된 워커 노드에 포드를 예약할 수 있습니다.

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

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

affinity

추가 정보는 affinity를 참조하십시오.

annotations

annotations을 사용하여 스팸체크 포드에 주석을 추가할 수 있습니다. 예:

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

resources

resources를 사용하여 스팸체크 포드가 사용할 수 있는 리소스(메모리 및 CPU)의 최소 및 최대량을 구성할 수 있습니다.

예:

resources:
  requests:
    memory: 100m
    cpu: 100M

livenessProbe/readinessProbe

deployment.livenessProbe 및 deployment.readinessProbe는 일부 시나리오에서 스팸체크 포드의 종료를 제어하는 메커니즘을 제공합니다. 예를 들어, 컨테이너가 손상된 상태인 경우 등의 경우입니다.

예:

deployment:
  livenessProbe:
    initialDelaySeconds: 10
    periodSeconds: 20
    timeoutSeconds: 3
    successThreshold: 1
    failureThreshold: 10
  readinessProbe:
    initialDelaySeconds: 10
    periodSeconds: 5
    timeoutSeconds: 2
    successThreshold: 1
    failureThreshold: 3

이 구성에 대한 자세한 내용은 공식 Kubernetes Documentation을 참조하십시오.

GitLab-Spamcheck 차트 사용하기

요구 사항

구성

Spamcheck 활성화

GitLab에서 Spamcheck 사용 설정

설치 명령줄 옵션

KEDA 구성

차트 구성 예시

serviceAccount

tolerations

affinity

annotations

resources

livenessProbe/readinessProbe

도움말

기능 사용 가능성과 제품 평가판

도움받기