GitOps 与 Kubernetes 集群一起使用

  • 从专业版移动到基础版于 15.3 版本。
  • 在极狐GitLab 15.7 中,id 属性更改为可选。
  • 在极狐GitLab 15.7 中,引入了指定分支、标签或提交引用以获取 Kubernetes manifest 文件。
  • 在极狐GitLab 16.1 中,将优先使用 Flux 进行 GitOps。

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

使用 GitOps,您可以从满足以下条件的 Git 仓库管理容器化集群和应用程序:

  • 是您系统的单一可信源。
  • 是您运营系统的唯一位置。

通过结合极狐GitLab、Kubernetes 和 GitOps,您可以实现:

  • 将极狐GitLab 作为 GitOps Operator。
  • Kubernetes 作为自动化和融合系统。
  • 用于持续集成的极狐GitLab CI/C。
  • 用于持续部署和集群可观测性的代理。
  • 内置自动偏移修复。
  • 使用服务器端应用进行资源管理,用于透明的多参与者字段管理。

部署顺序

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

sequenceDiagram participant D as Developer participant A as Application code repository participant M as Manifest repository participant K as GitLab agent participant C as Agent configuration repository loop Regularly K-->>C: Grab the configuration end D->>+A: Pushing code changes A->>M: Updating manifest loop Regularly K-->>M: Watching changes M-->>K: Pulling and applying changes end

您应该在 GitOps 部署中同时使用 Flux 和 agentk。Flux 能够保持集群状态和源文件的同步,而 agentk 则简化了 Flux 的设置,提供了集群到 GitLab 的访问管理,并在极狐GitLab UI 中可视化集群状态。

OCI 的源控制

您应该将 OCI 镜像用作 Flux 的源控制器,而不是 Git 仓库。极狐GitLab 容器镜像仓库 支持 OCI 镜像。

OCI 仓库 Git 仓库
设计为容器镜像的规模化使用。 设计为源代码的版本化控制和代码存储。
不可变、支持安全扫描。 可变的。
默认的 Git 分支可以存储集群状态(无需触发同步)。 当使用存储集群状态时,默认 Git 分支会触发一次同步。

仓库结构

为了简化配置,每个团队使用一个交付仓库。您可以将交付存储库按每个应用程序打包成多个 OCI 镜像。

Git 仓库立即同步

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

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

Kubernetes 代理会自动检测引用了代理所连接实例中的 GitRepository 对象,并为实例配置一个 Receiver。当代理检测到对它有访问权限的仓库中的 git push 时,Receiver 会被触发,然后 Flux 会根据仓库中的任何更改来更新集群。

To use immediate Git repository reconciliation, you must have a Kubernetes cluster that runs: 要想立即使用 Git 仓库调谐,您必须有一个符合以下条件的 Kubernetes 集群:

  • 运行了 Kubernetes agent。
  • 运行了 Flux source-controllernotification-controller

立即 Git 仓库调谐可以减少 Git 推送和调谐之间的时间,但它不能保证每个 git push 事件都会被接收。您需要仍然将 GitRepository.spec.interval 设置为一个可接受的持续时间。

note代理仅能够访问配置项目和所有的公共项目。代理不能够立即调谐任何私有项目,除了配置项目。

自定义 webhook 端点

当 Kubernetes 代理调用 Receiver webhook 时,代理默认地址为 http://webhook-receiver.flux-system.svc.cluster.local,您也可以配置自定义地址。要配置自定义端点,将 flux.webhook_receiver_url 设置为代理可以解析的 URL。例如:

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

以格式 /api/v1/namespaces/[^/]+/services/[^/]+/proxy 配置的服务代理 URL 有特殊处理。比如:

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

在这些情况下,Kubernetes 代理使用可用的 Kubernetes 配置和上下文连接到 API 端点。如果您在集群外运行代理但是您还没为 Flux 通知 controller 配置 Ingress,那么您可以使用此功能。

caution您应该配置为仅信任服务代理 URL。当您提供服务代理 URL 时,Kubernetes 代理会发送典型的 Kubernetes API 请求,这些请求包含用于认证 API 服务的凭证。

令牌管理

要使用特定的 Flux 功能,您可能需要多个访问令牌。此外,您还可以使用多种令牌类型来实现相同的结果。

此部分提供了您可能需要的令牌指南,以及在可能的情况下提供了令牌类型推荐。

通过 Flux 访问极狐GitLab

要访问极狐GitLab 容器镜像仓库或 Git 仓库,Flux 可以使用:

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

令牌不需要写访问权限。

如果 http 是可访问的,则您应该使用项目部署令牌。如果您需要 git+ssh 访问,则您应该使用部署密钥。要对比部署密钥和部署令牌,可查看部署密钥

Flux 到极狐GitLab 的通知

如果您配置了 Flux 来从 Git 源同步,则Flux 可以在 GitLab 流水线中注册外部作业状态

要从 Flux 获取外部作业状态,您可以使用:

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

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