DevOps全链路实战 | 第 1 天：全链路架构总览：从代码提交到灰度发布的完整管道设计

第 1/18 天

引言：为什么需要 DevOps 全链路实战？

在现代软件工程中，”DevOps”已经不再只是一个口号或工具清单，而是从代码提交到生产发布的完整工程化闭环。本系列「DevOps全链路实战」共 18 篇文章，将带你从零开始搭建一条可运行的 DevOps 管道：从 GitLab CE 代码托管 → GitLab CI 自动构建 → Harbor 私有镜像仓库 → Argo CD GitOps 持续部署 → Prometheus/Grafana 可观测性 → Argo Rollouts 渐进式交付，最终实现代码提交 → 自动构建 → 灰度发布 → 实时监控 → 自动告警 → 一键回滚的全自动闭环。

本系列目标读者：具备 K8s 基础知识的开发者、运维工程师，以及希望系统性地掌握现代 DevOps 流水线的技术负责人。每篇文章都包含可落地的 YAML 配置、Helm 命令和实战步骤，你可以按顺序跟进，最终获得一条完整的生产级 DevOps 管道。

核心概念：全链路架构总览

整体架构分层

一个完整的 DevOps 全链路管道可以分为 6 个层次，每一层都对应本系列中的若干篇内容：

数据流与管道流向

下图描述了一次典型的代码发布流程中，数据如何在各层之间流动：

代码仓库              镜像仓库             部署集群              可观测平台
(GitLab CE)        (Harbor)           (K8s + Argo CD)      (Prometheus+Grafana)
    │                  │                    │                      │
    │ ① Push代码       │ ② CI构建推送       │ ③ 镜像拉取+部署       │ ④ 指标采集+看板
    └──────────────────┴────────────────────┴──────────────────────┘

关键设计原则

本系列遵循以下设计原则，确保管道在生产环境中的可靠性和可维护性：

1. GitOps 优先：所有部署操作最终都通过 Git 仓库中的声明式配置驱动（Argo CD 同步），杜绝手动 kubectl apply。
2. 不可变基础设施：K8s 集群组件使用 Helm Chart 安装，不手动修改配置。
3. 渐进式交付：所有发布默认走金丝雀（canary）策略，先对 10% 流量发布，验证健康后逐步放量。
4. 可观测性先行：在发布之前就已准备好监控面板和告警规则，确保故障可以在秒级被发现。
5. 闭环回滚：当告警触发或指标分析失败时，Argo Rollouts 自动执行回滚，无需人工介入。

实战步骤：设计你的全链路管道

Step 1：规划集群拓扑

假设我们有 3 个 K8s 节点（1 Master + 2 Worker），硬件配置如下：

网络规划：Master 使用 10.0.0.10/24，Worker 使用 10.0.0.21/24 和 10.0.0.22/24。K8s 使用 Calico/Cilium CNI 做 Pod 网络，Ingress 使用 Nginx Ingress Controller。

# 所有节点的 /etc/hosts 配置（示例）
10.0.0.10  master-01
10.0.0.21  worker-01
10.0.0.22  worker-02

Step 2：基础设施组件的部署顺序

全链路管道中组件的部署存在严格依赖关系，本系列按以下顺序逐步搭建：

Day 1  架构总览（本篇）
Day 2  K8s 集群搭建（kubeadm + Cilium）
Day 3  Harbor 私有镜像仓库
Day 4  GitLab CE 自托管
Day 5  GitLab Runner 配置
Day 6  GitLab CI 流水线
Day 7  Harbor Tag 策略
Day 8  Argo CD GitOps
Day 9  CI-CD 联动
Day 10 Prometheus 指标采集
Day 11 Grafana 看板
Day 12 Alertmanager 告警
Day 13 Argo Rollouts 安装
Day 14 金丝雀发布实战
Day 15 AnalysisTemplate 自动回滚
Day 16 端到端全链路演示
Day 17 生产化加固
Day 18 供应链安全闭环

Step 3：编写 .gitlab-ci.yml 管道模板

在 Day 1 阶段，我们先编写一个”骨架”版本的 .gitlab-ci.yml，后续各篇章会逐步完善其内容。这是整个 CI/CD 管道的中枢配置：

# .gitlab-ci.yml — DevOps 全链路管道模板（骨架版）
stages:
  - build
  - test
  - scan
  - push
  - deploy
  - release

variables:
  REGISTRY: harbor.stellardata.top
  IMAGE_NAME: myapp
  TAG: $CI_COMMIT_SHORT_SHA
  DOCKER_USERNAME: $HARBOR_USER
  DOCKER_PASSWORD: $HARBOR_PASS

build-image:
  stage: build
  image:
    name: gcr.io/kaniko-project/executor:latest
    entrypoint: [""]
  script:
    - echo "Building Docker image..."
    - /kaniko/executor
      --context=.
      --dockerfile=Dockerfile
      --destination=$REGISTRY/$IMAGE_NAME:$TAG
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'

unit-test:
  stage: test
  image: python:3.11-slim
  script:
    - pip install pytest
    - pytest --tb=short -q
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'

trivy-scan:
  stage: scan
  image: aquasec/trivy:latest
  script:
    - trivy image --severity HIGH,CRITICAL --exit-code 1 $REGISTRY/$IMAGE_NAME:$TAG
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'

deploy-canary:
  stage: deploy
  image: argocd/argocd:latest
  script:
    - echo "Deploying canary via Argo Rollouts..."
    - kubectl apply -f manifests/deploy.yaml
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'
    - if: '$CI_COMMIT_TAG =~ /^v[0-9]+/'

注意：上述配置在第 1 天仅作为架构设计参考，实际可用配置将在第 6-9 天中逐段完善。Kaniko 构建在第 6 天详细讲解，Argo CD 部署在第 8-9 天展开，金丝雀发布在第 13-14 天实现。

Step 4：Argo CD Application 模板

GitOps 的核心是 Argo CD 的 Application 资源。以下是我们后续将使用的声明式部署模板（第 8 天会完整讲解）：

# gitops-app/app-myapp.yaml — Argo CD Application
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: myapp
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://gitlab.stellardata.top/devops/myapp.git
    targetRevision: main
    path: manifests/
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true

Step 5：Prometheus ServiceMonitor 指标采集框架

可观测性的基础是服务暴露指标端点。这是后续第 10-12 天要实现的框架：

# monitoring/service-monitor-myapp.yaml
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: myapp-metrics
  namespace: monitoring
  labels:
    release: kube-prometheus-stack
spec:
  selector:
    matchLabels:
      app: myapp
  endpoints:
    - port: metrics
      path: /metrics
      interval: 30s

常见问题（FAQ）

Q1：我已经用了 Jenkins + K8s，为什么还要切换 Argo CD？

Jenkins 擅长复杂编排和手动触发，但缺乏声明式状态同步能力。Argo CD 的核心价值在于 GitOps 一致性：集群状态与 Git 仓库中的期望状态始终一致，任何手动修改都会被自动纠正（selfHeal）。如果你需要严格的审计追踪和 Git 驱动的自动化部署，Argo CD 是更好的选择。本系列也会在第 9 天展示 GitLab CI（作为 CI 触发器）+ Argo CD（作为 CD 执行器）的联动方案，兼容现有 CI 投资。

Q2：为什么选 Kaniko 而不是 Docker-in-Docker？

Docker-in-Docker 需要特权容器（privileged: true），在安全敏感环境中有风险。Kaniko 是 Google 开源的无守护进程构建工具，通过模拟 Docker build 过程直接在 rootfs 中构建镜像，不需要 Docker Daemon，也不需要特权权限。在 GitLab Runner 的 K8s Executor 环境下（第 5-6 天），Kaniko 是主流推荐方案。

Q3：全链路搭建需要多长时间？硬件成本如何？

本系列假设 3 节点 K8s 集群（见 Step 1 配置），使用开源软件全部自托管。在 4C8GB 的机器上，Harbor + GitLab CE + Argo CD + Prometheus + Grafana + Argo Rollouts 全部运行约需 60GB 磁盘、16GB 内存。如果你使用云厂商的托管 K8s（如 ACK/EKS），成本会大幅降低，仅 GitLab CE 需要自托管。

Q4：系列文章之间可以跳着看吗？

不建议。本系列按依赖关系编排：第 2 天的 K8s 集群是 Harbor、GitLab、Argo CD 的运行基础；第 8 天的 Argo CD 是第 13 天 Argo Rollouts 的前置条件。强烈建议按顺序跟进。如果时间紧张，可以重点掌握 Day 1（架构）、Day 6（CI 流水线）、Day 9（CI-CD 联动）、Day 14（金丝雀发布）这四篇核心内容。

总结：全链路架构的设计哲学

第 1 天我们完成了全链路 DevOps 管道的架构设计工作。回顾一下核心要点：

1. 六层架构：代码管理 → 持续集成 → 镜像仓库 → 持续部署 → 可观测性 → 渐进式交付，每层各司其职。
2. GitOps 驱动：所有部署通过 Git 仓库声明，Argo CD 负责同步，确保集群状态与代码仓库一致。
3. 安全优先：Kaniko 无守护进程构建、Trivy 镜像扫描、cosign 镜像签名，安全贯穿整个管道。
4. 可观测性闭环：Prometheus 采集指标 → Grafana 可视化 → Alertmanager 告警 → Argo Rollouts 自动回滚，形成故障检测-响应闭环。
5. 渐进式交付：金丝雀发布策略 + AnalysisTemplate 自动分析，让发布风险从”全量切换”降到”逐步验证”。

下期预告

第 2 天：K8s 集群与网络基础：kubeadm 离线部署与 Cilium 网络插件

第 2 天我们将动手搭建本系列的 K8s 集群基础。内容包括：kubeadm 离线部署流程、Cilium CNI 网络插件的安装与配置、Cilium 安全策略（NetworkPolicy）实践、Pod 网络排查工具（cilium-cli）等。这是整条 DevOps 管道的运行基石，后续所有组件（Harbor、GitLab、Argo CD、Prometheus、Argo Rollouts）都依赖此集群运行。请确保你的 3 台机器已按 Step 1 的拓扑准备好。

系列目录：DevOps全链路实战

系列目录链接

• 第 1 天：全链路架构总览（← 本篇）
• 🔜 第 2 天：K8s 集群与网络基础
• 🔜 第 3 天：Harbor 私有镜像仓库部署与验证
• 🔜 第 4 天：GitLab CE 自托管部署
• 🔜 第 5 天：GitLab Runner 配置
• 🔜 第 6 天：GitLab CI 流水线搭建
• 🔜 第 7 天：Harbor 镜像版本管理与 Tag 策略配置
• 🔜 第 8 天：Argo CD 部署与 GitOps 配置仓库创建
• 🔜 第 9 天：CI 与 CD 联动
• 🔜 第 10 天：Prometheus 部署
• 🔜 第 11 天：Grafana 看板搭建
• 🔜 第 12 天：告警规则与 Alertmanager
• 🔜 第 13 天：Argo Rollouts 安装与基础概念
• 🔜 第 14 天：金丝雀发布实战
• 🔜 第 15 天：AnalysisTemplate 指标分析与自动回滚
• 🔜 第 16 天：全链路端到端演示
• 🔜 第 17 天：生产化加固要点
• 🔜 第 18 天：供应链安全闭环