3. 流水线基础：Jenkins/GitLab CI/CD 与 K8s 集成的典型架构

在 K8s 平台发布流水线中，CI/CD 工具与 Kubernetes 集群的集成深度决定了发布效率与稳定性。本章聚焦 Jenkins 与 GitLab CI/CD 两种主流方案，剖析其与 K8s 集成的典型架构、核心组件及适用场景。

3.1 集成架构总览

无论是 Jenkins 还是 GitLab CI/CD，与 K8s 集成的本质都是将 CI/CD 工具作为“控制平面”，通过 API 与 K8s 集群交互，实现构建、测试、部署的自动化。典型架构包含以下核心层：

• 代码源层：GitLab、GitHub、Bitbucket 等仓库触发流水线。
• CI/CD 引擎层：Jenkins Master/Agent 或 GitLab Runner，负责解析流水线定义并执行任务。
• 镜像构建层：通过 Docker-in-Docker (DinD) 或 Kaniko 在 K8s Pod 内构建容器镜像。
• 镜像仓库层：Harbor、Docker Registry、GitLab Container Registry 存储构建产物。
• K8s 集群层：目标集群接收部署清单，完成应用发布。

3.2 Jenkins 与 K8s 集成架构

Jenkins 通过 Kubernetes Plugin 实现动态 Agent 管理，每个构建任务在 K8s Pod 中启动临时 Agent，构建完成后自动销毁。这种“弹性 Agent”模式显著提升了资源利用率。

3.2.1 核心组件与角色

3.2.2 典型流水线流程

1. 代码推送：开发者向 Git 仓库推送代码，Webhook 触发 Jenkins Job。
2. Agent 调度：Jenkins Master 根据 Pod Template 定义，向 K8s API 请求创建 Agent Pod。
3. 构建与测试：Agent Pod 拉取代码，执行编译、单元测试、代码扫描。
4. 镜像构建：在 Agent Pod 内通过 DinD 或 Kaniko 构建容器镜像并推送至仓库。
5. 部署：Agent 执行 kubectl apply 或 Helm 命令，将更新后的镜像部署到目标 K8s 集群。
6. 清理：构建完成后，Agent Pod 自动销毁，释放资源。

pipeline {
    agent {
      kubernetes {
        yaml '''
apiVersion: v1
kind: Pod
spec:
  containers:
  - name: jnlp
    image: jenkins/inbound-agent:latest
  - name: docker
    image: docker:20.10
    command: ["cat"]
    tty: true
  - name: kubectl
    image: bitnami/kubectl:latest
    command: ["cat"]
    tty: true
'''
      }
    }
    stages {
      stage('Build & Push Image') {
        steps {
          container('docker') {
            sh 'docker build -t myapp:${BUILD_NUMBER} .'
            sh 'docker push registry.example.com/myapp:${BUILD_NUMBER}'
          }
        }
      }
      stage('Deploy to K8s') {
        steps {
          container('kubectl') {
            sh 'kubectl set image deployment/myapp myapp=registry.example.com/myapp:${BUILD_NUMBER}'
          }
        }
      }
    }
  }

3.3 GitLab CI/CD 与 K8s 集成架构

GitLab CI/CD 原生支持 K8s 集成，通过 GitLab Runner 的 Kubernetes Executor 在集群内直接运行 CI Job。相比 Jenkins，GitLab CI/CD 的流水线定义（.gitlab-ci.yml）更简洁，且与代码仓库深度绑定。

3.3.1 核心组件与角色

3.3.2 典型流水线流程

1. 代码推送：开发者推送代码至 GitLab 仓库，自动触发 Pipeline。
2. Runner 调度：GitLab Runner 检测到新 Job，通过 K8s Executor 创建 Job Pod。
3. Job 执行：Pod 内运行 .gitlab-ci.yml 定义的 stages（build、test、deploy）。
4. 镜像构建：使用 Docker-in-Docker 或 Kaniko 构建镜像，推送至 GitLab Container Registry。
5. 部署：通过 kubectl 或 GitLab CI/CD 的 environments 功能，将应用部署至目标 K8s 集群。
6. 环境清理：Job 完成后，Pod 自动删除，Runner 释放资源。

3.4 两种方案对比

3.5 集成最佳实践

• 最小权限原则：为 CI/CD 工具创建独立的 ServiceAccount，仅授予目标命名空间的最小 RBAC 权限（如 edit 角色）。
• 镜像构建安全：优先使用 Kaniko 或 BuildKit 替代 DinD，避免特权容器带来的安全风险。
• 缓存策略：利用 PVC 或分布式缓存（如 MinIO）加速依赖下载和镜像层复用，减少构建时间。
• 流水线幂等性：确保每次部署都是幂等的，避免因重试导致环境状态不一致。
• 回滚机制：在流水线中集成 Helm 或 Kustomize，利用 K8s 的 rollback 能力实现快速回退。