gitlab-runner使用kubernetes executor

本文详细介绍了如何在Kubernetes集群中配置和使用gitlab-runner,包括部署gitlab-runner的步骤、配置.gitlab-ci.yml文件、实现Auto-Devops以及优化流程。涉及的工具有docker、maven、kubectl,以及使用Kubernetes serviceaccount进行权限管理。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

gitlabrunner使用k8s executor

相关的文章有:gitlab-runner使用docker executor
两者主要区别在于,一个部署在docker服务器上,一个部署在k8s的pod中。

所需镜像

基础镜像

  • gitlab-runner:latest
    • gitlab-runner打包成的镜像,需要在k8s上长期驻留
  • gitlab-runner-helper:x86_64-f100a208
    • 这个是gitlab-runner用来启动pod的,他的版本由gitlab-runner版本和服务器版本决定
  • maven:3-jdk-8
    • 如果处理的是java代码,那此镜像既可以做为编译的镜像,也可以作为发布时的基础镜像。
  • busybox:latest
    • 默认镜像,如果不指定runner启动哪个镜像,就选择busybox
  • docker:dind
    • 用于编译业务镜像,基于maven:3-jdk-8
  • kubectl
    • 将业务镜像部署到k8s上

第一步:在K8S中部署gitlab-runner

在gitlab上找到url和token

  • 打开你想要配置CICD的项目或项目组
  • runner配置地址:settings->CI/CD->Runners->expand
  • 找到设置runner需要的url和token,拿小本本记下来

url和token

创建一个可用的runner

  • 找一台安装了docker的机器,使用以下命令生成toml:docker run -it --name runner gitlab/gitlab-runner:v11.10.0 register

register过程

  • settings->CI/CD->Runners->expand下找到新增的runner,获得新tokenkg8sKRsXs9kYWsMp5PJ7,记在小本本上。而上一步启动的runner已经不再需要了。

创建k8s上的gitlab-runner的配置文件

注意:这里的token使用我们新获得的token。

kind: ConfigMap
apiVersion: v1
metadata:
  name: gitlab-runner
  namespace: gitlab-runner
data:
  config.toml: |
    concurrent = 4
    check_interval = 0

    [session_server]
      session_timeout = 1800

    [[runners]]
      name = "first test"
      url = "http://${
   
   gitlabIP}"
      token ="......"
      executor = "kubernetes"
      [runners.kubernetes]
        host = ""
        bearer_token_overwrite_allowed = true
        privileged = true
        #这是runner的默认镜像;具体镜像maven:3-jdk-8在.gitlab-ci.yml中配置
        image = "${
   
   registryIP}/gitlab-runner/busybox:latest"  
        namespace = "gitlab-runner"
        namespace_overwrite_allowed = ""
        cpu_limit = "1"
        memory_limit = "2Gi"
        cpu_request = "1"
        memory_request = "2Gi"
        service_cpu_limit = "1"
        service_memory_limit = "2Gi"
        service_cpu_request = "1"
        service_memory_request = "2Gi"
        helper_cpu_limit = "1"
        helper_memory_limit = "2Gi"
        helper_cpu_request = "1"
        helper_memory_request = "2Gi"
        service_account = "gitlab"
        helper_image = "${
   
   registryIP}/gitlab-runner/gitlab-runner-helper:x86_64-f100a208"
        [
### 如何选择适合的 GitLab Runner Executor 类型 #### Shell 执行器 Shell 执行器是最简单的执行器之一,它直接在主机上运行命令。这种方式适用于大多数脚本语言和工具,因为不需要额外的环境设置。然而,由于其依赖于宿主机的操作系统和安装软件,因此灵活性较低[^1]。 对于那些希望快速测试 CI/CD 流水线而无需复杂配置的人来说,shell 是一个不错的选择;但对于生产环境中更复杂的项目来说可能不够理想。 #### Docker 执行器 Docker 执行器允许在一个隔离的容器内执行作业。这提供了更好的可移植性和一致性,因为它可以在任何支持 Docker 的平台上工作,并且每次构建都可以从相同的干净状态开始。当注册带有 `--docker-volumes` 和 `--docker-network-mode 'host'` 参数时,能够使容器访问本地资源和服务,这对于某些特定需求非常重要[^3]。 如果团队已经在使用 Docker 或者计划迁移到微服务架构下开发应用的话,那么采用 docker 作为 runnerexecutor 将会是一个明智之举。 #### Kubernetes 执行器 Kubernetes (k8s) 执行器专为基于 k8s 集群的应用程序设计。它可以动态创建 Pod 来处理来自不同项目的多个并行任务。此方法非常适合大规模分布式系统的持续集成与部署流程管理。不过需要注意的是,在实际操作前需确保有可用的 K8S 环境以及适当权限来管理和调度这些 pod 资源。 考虑到性能优化方面的要求,比如减少等待时间提高效率等优点,k8s 可能更适合大型企业级应用程序或云原生平台上的项目。 #### 自定义执行器 除了官方提供的几种常见类型的 executors 外,还有其他一些第三方插件形式存在的自定义选项可供选用。例如 Parallel Executor 支持多进程并发执行从而加快速度;VirtualBox Executor 则利用虚拟机技术实现更加彻底的隔离效果等等。根据具体业务场景和个人偏好做出合适的选择即可[^2]。 综上所述,选择哪种类型的 GitLab Runner 主要取决于具体的项目需求和技术栈特点等因素: - 如果追求简单易用性可以选择 shell; - 对于想要获得更高程度的一致性的用户推荐尝试 docker- 当涉及到更大规模的企业级解决方案则应考虑 k8s- 若存在特殊要求还可以探索更多样化的定制化方案。 ```bash sudo gitlab-runner run -c config.toml -u runner & ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值