使用 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 文档。