本篇和前面的 基于helm的方式在k8s集群中部署gitlab
具有很强的关联性,因此如果有不明白的地方可以查看往期分享:
- 基于helm的方式在k8s集群中部署gitlab - 部署
- 基于helm的方式在k8s集群中部署gitlab - 备份恢复
- 基于helm的方式在k8s集群中部署gitlab - 升级
文章目录
- 1. 背景
- 2. 配置
- step1: 在集群上打标签
- step2: 修改gitlab的values文件
- step3: 配置生效
- step4: 验证
1. 背景
- 在某些场景下,我们在使用kubernetes作为gitlab-runner的执行器的时候,希望将ci文件运行的runner pod调度到指定的节点上,便于运行某些job,如调度到有gpu资源上的node。
- 对此,我们可以使用gitlab-runner的高级配置,使用node_selector关键字可以将runner运行的pod调度到某个节点上。
- 参考文档:gitlab-runner高级配置
2. 配置
step1: 在集群上打标签
master节点打上runner_node=M1
,slave节点打上runner_node=S1
kubectl label nodes k8s-master01 runner_node=M1
kubectl label nodes k8s-worker01 runner_node=S1
step2: 修改gitlab的values文件
添加 [runners.kubernetes.node_selector]
配置,并配置指定调度的label的key和value
gitlab-runner:
...
...
runners:
...
config: |
[[runners]]
[runners.kubernetes]
...
{{- if .Values.global.minio.enabled }}
[runners.cache]
...
[runners.cache.s3]
...
[runners.kubernetes.node_selector]
runner_node = "S1"
{{ end }}
step3: 配置生效
执行helm upgrade命令
helm upgrade gitlab gitlab-jh/gitlab --version 7.3.6 --timeout 600s --set certmanager.install=false --set global.ingress.configureCertmanager=false --set global.ingress.tls.enabled=true --set gitlab.webservice.ingress.tls.secretName=gitlab-jihulab-cn-ssl --set registry.ingress.tls.secretName=registry-jihulab-cn-ssl --set minio.ingress.tls.secretName=minio-jihulab-cn-ssl --values values.yaml -n jihulab
step4: 验证
运行gitlab-ci流水线,通过命令查看runner的运行pod在哪个节点上;以下分别是调度到master节点和slave节点的展示