使用极狐GitLab 连接 Kubernetes 集群

  • 引入于极狐GitLab 13.4。
  • grpcs 的支持引入于极狐GitLab 13.6。
  • 通过 Early Adopter Program 在 wss://kas.gitlab.com 下,代理服务器在 JihuLab.com 上可用于极狐GitLab 13.10。
  • 引入于极狐GitLab 13.11,极狐GitLab 代理在 JihuLab.com 上可用。
  • 从专业版移动到基础版于极狐14.5。
  • 从”极狐GitLab Kubernetes 代理”重命名为 “Kubernetes 的极狐GitLab 代理”于极狐GitLab 14.6。
  • 将 Flux 推荐为 GitOps 解决方案于极狐GitLab 15.10。

您可以将 Kubernetes 集群与极狐GitLab 连接,部署、管理和监控您的云原生解决方案。

要将 Kubernetes 集群连接到极狐GitLab,您必须首先在集群中安装代理

代理在集群中运行,您可以使用它来:

  • 与位于防火墙或 NAT 后面的集群通信。
  • 实时访问集群中的 API 端点。
  • 推送有关集群中发生的事件的信息。
  • 启用 Kubernetes 对象的缓存,这些对象以极低的延迟保持最新。

工作流

您可以从两个主要工作流中进行选择。推荐使用 GitOps 工作流。

GitOps 工作流

GitOps 工作流中

  • 您将 Kubernetes manifests 保存在极狐GitLab 中。
  • 在集群中安装极狐GitLab 代理。
  • 每当您更新清单时,代理都会更新集群。
  • 集群自动清理意外更改。它使用服务器端应用来修复第三方引入的任何不一致的配置。

这个工作流完全由 Git 驱动,被认为是基于拉取的流程,因为集群正在从极狐GitLab 仓库中提取更新。

极狐GitLab CI/CD 工作流

CI/CD 工作流中

  • 您将极狐GitLab CI/CD 配置为使用 Kubernetes API 来查询和更新集群。

此工作流被认为是基于推送的流程,因为极狐GitLab 正在将来自极狐GitLab CI/CD 的请求推送到您的集群。

在以下情况,使用此工作流:

  • 当您有大量面向流水线的流程时。
  • 当您需要迁移到代理但 GitOps 工作流无法支持您需要的用例时。

此工作流的安全模型较弱,不建议用于生产部署。

支持极狐GitLab 功能的 Kubernetes 版本

极狐GitLab 支持以下 Kubernetes 版本。如果您想在 Kubernetes 集群中运行极狐GitLab,您可能需要不同版本的 Kubernetes:

您随时可以将您的 Kubernetes 版本升级为受支持的版本:

  • 1.27(支持将于 2024 年 7 月 22 日或 1.30 受支持时结束)
  • 1.26(支持将于 2024 年 3 月 22 日或 1.29 受支持时结束)
  • 1.25(支持将于 2023 年 10 月 22 日或 1.28 受支持时结束)

极狐GitLab 的目标是在首次发布三个月后支持新的 Kubernetes 小版本。极狐GitLab 在任何给定的时间至少支持三个可用于生产的 Kubernetes 小版本。

安装代理时,请使用与您的 Kubernetes 版本兼容的 Helm 版本。其他版本的 Helm 可能不可用。有关兼容版本的列表,请参阅 Helm 版本支持政策

当我们放弃对仅支持已弃用 API 的 Kubernetes 版本的支持时,可以从极狐GitLab 代码库中移除对已弃用 API 的支持。

某些极狐GitLab 功能可能适用于此处未列出的版本。

从历史的基于证书的集成迁移到代理

了解如何从基于证书的集成迁移到 Kubernetes 代理

代理连接

代理打开与 KAS 的双向通道进行通信。 该通道用于代理和 KAS 之间的所有通信:

  • 每个代理最多可以维护 500 个逻辑 gRPC 流,包括活跃的流和空闲的流。
  • gRPC 流使用的 TCP 连接数量由 gRPC 本身决定。
  • 每个连接的最长生命周期为两小时,并有一小时的宽限期。
    • KAS 前面的代理可能会影响连接的最长生命周期。在 JihuLab.com 上,是两个小时。宽限期为最长生命周期的 50%。

有关通道路由的详细信息,请参阅在代理中路由 KAS 请求

相关主题