Help us learn about your current experience with the documentation. Take the survey.

在 Kubernetes 集群中使用 GitOps

  • Tier: Free, Premium, Ultimate
  • Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated

GitLab 集成了 Flux 来实现 GitOps。 要开始使用 Flux，请参阅 Flux for GitOps 教程。

通过 GitOps，你可以从 Git 仓库管理容器化集群和应用程序，该仓库：

  • 是你系统的唯一真实来源。
  • 是你操作系统的唯一位置。

通过结合 GitLab、Kubernetes 和 GitOps，你可以获得：

  • GitLab 作为 GitOps 操作器。
  • Kubernetes 作为自动化和收敛系统。
  • GitLab CI/CD 用于持续集成。
  • 用于持续部署和集群可观测性的代理。
  • 内置的自动漂移修复功能。
  • 使用 server-side applies 进行透明多参与者字段管理的资源管理。

部署序列

此图显示了 GitOps 部署中的仓库和主要参与者：

%%{init: { "fontFamily": "GitLab Sans" }}%%
sequenceDiagram
accTitle: 部署序列
accDescr: 显示 GitOps 部署中的仓库和主要参与者。

  participant D as Developer
  participant A as Application code repository
  participant M as Deployment repository
  participant R as OCI registry
  participant C as Agent configuration repository
  participant K as GitLab agent
  participant F as Flux
  loop Regularly
    K-->>C: Grab the configuration
  end

  D->>+A: Pushing code changes
  A->>M: Updating manifest
  M->>R: Build an OCI artifact
  M->>K: Notify
  K->>F: Notify and watch sync
  R-->>F: Pulling and applying changes
  K->>M: Notify after sync

你应该同时使用 Flux 和 agentk 进行 GitOps 部署。Flux 保持集群状态与源同步，而 agentk 简化了 Flux 设置，提供集群到 GitLab 的访问管理，并在 GitLab UI 中可视化集群状态。

用于源代码控制的 OCI

你应该使用 OCI 映像作为 Flux 的源控制器，而不是 Git 仓库。GitLab 容器注册表 支持 OCI 映像。

OCI 注册表 Git 仓库
设计用于大规模提供容器映像。 设计用于版本控制和存储源代码。
不可变，支持安全扫描。 可变。
默认 Git 分支可以存储集群状态而不会触发同步。 默认 Git 分支用于存储集群状态时会触发同步。

仓库结构

为简化配置，每个团队使用一个交付仓库。 你可以将交付仓库打包为每个应用程序的多个 OCI 映像。

有关其他仓库结构建议，请参阅 Flux 文档。

即时 Git 仓库同步

通常，Flux 源控制器在配置的时间间隔内同步 Git 仓库。 这可能导致 git push 和集群状态同步之间的延迟，并导致不必要的 GitLab 拉取操作。

Kubernetes 代理会自动检测 Flux GitRepository 对象，这些对象引用代理连接到的实例中的 GitLab 项目，并为该实例配置一个 Receiver。 当 Kubernetes 代理检测到对其有权访问的仓库进行 git push 时，会触发 Receiver，Flux 会将集群与仓库的任何更改同步。

要使用即时 Git 仓库同步，你必须运行以下组件的 Kubernetes 集群：

  • Kubernetes 代理。
  • Flux source-controller 和 notification-controller。

即时 Git 仓库同步可以减少推送和同步之间的时间，但不能保证每个 git push 事件都能被接收。你仍应将 GitRepository.spec.interval 设置为可接受的持续时间。

代理只能访问代理配置项目和所有公共项目。 代理无法立即同步任何私有项目，代理配置项目除外。 允许代理访问私有项目已在 issue 389393 中提出。

自定义 Webhook 端点

当 Kubernetes 代理调用 Receiver webhook 时，代理默认使用 http://webhook-receiver.flux-system.svc.cluster.local，这也是 Flux bootstrap 安装设置的默认 URL。要配置自定义端点，请将 flux.webhook_receiver_url 设置为代理可以解析的 URL。例如：

flux:
  webhook_receiver_url: http://webhook-receiver.another-flux-namespace.svc.cluster.local

对于以这种格式配置的 服务代理 URL 有特殊处理：/api/v1/namespaces/[^/]+/services/[^/]+/proxy。例如：

flux:
  webhook_receiver_url: /api/v1/namespaces/flux-system/services/http:webhook-receiver:80/proxy

在这些情况下，Kubernetes 代理使用可用的 Kubernetes 配置和上下文连接到 API 端点。 如果你在集群外运行代理，并且没有为 Flux 通知控制器 配置 Ingress，可以使用此方法。

你应该只配置可信的服务代理 URL。 当你提供服务代理 URL 时，Kubernetes 代理会发送典型的 Kubernetes API 请求，其中包含与 API 服务身份验证所需的凭据。

令牌管理

要使用某些 Flux 功能，你可能需要多个访问令牌。此外，你可以使用多种令牌类型来实现相同的结果。

本节提供你可能需要的令牌指南，并在可能的情况下提供令牌类型建议。

Flux 访问 GitLab

要访问 GitLab 容器注册表或 Git 仓库，Flux 可以使用：

  • 项目或组部署令牌。
  • 项目或组部署密钥。
  • 项目或组访问令牌。
  • 个人访问令牌。

令牌不需要写入权限。

如果可能使用 http 访问，你应该使用项目部署令牌。 如果你需要 git+ssh 访问，你应该使用部署密钥。 要比较部署密钥和部署令牌，请参阅 部署密钥。

支持自动化部署令牌创建、轮换和报告的功能已在 issue 389393 中提出。

Flux 到 GitLab 通知

如果你配置 Flux 从 Git 源同步，Flux 可以在 GitLab 管道中注册外部作业状态。

要从 Flux 获取外部作业状态，你可以使用：

  • 项目或组部署令牌。
  • 项目或组访问令牌。
  • 个人访问令牌。

令牌需要 api 范围。为了最小化泄露令牌的攻击面，你应该使用项目访问令牌。

将 Flux 集成到 GitLab 管道中作为作业的功能已在 issue 405007 中提出。

相关主题