k3s x GitLab Runner Operator,GitLab CI 云原生构建新体验

GitLab CI 是非常常用的一款 CI/CD 工具,只需要在 .gitlab-ci.yml 文件中用 YAML 语法编写 CI/CD 流水线即可。而 GitLab CI 能够运行的关键组件是 GitLab Runner。GitLab Runner 是一个轻量级、高扩展的代理,主要用来执行 GitLab CI/CD 流水线中的 Job,然后将 Job 的执行结果返回 GitLab 实例。

GitLab Runner 的安装方式有很多种,包括安装包、Docker、Helm Chart 等,本文将用 GitLab Runner Operator 的方式来在 k3s 上安装 GitLab Runner,并执行 CI/CD 流水线。关于其他安装方式的详情,可以查看 GitLab Runner 安装文档

GitLab Runner Operator 主要是在 Kubernetes 平台上来管理 GitLab Runner。在 Kubernetes 平台上安装 GitLab Runner 有两个先决条件:

  • Kubernetes 的版本必须是 v1.21.1 以上
  • Cert manager 的版本为 v1.7.1 以上

本文使用 k3s 来搭建一个 Kubernetes 平台。


k3s 的安装


k3s 是经 CNCF 一致性认证的 Kubernetes 发行版,专为物联网及边缘计算而设计。简言之,k3s 是一个轻量级的 Kubernetes 发行版。

k3s 的安装非常简单,对于国内用户来讲,执行如下命令可以加速 k3s 的安装:

$ curl -sfL https://rancher-mirror.rancher.cn/k3s/k3s-install.sh | INSTALL_K3S_MIRROR=cn sh -
[INFO]  Finding release for channel stable
[INFO]  Using v1.28.5+k3s1 as release
[INFO]  Downloading hash rancher-mirror.rancher.cn/k3s/v1.28.5-k3s1/sha256sum-amd64.txt
[INFO]  Downloading binary rancher-mirror.rancher.cn/k3s/v1.28.5-k3s1/k3s
[INFO]  Verifying binary download
[INFO]  Installing k3s to /usr/local/bin/k3s
[INFO]  Skipping installation of SELinux RPM
[INFO]  Creating /usr/local/bin/kubectl symlink to k3s
[INFO]  Creating /usr/local/bin/crictl symlink to k3s
[INFO]  Skipping /usr/local/bin/ctr symlink to k3s, command exists in PATH at /usr/bin/ctr
[INFO]  Creating killall script /usr/local/bin/k3s-killall.sh
[INFO]  Creating uninstall script /usr/local/bin/k3s-uninstall.sh
[INFO]  env: Creating environment file /etc/systemd/system/k3s.service.env
[INFO]  systemd: Creating service file /etc/systemd/system/k3s.service
sh: 1014: restorecon: not found
sh: 1015: restorecon: not found
[INFO]  systemd: Enabling k3s unit
Created symlink /etc/systemd/system/multi-user.target.wants/k3s.service → /etc/systemd/system/k3s.service.
[INFO]  systemd: Starting k3s

接着可以查看 k3s 是否安装成功:

#查看 k3s 版本
$ k3s --version
k3s version v1.28.5+k3s1 (5b2d1271)
go version go1.20.12

# 查看 k3s 集群
$ kubectl get nodes
NAME             STATUS   ROLES                  AGE   VERSION
vm-0-12-ubuntu   Ready    control-plane,master   38s   v1.28.5+k3s1

上述命令已经快速构建了一个单节点的 k3s 集群。接下来就可以在这个 k3s 集群上使用 GitLab Runner Operator 来安装 GitLab Runner 了。安装详情可以在 OperatorHub.io 上查看详细步骤。


GitLab Runner Operator 的安装

在安装之前首先需要安装 cert-manager。


安装 cert-manager

使用如下命令即可完成安装。

$ kubectl apply -f https://github.com/jetstack/cert-manager/releases/download/v1.7.1/cert-manager.yaml

customresourcedefinition.apiextensions.k8s.io/certificaterequests.cert-manager.io created
customresourcedefinition.apiextensions.k8s.io/certificates.cert-manager.io created
customresourcedefinition.apiextensions.k8s.io/challenges.acme.cert-manager.io created

......太长了,删除一部分输出日志......

mutatingwebhookconfiguration.admissionregistration.k8s.io/cert-manager-webhook created
validatingwebhookconfiguration.admissionregistration.k8s.io/cert-manager-webhook created

上述过程中安装了 N 多 Kubernetes 资源。

安装 Operator Lifecycle Manager

接下来要安装 Operator Lifecycle Manager(OLM),这是一个能够对 Kubernetes 集群上 Operator 进行管理的工具。使用如下命令安装:

$ curl -sL https://github.com/operator-framework/operator-lifecycle-manager/releases/download/v0.26.0/install.sh | bash -s v0.26.0

customresourcedefinition.apiextensions.k8s.io/catalogsources.operators.coreos.com created
customresourcedefinition.apiextensions.k8s.io/clusterserviceversions.operators.coreos.com created

......太长了,删除一部分输出日志......

Waiting for deployment "olm-operator" rollout to finish: 0 of 1 updated replicas are available...
deployment "olm-operator" successfully rolled out
deployment "catalog-operator" successfully rolled out
Package server phase: Installing
Package server phase: Succeeded
deployment "packageserver" successfully rolled out

可以将上面的版本换成自己想要的版本,比如 `v0.22.0`。


安装 Operator

接下来执行如下命令来完成 Operator 的安装:

$ kubectl create -f https://operatorhub.io/install/stable/gitlab-runner-operator.yaml
subscription.operators.coreos.com/my-gitlab-runner-operator created

查看安装的 Operator

使用如下命令查看 Operator 是否安装成功

# 查看 csv 资源
$ kubectl get csv -n operators
NAME                             DISPLAY         VERSION   REPLACES                         PHASE
gitlab-runner-operator.v1.15.1   GitLab Runner   1.15.1    gitlab-runner-operator.v1.15.0   Succeeded

# 查看 pod 状态
$ kubectl -n operators get pods
NAME                                                READY   STATUS    RESTARTS   AGE
gitlab-runner-controller-manager-5b7f856fc5-fhk2f   2/2     Running   0          20h

接下来就可以使用 GitLab Runner Operator 来创建 GitLab Runner 了。

使用 Operator 创建 GitLab Runner

本文使用 GitLab 中国发行版——极狐GitLab 来进行测试。极狐GitLab 是 GitLab 除 CE/EE 之外发行的另外一个版本,专门面向中国用户。可以私有化部署,也可以使用 SaaS(jihulab.com)。

创建 GitLab Runner 之前,需要明确创建什么样的 Runner,是共享的还是专有的,是群组级别的还是项目级别的。关于 GitLab Runner 的作用范围可以查看 GitLab Runner 官方文档

获取 Runner 注册 token

以注册项目 Runner 为例来说,在项目 --> 设置 --> CI/CD --> Runner 中,选择新建项目 Runner

点击新建项目 Runner 选项,在出现的界面中填写好对于的信息,包括 Runner 标签、描述等:

点击创建 Runner就会出现注册 Runner 的命令,在命令中就有 Runner 注册的 token,默认以 plrt 开头。

一定要保存好此 token,后面会用到。

创建包含注册 token 的 secret

将上一步中获取的 Runner 注册 token 存入下方的 yaml 文件:

cat > gitlab-runner-secret.yml << EOF
  apiVersion: v1
  kind: Secret
  metadata:
    name: jh-gitlab-runner-secret
  type: Opaque
  stringData:
    runner-registration-token: REPLACE_ME # 上一步中创建的 Runner 注册 token
  EOF

使用如下命令创建 secret

$ kubectl  apply -f gitlab-runner-secret.yml
secret/jh-gitlab-runner-secret created

创建 Runner CRD

Runner CRD yaml 文件内容如下:

cat > gitlab-runner.yml << EOF
apiVersion: apps.gitlab.com/v1beta2
kind: Runner
metadata:
    name: gitlab-runner
spec:
    gitlabUrl: https://jihulab.com
    buildImage: alpine
    token: jh-gitlab-runner-secret
EOF

参数说明:

  • gitlabUrl:GitLab/极狐GitLab 实例的地址,本文使用极狐GitLab SaaS,地址为 https://jihulab.com。
  • token:上一步创建的 secret 名称。

使用如下命令完成 Runner CRD 的创建:

$ kubectl apply -f gitlab-runner.yml
runner.apps.gitlab.com/jh-gitlab-runner created

接着确认一下 Runner CRD 是否创建成功:

# 查看 Runner CRD 资源
kubectl get runner
NAME               AGE
jh-gitlab-runner   20h

# 查看 Runner pod
$ kubectl  get pods
NAME                                       READY   STATUS    RESTARTS   AGE
jh-gitlab-runner-runner-6f7c4bf7dc-r9lzh   1/1     Running   0          16h

接着就可以在项目的 Runner 页面查看 Runner 是否注册成功:

可以看到有一个该项目专用的 Runner 已经注册成功。接下来测试此 Runner。


Runner 测试

在项目的 .gitlab-ci.yml 文件中写入一个构建容器镜像并推送到极狐GitLab 内置的镜像仓库的 Job 配置:

build:
  image: docker:latest
  stage: build
  tags:
    - jh
  services:
    - docker:20.10.7-dind
  script:
    - docker login -u "$CI_REGISTRY_USER" -p "$CI_REGISTRY_PASSWORD" $CI_REGISTRY
    - docker build -t $CI_REGISTRY_IMAGE:v1.0.0 .
    - docker push $CI_REGISTRY_IMAGE:v1.0.0


触发流水线,然后在项目 --> 构建 --> 流水线中查看结果:

可以看到流水线构建成功。再查看构建日志,确认构建此次流水线所需的 Runner 是否为上面创建的 Runner:

从红色方框的信息看,此次 CI/CD 流水线构建使用的就是上述用 GitLab Runner Operator 创建出来的 Runner。

过程中遇到的问题及修复方案


operators 中 gcr.io 镜像不可用问题

在安装 Operator 的过程中,gitlab-runner-controller-manager 依赖镜像 gcr.io/kubebuilder/kube-rbac-proxy:v0.8.0。由于此镜像在国内无法正常拉取,会导致以下错误:

$ kubectl -n operators get pods -w
NAME                                                READY   STATUS              RESTARTS   AGE
gitlab-runner-controller-manager-6d88d9d9d4-tdf5m   0/2     ContainerCreating   0          15s
gitlab-runner-controller-manager-6d88d9d9d4-tdf5m   1/2     ErrImagePull        0          31s
gitlab-runner-controller-manager-6d88d9d9d4-tdf5m   1/2     ImagePullBackOff    0          32s

镜像拉取失败的详细日志:

Warning  Failed     45s                kubelet            Failed to pull image "gcr.io/kubebuilder/kube-rbac-proxy:v0.8.0": rpc error: code = DeadlineExceeded desc = failed to pull and unpack image "gcr.io/kubebuilder/kube-rbac-proxy:v0.8.0": failed to resolve reference "gcr.io/kubebuilder/kube-rbac-proxy:v0.8.0": failed to do request: Head "https://gcr.io/v2/kubebuilder/kube-rbac-proxy/manifests/v0.8.0": dial tcp 173.194.174.82:443: i/o timeout
Warning  Failed     45s                kubelet            Error: ErrImagePull
Normal   Pulled     45s                kubelet            Container image "registry.gitlab.com/gitlab-org/gl-openshift/gitlab-runner-operator/gitlab-runner-operator:v1.15.1" already present on machine
Normal   Created    45s                kubelet            Created container manager
Normal   Started    45s                kubelet            Started container manager
Normal   BackOff    44s (x2 over 45s)  kubelet            Back-off pulling image "gcr.io/kubebuilder/kube-rbac-proxy:v0.8.0"
Warning  Failed     44s (x2 over 45s)  kubelet            Error: ImagePullBackOff
Normal   Pulling    29s (x2 over 75s)  kubelet            Pulling image "gcr.io/kubebuilder/kube-rbac-proxy:v0.8.0"

提示无法拉取 gcr.io/kubebuilder/kube-rbac-proxy:v0.8.0。解决办法为将上述镜像替换为 kubesphere/kube-rbac-proxy:v0.8.0。替换完成后,pod 运行正常:

$ kubectl  -n operators get pods
NAME                                                READY   STATUS    RESTARTS   AGE
gitlab-runner-controller-manager-5b7f856fc5-fhk2f   2/2     Running   0          20h

看这个镜像应该是 kubesphere 制作的,在此感谢 kubesphere 团队所做的贡献。


pod 中执行 docker 命令

上面测试的 Job 是现在在 kubernetes pod 中执行 docker 命令来构建容器镜像:

build:
  image: docker:latest
  stage: build
  tags:
    - jh
  services:
    - docker:20.10.7-dind
  script:
    - docker login -u "$CI_REGISTRY_USER" -p "$CI_REGISTRY_PASSWORD" $CI_REGISTRY
    - docker build -t $CI_REGISTRY_IMAGE:v1.0.0 .
    - docker push $CI_REGISTRY_IMAGE:v1.0.0

这个过程中其实需要将宿主机的 docker.sock 文件挂在到 Runner pod 里面。这个时候就需要对于 Runner 的 config.toml 文件进行修改了。

使用 Operator 安装的 Runner,其配置文件以 configmap 的形式存在,可以在 Runner 所在的 namespace 下面查看:

$ kubectl  get cm
NAME                             DATA   AGE
jh-gitlab-runner-runner-config   6      20h


查看上述 configmap 的内容,默认情况下对于 config.toml 文件的描述仅有一下内容:

  config.toml: |-
    concurrent = 10
    check_interval = 30
    log_level = "info"
    listen_address = '[::]:9252'

在 Runner pod 中查看 `config.toml` 文件的配置:

[runners.kubernetes]
    host = ""
    bearer_token_overwrite_allowed = false
    image = "alpine"
    namespace = "default"
    namespace_overwrite_allowed = ""
    node_selector_overwrite_allowed = ""
    helper_image = "registry.gitlab.com/gitlab-org/ci-cd/gitlab-runner-ubi-images/gitlab-runner-helper-ocp:v16.0.1"
    poll_timeout = 180
    pod_labels_overwrite_allowed = ""
    service_account_overwrite_allowed = ""
    pod_annotations_overwrite_allowed = ""
    [runners.kubernetes.pod_security_context]
    [runners.kubernetes.init_permissions_container_security_context]
    [runners.kubernetes.build_container_security_context]
    [runners.kubernetes.helper_container_security_context]
    [runners.kubernetes.service_container_security_context]
    [runners.kubernetes.volumes]
    [runners.kubernetes.dns_config]

可以看到在 `[runners.kubernetes.volumes]` 配置中并没有挂载 docker.sock 文件。这时候就需要通过自定义 config.toml 文件的形式来完成文件的挂载了。整个自定义的过程可以查看GitLab config.toml 文件自定义官方文档

首先,创建一个 `custome-config.toml` 文件,写入挂载文件的内容:

[[runners]]
  [runners.kubernetes]
    [runners.kubernetes.volumes]
      [[runners.kubernetes.volumes.host_path]]
          name = "docker"
          mount_path = "/var/run/docker.sock"
          host_path = "/var/run/docker.sock"

然后,以文件的形式创建 configmap:

$ kubectl create configmap custom-config-toml --from-file config.toml=custom-config.toml
configmap/custom-config-toml created

然后将上述新增的 configmap 添加到 Runner 的 CRD 中:

apiVersion: apps.gitlab.com/v1beta2
kind: Runner
metadata:
  name: jh-gitlab-runner
spec:
  gitlabUrl: https://jihulab.com
  buildImage: alpine
  token: jh-gitlab-runner-secret
  config: custom-config-toml

以 config 为关键字将自定义的 configmap 内容引入。然后创建 Runner 即可。最后可以在 Runner pod 中看到如下内容:

    [runners.kubernetes.volumes]
      [[runners.kubernetes.volumes.host_path]]
        name = "docker"
        mount_path = "/var/run/docker.sock"
        host_path = "/var/run/docker.sock"

说明宿主机的 docker.sock 文件被挂载到了 Runner pod 中,这样就可以在 pod 中使用 docker 命令了。当然,这种方式存在一定的安全问题,建议使用 `kaniko` 进行镜像构建。详情可以查看过往的技术文章Kaniko- 以一种更安全可靠的方式在Kubernetes平台上构建容器镜像

GitHub 无法链接

在安装 Operator 的时候,因为会从 Operator GitHub 仓库拉取资源直接安装,这时候可能会遇到 GitHub 无法链接的问题(看你服务器在哪儿了)。这时候就可以在Operator Lifycycle Manager GitHub Repo上看一下内容,把无法拉取的文件内容想办法搞到本地,然后在本地执行即可。比如 install.sh、crds.yml、olm.yml文件。当然,前提是要看懂这些文件里面的内容,适当的时候要做一些调整。当然,调整不会影响安装使用。
 

<think>嗯,用户想了解Kubernetes的实战项目推荐。首先,我需要确定用户的背景。可能是一个刚开始学习Kubernetes的人,想要通过实际项目来巩固知识,或者是有一定基础想找项目练手。用户提到的是“实战项目”,所以应该需要具体、可操作的项目建议,而不仅仅是理论。 接下来,我应该考虑哪些类型的项目适合不同水平的学习者。比如,对于初学者,可能适合部署简单的应用,比如WordPress或者博客系统。中级用户可能需要涉及CI/CD、监控、日志等。高级用户可能涉及多集群管理、服务网格、自定义控制器等。 然后,要确保推荐的项目覆盖常见的Kubernetes使用场景,比如应用部署、自动化、监控、伸缩、服务发现等。每个项目需要说明技术栈和收获,这样用户能清楚项目的目的和能学到什么。 还要注意项目的可实施性,是否有详细的文档或教程可以参考。可能需要推荐一些GitHub上的热门项目或者官方示例,这样用户容易找到资源。 另外,用户可能希望项目有实际应用价值,比如微服务架构、云原生应用,这样在简历或实际工作中也能派上用场。比如部署一个电商微服务系统,或者使用Kubernetes管理机器学习工作流。 还需要考虑用户可能对某些工具或技术栈不熟悉,比如Helm、Prometheus、Istio等,所以在推荐项目时应该适当介绍这些工具,并说明在项目中的作用。 另外,可能用户希望从简单到复杂的项目路径,逐步提升技能。所以应该分层次推荐,从基础到高级,让用户可以根据自身情况选择。 同时,要确保推荐的项目涵盖不同的方面,比如存储管理、网络策略、安全加固,这样用户能全面了解Kubernetes的各个组件和功能。 最后,可能需要提醒用户在学习过程中注意实践和文档记录,以及如何解决常见问题,比如调试Pod、排查网络问题等。可能还需要建议他们结合官方文档和社区资源,遇到问题时积极查找解决方案。</think>以下是一些适合不同阶段的Kubernetes实战项目推荐,涵盖从基础到进阶的实践场景,建议根据自身技术水平选择: --- ### **一、入门级项目(熟悉基础概念)** 1. **部署WordPress博客系统** - 技术栈:Deployment/Service/PVC/MySQL - 收获:掌握Pod生命周期管理、服务暴露(NodePort/LoadBalancer)、持久化存储配置 - 扩展:尝试用Helm Chart一键部署 2. **搭建多节点Redis集群** - 技术栈:StatefulSet/Headless Service/ConfigMap - 收获:理解有状态应用部署、DNS解析机制、配置文件注入 3. **自动化构建CI/CD流水线** - 技术栈:Jenkins/GitLab Runner + Kubernetes Pod Executor - 收获:实践容器化构建、流水线任务调度、动态资源分配 --- ### **二、中级项目(提升运维能力)** 4. **全链路监控系统** - 技术栈:Prometheus + Grafana + Alertmanager - 收获:配置指标采集、自定义告警规则、可视化监控大盘 - 扩展:集成EFK(Elasticsearch+Fluentd+Kibana)日志系统 5. **金丝雀发布与流量管理** - 技术栈:Ingress Controller(Nginx/Traefik) + Service Mesh(Istio) - 实践:通过VirtualService/DestinationRule实现灰度发布 - 扩展:结合HPA(Horizontal Pod Autoscaler)实现自动扩缩容 6. **混合云部署实践** - 技术栈:Kubernetes Cluster API + 跨云网络方案(Calico/VXLAN) - 收获:掌握多集群管理、跨云服务发现、统一配置管理 --- ### **三、进阶项目(深入架构设计)** 7. **开发自定义Operator** - 技术栈:Operator SDK/Kubebuilder + CRD(Custom Resource Definition) - 场景案例:实现MySQL集群自动化运维(备份/故障转移) - 收获:理解K8s扩展机制、控制器模式、Reconcile循环 8. **Serverless框架实践** - 技术栈:Knative/OpenFaaS + Eventing系统 - 实践:部署函数计算服务,实现事件驱动架构(如文件上传触发缩略图生成) 9. **边缘计算场景落地** - 技术栈:K3s/KubeEdge + MQTT协议 - 挑战:解决弱网络环境下的节点通信、边缘设备管理 --- ### **四、企业级综合项目(真实场景复现)** 10. **电商微服务架构** - 技术栈:Spring Cloud + Istio + Redis Cluster - 关键实践:服务网格流量管理、分布式事务处理、熔断降级策略 11. **AI/ML工作流调度** - 技术栈:Kubeflow + Argo Workflows + GPU资源调度 - 场景:实现分布式模型训练、推理服务自动伸缩 12. **安全加固实践** - 技术栈:OPA(Open Policy Agent) + NetworkPolicy + RBAC - 实施:零信任网络策略、Pod安全上下文配置、敏感数据加密 --- ### **五、学习资源推荐** 1. **官方项目库**:Kubernetes GitHub官方示例(`kubernetes/examples`) 2. **动手实验室**:Katacoda、Play with Kubernetes(免费在线沙箱) 3. **开源项目参考**: - 微服务案例:https://github.com/googlecloudplatform/microservices-demo - 生产级集群配置:https://github.com/kubernetes-sigs/kubespray **学习建议**:每个项目务必配合以下操作: 1. 手写YAML文件(避免直接复制) 2. 通过`kubectl describe`和`kubectl logs`排查问题 3. 绘制架构图理清组件关系 4. 尝试破坏性测试(如删除Pod/节点断电)观察系统自愈能力
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值