使用 GitLab-Spamcheck chart
spamcheck
子 chart 提供了 Spamcheck 的部署,这是一个反垃圾邮件引擎。
要求
此 chart 依赖于对 GitLab API 的访问。
配置
启用 Spamcheck
spamcheck
默认被禁用。要在实例上启用它,请将 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
配置使用 Spamcheck
- 在左侧边栏上,选择 搜索或转到。
- 选择 管理中心。
- 选择 设置 > 报告
- 展开 垃圾邮件和反机器人防护。
- 更新垃圾邮件检查设置:
- 选中 通过外部API端点启用垃圾信息检查 复选框。
- 对于外部垃圾邮件检查端点的 URL,使用
grpc://gitlab-spamcheck.default.svc:8001
,其中default
替换为部署极狐GitLab 的 Kubernetes 命名空间。 - 将 垃圾邮件检查 API 密钥 留空。
- 选择 保存更改。
安装命令行选项
下表包含可以使用 --set
标志提供给 helm install
命令的所有可能的 chart 配置。
参数 | 默认值 | 描述 |
---|---|---|
annotations
| {}
| Pod annotations |
common.labels
| {}
| 应用于此 chart 创建的所有对象的补充标签。 |
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.targetAverageValue
| 100m
| 设置自动扩缩容目标值 |
hpa.cpu.targetAverageUtilization
| 设置自动缩放 CPU 目标利用率 | |
hpa.memory.targetType
| 设置自动缩放内存目标类型,必须是 Utilization 或 AverageValue
| |
hpa.memory.targetAverageValue
| 设置自动缩放内存目标值 | |
hpa.memory.targetAverageUtilization
| 设置自动缩放内存目标利用率 | |
hpa.minReplicas
| 最小副本数 | |
hpa.maxReplicas
| 最大副本数 | |
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 镜像 digest | |
keda.enabled
| false
| 使用 KEDA ScaledObjects 替代 HorizontalPodAutoscalers
|
keda.pollingInterval
| 30
| 检查每个触发器的时间间隔 |
keda.cooldownPeriod
| 300
| 最后一个触发器报告有效后,在将资源缩放回 0 之前等待的时间 |
keda.minReplicaCount
| KEDA 将资源缩减到的最小副本数,默认为 hpa.minReplicas
| |
keda.maxReplicaCount
| KEDA 将资源扩展到的最大副本数,默认为 hpa.maxReplicas
| |
keda.fallback
| KEDA 后备配置,请参阅文档 | |
keda.hpaName
| KEDA 将创建的 HPA 资源的名称,默认为 keda-hpa-{scaled-object-name}
| |
keda.restoreToOriginalReplicaCount
| 指定删除 ScaledObject 后,目标资源是否应缩减至原始副本数
| |
keda.behavior
| 放大和缩小行为的 spec,默认为 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.enabled
| 使用 ServiceAccount 标志 | false
|
serviceAccount.create
| 创建 ServiceAccount 标志 | false
|
tolerations
| []
| pod 分配的 toleration 标签 |
extraEnvFrom
| {}
| 要暴露的其它数据源的额外环境变量列表 |
priorityClassName
| 指派给 Pod 的优先级别。 |
配置 KEDA
keda
部分允许安装 KEDA ScaledObjects
,而不是常规的 HorizontalPodAutoscalers
。
此配置是可选的,可以在需要根据自定义或外部指标进行自动缩放时使用。
大多数设置默认为 hpa
部分中适用的值。
如果满足以下条件,则会根据 hpa
部分中设置的 CPU 和内存阈值自动添加 CPU 和内存触发器:
- 未设置
triggers
。 - 相应的
request.cpu.request
或request.memory.request
也设置为非零值。
如果未设置触发器,则不会创建 ScaledObject
。
有关这些设置的更多详细信息,请参阅 KEDA 文档。
名称 | 类型 | 默认值 | 描述 |
---|---|---|---|
enabled
| Boolean | false
| 使用 KEDA ScaledObjects 替代 HorizontalPodAutoscalers
|
pollingInterval
| Integer | 30
| 检查每个触发器的时间间隔 |
cooldownPeriod
| Integer | 300
| 最后一个触发器报告有效后,在将资源缩放回 0 之前等待的时间 |
minReplicaCount
| Integer | KEDA 将资源缩减到的最小副本数,默认为 hpa.minReplicas
| |
maxReplicaCount
| Integer | KEDA 将资源扩展到的最大副本数,默认为 hpa.maxReplicas
| |
fallback
| Map | KEDA 后备配置,请参阅文档 | |
hpaName
| String | KEDA 将创建的 HPA 资源的名称,默认为 keda-hpa-{scaled-object-name}
| |
restoreToOriginalReplicaCount
| Boolean | 指定删除 ScaledObject 后,目标资源是否应缩减至原始副本数
| |
behavior
| Map | 放大和缩小行为的 spec,默认为 hpa.behavior
| |
triggers
| Array | 用于激活目标资源扩展的触发器列表,默认为根据 hpa.cpu 和 hpa.memory 计算的触发器
|
Chart 配置示例
tolerations
tolerations
允许您调度 pod 到受污染的工作节点上。
下面是一个使用 tolerations
的示例:
tolerations:
- key: "node_label"
operator: "Equal"
value: "true"
effect: "NoSchedule"
- key: "node_label"
operator: "Equal"
value: "true"
effect: "NoExecute"
annotations
annotations
允许您向 Spamcheck pod 添加注释。例如:
annotations:
kubernetes.io/example-annotation: annotation-value
resources
resources
允许您配置 Spamcheck pod 可以消耗的最小和最大资源量(内存和 CPU)。
例如:
resources:
requests:
memory: 100m
cpu: 100M
livenessProbe/readinessProbe
deployment.livenessProbe
和 deployment.readinessProbe
提供了一种机制,来帮助控制 Spamcheck Pod 在某些情况下的终止,例如,当容器处于损坏状态时。
例如:
deployment:
livenessProbe:
initialDelaySeconds: 10
periodSeconds: 20
timeoutSeconds: 3
successThreshold: 1
failureThreshold: 10
readinessProbe:
initialDelaySeconds: 10
periodSeconds: 5
timeoutSeconds: 2
successThreshold: 1
failureThreshold: 3
有关此配置的更多详细信息,请参阅官方 Kubernetes 文档。