---

深度解析 GitLab MCP：拥抱 GitOps，构建高效可靠的多集群管理平台

随着云原生技术的飞速发展，Kubernetes 已成为容器编排的事实标准。越来越多的企业将核心业务迁移到 Kubernetes 上，享受其带来的灵活性和可伸缩性。然而，当业务规模不断扩大、应用部署场景日益复杂时，管理单个 Kubernetes 集群往往难以满足需求。出于高可用性、灾难恢复、地域分布、隔离需求、混合云/多云策略、合规性要求等多种因素的考虑，企业不可避免地会走向多集群架构。

管理多个 Kubernetes 集群并非易事。每个集群可能有不同的配置、不同的安全策略、不同的网络环境。如何保持集群之间的一致性？如何安全高效地向不同集群部署应用？如何统一监控和治理这些分散的资源？这些都是多集群管理带来的巨大挑战。传统的基于脚本或手动操作的方式，不仅效率低下，而且容易出错，难以应对复杂环境下的管理需求。

正是在这样的背景下，统一的多集群管理解决方案变得至关重要。GitLab，作为一体化的 DevOps 平台领导者，自然不会忽视这一领域的需求。GitLab 的多集群管理平台（Multi-Cluster Management Platform, MCP）应运而生，它并非一个独立的模块或产品，而是 GitLab 核心功能——Git、CI/CD、Registry、Infrastructure 等——在多集群场景下的自然延伸和有机整合。其核心理念是拥抱 GitOps，将 Git 仓库作为所有集群状态和配置的唯一事实来源，并通过自动化 agent 实现集群状态与 Git 仓库声明状态的同步。

本文将带您深入了解 GitLab MCP 是什么，它如何帮助您有效地管理多个 Kubernetes 集群，以及如何入门使用 GitLab 构建您的多集群管理平台。

第一章：为什么需要多集群管理？挑战与场景

在深入 GitLab MCP 之前，我们首先需要明确，为什么企业会需要管理多个 Kubernetes 集群，以及这样做会带来哪些挑战。理解这些需求和痛点，有助于我们更好地 appreciating GitLab 的解决方案。

1. 多集群的典型应用场景

• 高可用性与灾难恢复 (HA/DR): 在不同的地理区域或可用区部署多个集群，当一个集群发生故障或面临灾难时，流量可以快速切换到其他健康的集群，确保业务的连续性。
• 地域分布与边缘计算: 将应用部署到离用户更近的边缘集群，减少延迟，提升用户体验。这在物联网、游戏、CDN 等领域尤为常见。
• 环境隔离: 为开发、测试、预生产、生产等不同环境使用独立的集群。这样可以避免不同环境之间的相互影响，提高稳定性和安全性。例如，生产集群通常有更严格的安全策略和更强的资源保证。
• 合规性与数据本地化: 某些法规要求特定类型的数据必须存储在特定的地理区域。通过在不同地区部署集群，可以确保数据存储和处理满足合规性要求。
• 混合云与多云策略: 企业可能需要在自建数据中心的私有云集群和公共云提供商（AWS EKS, GKE, Azure AKS 等）的托管集群之间进行部署。多云策略可以避免供应商锁定，并利用不同云厂商的优势服务。
• 组织结构与职责分离: 大型组织可能将集群管理职责分散给不同的团队或业务单元。每个团队管理自己的集群，但可能需要一个统一的平台来进行应用部署和治理。
• 资源限制与规模扩展: 单个集群存在规模限制（节点数、Pod 数上限）。当业务规模超出单个集群的处理能力时，需要通过增加集群来扩展。
• 新技术试验与版本升级: 在独立的集群中试验新的 Kubernetes 版本、新的操作系统或新的运行时，可以降低对现有生产环境的影响。

2. 多集群管理带来的挑战

尽管多集群架构能够解决上述问题，但也引入了新的复杂性：

• 配置一致性 (Configuration Drift): 手动配置多个集群极易导致它们之间的配置不一致，这会带来运维难题和潜在的故障隐患。
• 应用部署复杂度: 如何将同一个应用版本部署到多个集群，并确保部署过程的一致性和可靠性？如何管理不同集群的应用配置差异？
• 可见性与监控: 如何统一查看所有集群的状态、资源使用情况、应用健康状况？分散的监控系统难以提供全局视图。
• 安全管理: 如何安全地访问和管理分散在各处的集群？如何统一管理 RBAC、网络策略等安全配置？如何确保只有授权的实体能够与集群交互？
• 网络与服务发现: 跨集群的服务如何通信？如何实现全局负载均衡和服务发现？（虽然这更多是集群网络层面的挑战，但与多集群管理密切相关）。
• 复杂性与运维负担: 管理 N 个集群的复杂性通常高于管理单个集群的 N 倍，而不是简单的 N 倍。运维团队需要掌握更多工具和流程来应对多集群环境。

这些挑战促使企业寻求一种统一、自动化、安全且可扩展的多集群管理解决方案。GitLab MCP 正是为此而设计。

第二章：GitLab MCP 是什么？核心理念与组成部分

GitLab MCP 并非一个独立的软件产品，而是 GitLab 平台为解决多集群管理问题所提供的一套集成能力和推荐的工作流程。其核心在于将 GitLab 作为多集群的控制平面 (Control Plane)，并以 GitOps 作为其指导原则。

1. 核心理念：GitOps Everywhere

GitOps 的核心思想是：
1. 将所有系统的声明性配置（包括 Kubernetes Manifests, Helm Charts, Kustomize overlays 等）存储在 Git 仓库中，Git 成为系统状态的唯一事实来源 (Single Source of Truth)。
2. 使用自动化进程（Agent）持续监控 Git 仓库，当检测到状态变更时，自动将集群的实际状态调整为与 Git 仓库中声明的状态一致。

GitLab MCP 将这一理念扩展到多集群场景。这意味着：

• 您的所有集群配置、应用程序部署文件都存储在一个或多个 GitLab 仓库中。
• 每个目标 Kubernetes 集群中都运行一个 GitLab Agent 客户端。
• 这些 Agent 客户端安全地连接回您的 GitLab 实例 (Agent Server)。
• Agent 客户端负责监听 Git 仓库中的变更，并将这些变更自动应用到其所在的集群。
• CI/CD 流水线仍然在 GitLab 中运行，但它不再需要直接通过公网访问集群的 API Server。相反，它可以安全地通过 Agent 建立的隧道与集群交互，执行部署、测试或管理任务。

这种模式有几个显著优势：

• 安全性: 集群的 API Server 不需要暴露在公网，Agent 采用拉 (Pull) 的方式从 GitLab 获取指令和配置，而不是 GitLab 主动推 (Push) 到集群，大大减少了攻击面。
• 一致性: 所有集群的状态都由 Git 仓库定义，通过 Agent 的自动化同步，可以最大程度地保证集群配置的一致性。
• 可审计性: 所有的配置变更都通过 Git 的提交记录进行，提供了完整的审计日志和版本控制能力。
• 简化 CI/CD: CI/CD 流水线与集群的交互通过安全的隧道完成，无需复杂的网络配置或凭证管理。
• 回滚能力: 如果部署出现问题，可以通过 Git 回滚提交，Agent 会自动将集群状态恢复到之前的版本。

2. GitLab MCP 的核心组成部分

GitLab MCP 主要依赖于以下几个关键组件和功能：

• GitLab 实例 (SaaS 或 Self-Managed): 作为整个平台的控制中心，提供 Git 仓库、CI/CD、用户管理、Agent Server 等核心服务。
• GitLab Agent for Kubernetes (Agentk): 这是部署在每个目标 Kubernetes 集群内的轻量级代理客户端。它是连接集群与 GitLab 平台的关键。Agentk 负责与 GitLab Agent Server 建立安全连接，接收配置同步指令，并安全地暴露 CI/CD 隧道。
• GitLab Agent Server: 运行在 GitLab 实例内部的服务，负责管理 Agentk 连接、处理来自 Agentk 的请求、并将 Git 仓库的变更通知 Agentk。
• Git 仓库 (Repositories): 存储 Kubernetes Manifests、Helm Charts、Kustomize Overlays 以及 Agent 配置文件的中心位置。您可以根据需要使用一个仓库（Monorepo）或多个仓库（Polyrepo）来组织配置。
• GitLab CI/CD: 用于构建、测试、打包应用，并触发 Agent 进行部署。通过 CI/CD 隧道，流水线可以直接运行 kubectl 或 Helm 命令与目标集群交互。
• Agent Configuration File (config.yaml): 存储在 Git 仓库中的 YAML 文件，用于配置特定的 Agent 实例，指定它应该同步哪些 Git 仓库的哪些路径，以及哪些 GitLab 项目或群组可以通过该 Agent 访问其所在的集群。

理解这几个组件之间的关系至关重要：GitLab 实例是大脑和指挥中心，Git 仓库是蓝图和状态定义，Agent 是在每个集群中的执行者和通信桥梁，而 CI/CD 则负责触发流程和执行需要与集群交互的任务。

第三章：GitLab Agent for Kubernetes：MCP 的基石

GitLab Agent for Kubernetes (Agentk) 是实现 GitLab MCP 的核心技术。它替代了传统方法中，CI Runner 需要直接通过公网或 VPN 访问集群 API Server 的方式。

1. Agentk 的架构与工作原理

Agentk 采用 C/S (Client-Server) 架构：

• Agentk Client: 一个 Kubernetes Deployment/Pod，运行在目标集群内部。它连接到 GitLab 实例上的 Agent Server。这个连接是安全的、基于 mTLS 的双向认证连接。
• Agent Server: 运行在 GitLab 实例内部的服务。它管理所有连接上来的 Agentk 客户端。

工作流程概述：

1. 您在 GitLab UI 中注册一个新的 Agent，并在一个 Git 仓库中创建一个 Agent 配置文件 (.gitlab/agents/<agent-name>/config.yaml)。
2. 您使用 agentctl 工具或 Helm chart 将 Agentk Client 部署到目标 Kubernetes 集群中，部署过程中需要提供 Agent 的注册令牌。
3. Agentk Client 启动后，通过安全的 WebSocket 连接连接到 GitLab Agent Server。
4. 您在 Agent 配置文件中指定该 Agent 应该监听哪些 Git 仓库（通过 gitops.manifest_projects 配置）。
5. 当您向这些 Git 仓库提交新的 Kubernetes Manifests 或配置变更时，GitLab Agent Server 会检测到这些变更。
6. Agent Server 通过之前建立的安全连接，通知相应的 Agentk Client 有新的配置需要同步。
7. Agentk Client 从 Git 仓库中拉取最新的配置，并使用 Kubernetes API 将其应用到集群中，确保集群状态与 Git 仓库声明的状态一致。
8. 如果您在 Agent 配置文件中启用了 ci_access 并授权了特定的 GitLab 项目或群组，CI/CD 流水线中的 Job 就可以通过 Agent Server 和 Agentk Client 建立的 CI/CD Tunnel 安全地访问集群 API。CI Job 发送的 kubectl 或 Helm 命令会通过隧道传输到 Agentk Client，Agentk Client 再在集群内部执行这些命令并将结果返回。

2. Agentk 的关键特性

• 安全连接: 基于 mTLS 的安全隧道，无需暴露 Kubernetes API Server。
• GitOps 集成: 自动将 Git 仓库中的声明性配置同步到集群。支持多种配置管理工具（原生 Manifests, Kustomize, Helm）。
• CI/CD Tunnel: 提供安全的通道，允许 GitLab CI/CD Job 与集群交互，无需复杂的网络配置或在 CI Runner 中存储敏感凭证。
• 多集群支持: 每个集群部署一个独立的 Agentk 实例，通过各自的 Agent 配置进行管理。
• 细粒度授权: 通过 Agent 配置文件，您可以精确控制哪些 GitLab 项目或群组可以访问该 Agent 所在的集群，以及用于 GitOps 同步的仓库。
• Observability (演进中): Agentk 的未来版本将支持将集群的状态、事件、指标等信息推送回 GitLab，提供更全面的可见性（这部分功能可能还在不断完善和迭代）。

Agentk 的引入是 GitLab 在多集群管理方面迈出的重要一步，它解决了安全和连接性问题，并为基于 GitOps 的自动化部署和管理奠定了基础。

第四章：基于 Git 的多集群配置组织结构

在 GitLab MCP 中，Git 仓库是核心。如何有效地组织存储在 Git 仓库中的多集群配置，是实现高效管理的关键。没有一个放之四海而皆准的完美方案，但通常可以归结为以下几种模式：

1. 单仓库模式 (Monorepo)

将所有集群的所有配置都存储在一个大型 Git 仓库中。

• 优点:
  • 所有配置集中存放，便于查找和管理。
  • 更容易实现跨集群的配置共享（例如，基础服务、CRD 定义）。
  • 原子性变更：一次提交可以包含针对多个集群的联动变更。

• 缺点:

  • 仓库体积可能变得非常庞大。
  • 访问控制可能不够灵活（难以只给特定团队访问部分集群配置的权限）。
  • CI/CD 流水线可能变得复杂，需要精确过滤哪些变更应该触发哪些集群的部署。

• 推荐结构: 通常使用目录结构来区分不同集群或环境的配置。
  kubernetes-configs/
├── agents/ # Agent 配置目录
│ ├── prod-us-west/
│ │ └── config.yaml # prod-us-west 集群的 Agent 配置
│ ├── staging-eu-central/
│ │ └── config.yaml # staging-eu-central 集群的 Agent 配置
│ └── ...
├── clusters/ # 集群配置目录
│ ├── prod-us-west/
│ │ ├── base/ # 基础配置 (可能用 Kustomize/Helm)
│ │ │ ├── deployment.yaml
│ │ │ └── service.yaml
│ │ └── overlays/ # 环境特定覆盖 (用 Kustomize)
│ │ └── app-a/
│ │ ├── kustomization.yaml
│ │ └── replica-patch.yaml
│ ├── staging-eu-central/
│ │ ├── base/
│ │ └── overlays/
│ │ └── app-a/
│ │ ├── kustomization.yaml
│ │ └── resource-patch.yaml
│ └── ...
├── shared/ # 共享配置 (CRDs, Namespaces, RBAC etc.)
│ └── namespace-definitions/
│ └── production-namespaces.yaml
└── README.md
  在这种结构下，每个 Agent 的 config.yaml 文件中的 gitops.manifest_projects 部分会指向 clusters/<cluster-name>/ 或其子目录。共享配置可以被多个 Agent 引用。

2. 多仓库模式 (Polyrepo)

为每个集群、每个环境，或者每组相关的应用/配置使用独立的 Git 仓库。

• 优点:
  • 仓库规模小，管理简单。
  • 访问控制灵活，可以为不同仓库设置不同的权限。
  • CI/CD 流水线更简单，变更只影响特定仓库关联的集群。

• 缺点:

  • 难以实现跨集群的配置共享（需要通过 submodule, artifact 或复制粘贴）。
  • 需要管理更多的仓库。
  • 跨多个集群的联动变更需要协调多个仓库的提交。

• 推荐结构:
  “`
  # Repository 1: cluster-configs-prod-us-west
  prod-us-west-configs/
  ├── .gitlab/
  │ └── agents/
  │ └── prod-us-west/
  │ └── config.yaml # Agent 配置 (这个 Agent 会监听当前仓库)
  ├── applications/
  │ └── app-a/
  │ ├── deployment.yaml
  │ └── service.yaml
  ├── infrastructure/ # Cluster specific infrastructure like storageclasses
  └── README.md

  Repository 2: cluster-configs-staging-eu-central

  staging-eu-central-configs/
  ├── .gitlab/
  │ └── agents/
  │ └── staging-eu-central/
  │ └── config.yaml # Agent 配置 (这个 Agent 会监听当前仓库)
  ├── applications/
  │ └── app-a/
  │ ├── deployment.yaml # Staging specific config
  │ └── service.yaml
  └── README.md

  Repository 3: shared-k8s-manifests (optional, for reusable components)

  shared-manifests/
  ├── base-app-template/
  │ ├── deployment.yaml
  │ └── service.yaml
  └── crds/
  └── prometheus.crd.yaml
  ``
在这种模式下，每个集群的 Agentconfig.yaml会配置gitops.manifest_projects` 来指向其对应的仓库。如果需要共享配置，可以考虑将共享部分放在一个单独的仓库中，并在其他仓库中将其添加为 submodule，或者使用 CI/CD 将共享配置作为 artifact 部署到所有相关集群（通过各自 Agent 的 CI/CD 隧道）。

3. 混合模式

结合 Monorepo 和 Polyrepo 的优点。例如，将所有基础平台配置（CRDs, Namespaces, RBAC）放在一个 Monorepo 中由平台团队管理，而将应用部署相关的配置放在各个应用团队自己的仓库中。每个 Agent 配置可以同时引用平台仓库和应用仓库。

• Agent 配置 (config.yaml) 示例:
  “`yaml
  gitops:
  # 这个 Agent 会监听当前仓库的 /manifests 目录
  manifest_projects:
  – id: 123 # 当前仓库ID
  paths:
  – glob: /manifests//.yaml
  # 也可以引用其他仓库
  – id: 456 # 共享平台配置仓库ID
  paths:
  – glob: /shared-crds/.yaml
  – glob: /base-namespaces/*.yaml

  ci_access:
  projects:
  – id: 789 # 允许 ID 为 789 的项目通过此 Agent 访问集群
  – id: 101 # 允许 ID 为 101 的项目通过此 Agent 访问集群
  # 或者允许整个群组访问
  groups:
  – id: 202 # 允许 ID 为 202 的群组下的所有项目通过此 Agent 访问集群
  “`

选择哪种组织结构取决于您的团队规模、组织结构、安全要求、配置的共享程度以及对仓库复杂度的接受程度。对于入门来说，从简单的 Polyrepo 或小规模 Monorepo 开始可能是个不错的选择。

第五章：多集群管理入门实践：使用 GitLab Agent

本章将提供一个逐步指南，介绍如何在 GitLab 中配置 Agent，并将其部署到多个 Kubernetes 集群，实现基本的 GitOps 同步和 CI/CD 部署。

前提条件:

1. 一个可用的 GitLab 实例（SaaS 或 Self-Managed 14.0+，推荐较新版本以获得 Agent 的完整功能）。
2. 至少两个 Kubernetes 集群（可以是任何类型，例如 Minikube, kind, EKS, GKE, AKS, 自建集群等）。
3. 在本地机器上安装 kubectl 命令行工具，并且能够连接到您的目标 Kubernetes 集群（用于安装 Agentk 客户端）。
4. 安装 GitLab Agent CLI 工具 agentctl：请参考 GitLab 官方文档进行安装。

步骤 1: 在 GitLab 中创建 Agent 项目和配置文件

您需要在 GitLab 中创建一个专门用于存放 Agent 配置文件的项目。这个项目通常被称为 “Agent 配置仓库” 或 “GitOps 配置仓库”。

1. 在 GitLab 中创建一个新的空白项目 (New project -> Create blank project)。命名可以类似于 kubernetes/agents 或 my-gitops-configs。
2. 在该项目中，创建一个目录结构来存放 Agent 的配置文件。推荐的结构是 .gitlab/agents/<agent-name>/config.yaml。<agent-name> 应该是对您要连接的集群有意义的名称，例如 prod-us-east-1 或 staging-gke-europe-central-2。

3. 在 <agent-name> 目录下创建 config.yaml 文件。这是一个基本的 Agent 配置示例：

   “`yaml

   .gitlab/agents/prod-us-east-1/config.yaml

   gitops:
   # 这个 Agent 将监控同一个仓库的 /manifests/prod 目录
   # 当这个目录下的文件发生变化时，Agent 会自动应用这些变化到它所在的集群
   manifest_projects:
   – id: $CI_PROJECT_ID # 使用预定义变量指向当前 Agent 配置所在的仓库
   paths:
   – glob: /manifests/prod//*.yaml # 监控 manifests/prod 目录下的所有yaml文件
   – glob: /manifests/shared//*.yaml # 也可以监控共享目录

   ci_access:
   projects:
   # 允许 ID 为 <您的应用项目ID> 的项目通过此 Agent 访问集群
   – id: # 替换为实际的应用项目ID
   ``
**注意:**
*$CI_PROJECT_ID是一个 GitLab CI/CD 预定义变量，但在这里它直接表示 Agent 配置文件所在的这个 Git 仓库的项目 ID。在创建 Agent 时，GitLab 会知道这个文件属于哪个项目，并关联起来。
*` 是您的应用程序代码所在的 GitLab 项目的 ID。您可以在该项目的设置页面找到。

4. 提交并推送这个 config.yaml 文件到您的 Agent 配置仓库。

步骤 2: 在 GitLab UI 中注册 Agent

现在您已经在 Git 仓库中定义了 Agent 的配置，接下来需要在 GitLab UI 中正式注册它。

1. 导航到您的 Agent 配置仓库项目页面。
2. 在左侧菜单中，找到 Infrastructure -> Kubernetes clusters。
3. 点击 Connect a cluster。
4. 选择 GitLab Agent。
5. 选择您刚刚创建的 Agent 配置文件所在的仓库和分支。GitLab 会自动检测到 .gitlab/agents/ 目录下的 Agent 配置。选择您要注册的 <agent-name>（例如 prod-us-east-1）。
6. GitLab 会显示用于安装 Agentk 客户端的命令和令牌。复制提供的 agentctl 安装命令。这个命令包含了连接所需的 Agent ID 和注册令牌。

步骤 3: 在目标 Kubernetes 集群中安装 Agentk 客户端

使用上一步骤中复制的 agentctl 命令，在您的目标 Kubernetes 集群中安装 Agentk。确保您的 kubectl 已经配置为指向正确的集群。

1. 打开终端，并确保您可以连接到目标集群（例如，通过运行 kubectl get nodes）。
2. 粘贴并运行 GitLab UI 中提供的 agentctl 安装命令。该命令通常看起来像这样：
   bash
agentctl install --agent-id <agent-id> --token <token> --gitlab-kas-address <gitlab-kas-url>
   • <agent-id> 和 <token> 是 GitLab 生成的唯一标识符和令牌。
   • <gitlab-kas-url> 是 GitLab Agent Server (KAS) 的地址。对于 GitLab.com，这是 wss://kas.gitlab.com。对于 Self-Managed 实例，需要配置 KAS 并使用您的 URL。
3. agentctl 会创建一个 gitlab-agent Namespace，并在其中部署 Agentk Deployment、Service Account、ClusterRolebinding 等资源。
4. 等待 Agentk Pod 启动并成功连接到 GitLab。您可以通过 kubectl get pods -n gitlab-agent 查看 Pod 状态，并通过 kubectl logs -n gitlab-agent <agentk-pod-name> 查看日志。
5. 回到 GitLab UI 中的 Agent 页面 (Infrastructure -> Kubernetes clusters -> Agents 列表)，您应该能看到您注册的 Agent 状态变为绿色或“Connected”。

步骤 4: 配置 GitOps (部署 Manifests)

现在 Agent 已经连接成功，我们可以利用它来自动同步 Git 仓库中的配置。

1. 在您的 Agent 配置仓库中（或者在 config.yaml 中配置的任何其他仓库），创建一个目录来存放您的 Kubernetes Manifest 文件，例如 manifests/prod/。

2. 在该目录下添加一些 YAML Manifest 文件，例如一个简单的 Nginx Deployment 和 Service：

   “`yaml

   manifests/prod/nginx.yaml

   apiVersion: apps/v1
   kind: Deployment
   metadata:
   name: nginx-deployment-prod
   namespace: default # 根据需要修改命名空间
   spec:
   replicas: 2
   selector:
   matchLabels:
   app: nginx
   template:
   metadata:
   labels:
   app: nginx
   spec:
   containers:
   – name: nginx
   image: nginx:latest
   ports:
   – containerPort: 80

   ---

   apiVersion: v1
   kind: Service
   metadata:
   name: nginx-service-prod
   namespace: default # 根据需要修改命名空间
   spec:
   selector:
   app: nginx
   ports:
   – protocol: TCP
   port: 80
   targetPort: 80
   type: LoadBalancer # 根据需要修改服务类型
   ``
3. 确保您的 Agent 配置 (.gitlab/agents//config.yaml) 中的gitops.manifest_projects部分正确指向包含这些文件的路径（例如，使用glob: /manifests/prod/*/.yaml）。
4. 提交并推送这些 Manifest 文件到 Git 仓库。
5. Agentk 会自动检测到 Git 仓库的变更，并自动将这些 Manifest 应用到它所在的集群。
6. 您可以通过kubectl get pods -n default -l app=nginx和kubectl get service -n default nginx-service-prod` 在集群中验证 Nginx Pod 和 Service 是否已被创建。

至此，您已经成功地通过 GitLab Agent 实现了 GitOps 风格的配置同步。对 manifests/prod/ 目录下的文件进行的任何 Git 提交，都会自动反映到集群中。

5. 配置 CI/CD 部署 (通过 Agent Tunnel)

除了自动同步，您还可以通过 Agent 的 CI/CD Tunnel 在 GitLab CI/CD 流水线中安全地与集群交互。

1. 在您的应用程序项目（即您在 Agent 配置的 ci_access.projects 或 ci_access.groups 中授权的项目或群组）中，创建或修改 .gitlab-ci.yml 文件。

2. 定义一个 CI Job，使用 Agent 来执行 kubectl 命令。以下是一个示例：

   “`yaml

   .gitlab-ci.yml in your application project

   variables:
   # 定义目标集群使用的 Agent 名称
   KUBERNETES_KUBECONFIG_FILE: /tmp/kubeconfig # Agent tunnel 会将kubeconfig放在这里

   deploy_to_prod:
   stage: deploy
   image: registry.gitlab.com/gitlab-org/cluster-integration/cluster-applications/kubectl:latest # 使用包含kubectl的镜像
   script:
   – echo “Deploying to production cluster via GitLab Agent…”
   # 使用 kubectl 命令，这些命令将通过 Agent tunnel 执行
   – kubectl –kubeconfig /tmp/kubeconfig rollout status deployment/nginx-deployment-prod -n default –timeout=5m
   # 假设您想从应用项目部署一个特定的应用 manifest
   # 您可以从应用项目仓库中包含 manifest，或者从 artifact 中获取
   # – kubectl –kubeconfig /tmp/kubeconfig apply -f path/to/your/app-manifest.yaml -n default
   # 指定使用哪个 Agent 连接到目标集群
   # 格式为 ‘agents::‘
   # 是 Agent 配置仓库在GitLab中的路径 (群组/项目名称)
   # 是 Agent 配置文件的目录名 (.gitlab/agents//config.yaml 中的 )
   environment: # 将此 job 与特定的部署环境关联
   name: production/prod-us-east-1 # 推荐格式 environment_tier/cluster_name
   kubernetes:
   namespace: default # 可选: 指定job默认操作的命名空间
   agent:
   project: # 替换为您的 Agent 配置仓库路径
   name: prod-us-east-1 # 替换为您的 Agent 名称

   您可以为另一个集群定义另一个 Job

   deploy_to_staging:
   stage: deploy
   image: registry.gitlab.com/gitlab-org/cluster-integration/cluster-applications/kubectl:latest
   script:
   – echo “Deploying to staging cluster via GitLab Agent…”
   – kubectl –kubeconfig /tmp/kubeconfig rollout status deployment/nginx-deployment-staging -n default –timeout=5m
   # … staging specific deployment steps …
   environment:
   name: staging/staging-eu-central-2
   kubernetes:
   namespace: default
   agent:
   project: # 替换为您的 Agent 配置仓库路径
   name: staging-eu-central-2 # 替换为您的另一个 Agent 名称 (需要先注册和安装)

   ``
**注意:**
* 在 CI Job 中使用 Agent 的关键在于environment: kubernetes: agent:配置块。它告诉 GitLab CI 这个 Job 需要连接到哪个 Agent。
* GitLab CI 会自动通过 Agent tunnel 为您创建一个临时的 kubeconfig 文件，并将其路径设置在$KUBERNETES_KUBECONFIG_FILE变量中（或者您可以自定义变量名）。您需要在kubectl命令中显式使用–kubeconfig $KUBERNETES_KUBECONFIG_FILE。
*environment: name:` 的值用于在 GitLab UI 的 Environments 页面中显示部署状态。

3. 提交并推送您的 .gitlab-ci.yml 文件。

4. GitLab CI 会运行流水线，当执行到使用了 Agent 的 Job 时，它会通过 Agent tunnel 安全地连接到目标集群并执行 kubectl 命令。

步骤 6: 添加更多集群

要添加另一个集群（例如 Staging 集群），您只需重复上述步骤：

1. 在您的 Agent 配置仓库的 .gitlab/agents/ 目录下，为新的集群创建一个新的子目录和 config.yaml 文件（例如 .gitlab/agents/staging-eu-central-2/config.yaml）。配置其 gitops 和 ci_access 部分，指向 Staging 环境相关的 Manifest 路径和授权的应用项目。
2. 在 GitLab UI 中注册新的 Agent，选择 staging-eu-central-2 配置。
3. 在您的 Staging Kubernetes 集群中安装 Agentk 客户端，使用新 Agent 的安装命令。
4. 在 Agent 配置仓库中创建 Staging 环境的 Manifest 文件（例如 manifests/staging/），并提交。Staging Agent 会自动同步这些配置到 Staging 集群。
5. 在您的应用程序项目的 .gitlab-ci.yml 中，添加或修改 Job，使用新的 Staging Agent 进行部署（如步骤 5 示例所示）。

通过这种方式，您可以轻松地将任意数量的集群纳入 GitLab 的统一管理之下。

第六章：GitLab MCP 的优势与价值

采用 GitLab MCP 进行多集群管理，可以为组织带来诸多益处：

• 一体化的 DevOps 体验: GitLab 提供从代码提交、CI/CD、到容器注册表、再到多集群部署和管理的端到端平台。无需集成多个独立工具，降低了复杂性和运维成本。
• 强大的 GitOps 能力: 将 Git 作为核心，提供了卓越的配置一致性、可审计性、可回滚性和自动化能力，显著提升了运维效率和可靠性。
• 增强的安全性: Agent 的拉取模式和安全隧道消除了暴露集群 API Server 的风险，为多集群环境提供了更强的安全保障。
• 简化的 CI/CD 流程: CI/CD Job 与集群的安全交互通过 Agent Tunnel 完成，无需复杂的网络配置和凭证分发。流水线定义更简洁，更容易维护。
• 高效的配置管理: 结合 Git 的版本控制和分支策略，可以轻松管理不同环境、不同集群的配置差异。配合 Kustomize 或 Helm，可以实现配置的复用和定制。
• 可扩展性: Agent 架构天生具有可扩展性，您可以随着集群数量的增加，简单地为每个新集群部署一个 Agent 即可。
• 更好的协作: 开发者、运维工程师、SREs 都在同一个平台上工作，围绕 Git 仓库进行协作，提高了团队效率和沟通透明度。

第七章：进阶主题与展望

本文重点介绍了 GitLab MCP 的基础概念和入门实践。多集群管理是一个复杂的话题，还有许多进阶主题值得探索：

• 高级配置管理: 深入使用 Kustomize 的 overlays 实现不同环境的配置定制，或使用 Helm Charts 及其 values 文件来管理应用的部署配置，并将这些配置也存储在 Git 中由 Agent 同步。
• Secrets Management: 如何在多集群环境中安全地管理敏感信息？可以考虑使用 GitLab 的 CI/CD 变量配合 Agent Tunnel 将 secrets 安全注入集群，或者使用外部 Secrets Manager（如 HashiCorp Vault, AWS Secrets Manager）并集成到 GitOps 工作流中。
• 跨集群服务发现与网络: 虽然 Agent 本身不提供跨集群网络解决方案，但在多集群环境下，您可能需要 Service Mesh (Istio, Linkerd) 或多集群 DNS 等技术来解决服务间通信问题。
• 策略即代码 (Policy as Code): 使用 OPA/Gatekeeper 等工具，配合 Agent 的 GitOps 同步能力，在集群中 enforce 安全、合规性等策略。
• 多集群 Observability: 整合来自不同集群的日志、指标和追踪数据，构建统一的监控和可视化平台（例如使用 Prometheus Federated 或 Thanos）。GitLab Agent 的未来版本也可能会提供更多 Observability 能力。
• GitLab Agent 的更多功能: Agent 不仅支持 GitOps 同步和 CI/CD Tunnel，未来还将集成更多的集群管理功能，例如集群安全扫描、资源报告等。

结论

多集群管理是现代云原生架构不可回避的挑战。GitLab MCP 通过将强大的 DevOps 平台能力与 GitOps 理念相结合，提供了一个统一、安全、高效的解决方案。核心在于将 Git 仓库作为所有集群配置的唯一事实来源，并利用轻量级的 Agent 在每个集群中实现自动化同步和安全访问。

从注册 Agent、安装 Agentk 客户端，到配置 GitOps 同步和利用 CI/CD Tunnel 进行部署，入门使用 GitLab MCP 相对直观。随着您对多集群管理需求的深入，可以逐步探索高级配置管理、安全性、监控等更复杂的议题。

拥抱 GitLab MCP，意味着您正在构建一个基于 Git、自动化、安全可靠的多集群管理平台，这将极大地提升您的运维效率，降低风险，并更好地支持您的业务发展。立即在您的 GitLab 实例中开始尝试 Agent for Kubernetes 吧，开启您的多集群管理新篇章！

---