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

连接 Kubernetes 集群与 GitLab

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

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

要将 Kubernetes 集群连接到 GitLab，您必须先 在集群中安装代理。

代理在集群中运行，您可以使用它来：

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

有关代理目的和架构的更多详细信息，请参阅 架构文档。

您必须为每个想要连接到 GitLab 的集群部署一个单独的代理。 代理设计时具有强大的多租户支持。为简化维护和操作，每个集群应只运行一个代理。

代理始终在 GitLab 项目中注册。 代理注册并安装后，代理到集群的连接可以与其他项目、组和用户共享。 这种方法意味着您可以从 GitLab 本身管理和配置您的代理实例， 并且可以将单个安装扩展到多个租户。

接收式代理

  • Tier: Ultimate
  • Offering: GitLab Self-Managed

接收式代理允许 GitLab 与无法建立到 GitLab 实例网络连接的 Kubernetes 集群集成，但 GitLab 可以连接到这些集群。例如，当以下情况发生时：

  1. GitLab 在私有网络或防火墙后运行，只能通过 VPN 访问。
  2. Kubernetes 集群由云提供商托管，但暴露在互联网上或可以从私有网络访问。

启用此功能后，GitLab 会使用提供的 URL 连接到代理。 您可以同时使用代理和接收式代理。

GitLab 功能支持的 Kubernetes 版本

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

您可以随时将您的 Kubernetes 版本升级到支持的版本：

  • 1.33（支持在 GitLab 19.2 版本发布或 1.36 版本支持时结束）
  • 1.32（支持在 GitLab 18.10 版本发布或 1.35 版本支持时结束）
  • 1.31（支持在 GitLab 18.7 版本发布或 1.34 版本支持时结束）

GitLab 旨在在 Kubernetes 初始发布三个月后支持新的次要版本。GitLab 在任何时候至少支持三个生产就绪的 Kubernetes 次要版本。

当发布新版本的 Kubernetes 时，我们将：

  • 在大约四周内更新此页面，包含我们早期冒烟测试的结果。
  • 如果我们预计在新版本支持发布方面会有延迟，我们将在大约八周内更新此页面，包含预期的 GitLab 支持版本。

安装代理时，请使用与您的 Kubernetes 版本兼容的 Helm 版本。其他版本的 Helm 可能无法工作。有关兼容版本列表，请参阅 Helm 版本支持策略。

当我们停止支持仅支持已弃用 API 的 Kubernetes 版本时，对已弃用 API 的支持可能会从 GitLab 代码库中移除。

一些 GitLab 功能可能在此未列出的版本上工作。这个史诗 跟踪对 Kubernetes 版本的支持。

Kubernetes 部署工作流

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

GitOps 工作流

GitLab 推荐使用 Flux 进行 GitOps。要开始使用，请参阅 教程：设置 Flux 进行 GitOps。

GitLab CI/CD 工作流

在 CI/CD 工作流 中，您配置 GitLab CI/CD 使用 Kubernetes API 来查询和更新您的集群。

此工作流被视为 基于推送 的，因为 GitLab 将来自 GitLab CI/CD 的请求推送到您的集群。

使用此工作流：

  • 当您有管道驱动的过程时。
  • 当您需要迁移到代理，但 GitOps 工作流不支持您的用例时。

此工作流的安全模型较弱。您不应将 CI/CD 工作流用于生产部署。

代理连接技术细节

代理为通信打开一个到 KAS 的双向通道。 此通道用于代理和 KAS 之间的所有通信：

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

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

Kubernetes 集成术语表

此术语表提供了与 GitLab Kubernetes 集成相关的术语定义。

术语 定义 范围
GitLab agent for Kubernetes 整体产品，包括相关功能和底层组件 agentk 和 kas。 GitLab, Kubernetes, Flux
agentk 集群端组件，用于维护与 GitLab 的安全连接，以进行 Kubernetes 管理和部署自动化。 GitLab
GitLab agent server for Kubernetes (kas) GitLab 的 GitLab 端组件，处理 Kubernetes 代理集成的操作和逻辑。管理 GitLab 和 Kubernetes 集群之间的连接和通信。 GitLab
Pull-based deployment 一种部署方法，其中 Flux 检查 Git 仓库中的更改并自动将这些更改应用到集群。 GitLab, Kubernetes
Push-based deployment 一种部署方法，其中更新从 GitLab CI/CD 管道发送到 Kubernetes 集群。 GitLab
Flux 一个开源的 GitOps 工具，与代理集成用于基于拉取的部署。 GitOps, Kubernetes
GitOps 一组实践，涉及使用 Git 进行版本控制和协作，以管理和自动化云和 Kubernetes 资源。 DevOps, Kubernetes
Kubernetes namespace Kubernetes 集群中的逻辑分区，用于在多个用户或环境之间划分集群资源。 Kubernetes

相关主题