{{< details >}}

  • Tier: 基础版, 专业版, 旗舰版
  • Offering: JihuLab.com, 私有化部署

{{< /details >}}

{{< history >}}

  • 在极狐GitLab 15.3 中，从专业版移动至基础版。
  • 在极狐GitLab 15.7 中，id 属性变为可选。
  • 指定分支、标签或提交应用来拉取 Kubernetes 清单文件引入于极狐GitLab 15.7。
  • 在极狐GitLab 16.1 中，优先使用 Flux 进行 GitOps。

{{< /history >}}

极狐GitLab 集成 Flux 来实践 GitOps。要使用 Flux，请查看 Flux 实践 GitOps 教程。

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

  • 是你系统的单一真实来源。
  • 是你操作系统的唯一地方。

结合极狐GitLab、Kubernetes 和 GitOps，你可以拥有：

  • 极狐GitLab 作为 GitOps 操作员。
  • Kubernetes 作为自动化和收敛系统。
  • 极狐GitLab CI/CD 用于持续集成。
  • 用于持续部署和集群可观测性的代理。
  • 内置自动漂移补救。
  • 使用 服务器端应用 进行透明的多参与者字段管理的资源管理。

部署顺序

这个图展示了 GitOps 部署中的仓库和主要参与者：

%%{init: { "fontFamily": "GitLab Sans" }}%% sequenceDiagram accTitle: Deployment sequence accDescr: Shows the repositories and main actors in a GitOps deployment. 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 镜像。

立即 Git 仓库协调

{{< history >}}

  • 引入于极狐GitLab 16.1，使用名为 notify_kas_on_git_push 的特性标志。默认禁用。
  • 极狐GitLab 16.2 中，在 JihuLab.com 和私有化部署上启用。
  • 在极狐GitLab 16.3 中，功能标志被移除。

{{< /history >}}

通常，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 到一个可接受的持续时间。

{{< alert type=”note” >}}

代理仅能访问代理配置项目和所有公共项目。代理无法立即协调任何私有项目，除了代理配置项目。

{{< /alert >}}

自定义 webhook 端点

当 Kubernetes 代理调用 Receiver webhook 时，代理默认为 http://webhook-receiver.flux-system.svc.cluster.local，这也是 Flux 引导安装设置的默认 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，你可以使用这个。

{{< alert type=”warning” >}}

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

{{< /alert >}}

密钥管理

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

本节提供了你可能需要的密钥指南，并尽可能提供密钥类型建议。

Flux 通过极狐GitLab 访问

要访问极狐GitLab 容器仓库或 Git 仓库，Flux 可以使用：

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

密钥不需要写入权限。

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

Flux 到极狐GitLab 通知

如果你配置 Flux 从 Git 源同步，Flux 可以在极狐GitLab 流水线中注册外部作业状态。

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

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

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