使用极狐GitLab 连接 Kubernetes 集群
- 将 Flux 推荐为 GitOps 解决方案于极狐GitLab 15.10。
您可以将 Kubernetes 集群与极狐GitLab 连接，部署、管理和监控您的云原生解决方案。
要将 Kubernetes 集群连接到极狐GitLab，您必须首先在集群中安装代理。
代理在集群中运行，您可以使用它来：
- 与位于防火墙或 NAT 后面的集群通信。
- 实时访问集群中的 API 端点。
- 推送有关集群中发生的事件的信息。
- 启用 Kubernetes 对象的缓存，这些对象以极低的延迟保持最新。
您必须为每个您想要连接到极狐GitLab 的集群部署一个单独的代理。代理设计为具有强大的多租户支持。为了简化维护和操作，您应该为每个集群运行一个代理。
代理总是注册在极狐GitLab 项目中。当代理注册并安装后，它可以被其他项目、群组和用户共享。此方法意味着您可以从极狐GitLab 自身来管理和配置您的代理实例，您还可以将单个安装扩展到多个租户。
可接受型代理
- 引入于极狐GitLab 17.4。
可接收型代理使极狐GitLab 能够与那些无法主动建立与极狐GitLab实例的网络连接，但极狐GitLab能够连接到的 Kubernetes 集群集成。例如，在以下情况中可能会出现这种情况：
- 极狐GitLab 运行在私有网络或防火墙后，而且仅能够通过 VPN 来访问。
- Kubernetes 集群由云提供商托管，但是暴露在互联网上或可以从私有网络访问。
当启用此功能时，极狐GitLab 使用提供的 URL 连接到代理。您可以同时使用代理和可接收型代理。
极狐GitLab 支持的 Kubernetes 版本
极狐GitLab 支持如下的 Kubernetes 版本。如果您想要在 Kubernetes 集群中运行极狐GitLab，您可能需要不同版本的 Kubernetes：
- 针对 Helm Chart。
- 针对 GitLab Operator。
您可以随时将您的 Kubernetes 版本升级至支持的版本：
- 1.30（当极狐GitLab 18.2 发布或 1.33 变为支持版本时结束支持）
- 1.29（当极狐GitLab 17.10 发布或 1.32 变为支持版本时结束支持）
- 1.28（当极狐GitLab 17.5 发布或 1.31 变为支持版本时结束支持）
极狐GitLab 旨在支持一个最新小版本的 Kubernetes（其发布后三个月）。在任何给定时间，极狐GitLab 至少支持三个可用于生产的 Kubernetes 小版本。
当新版本的 Kubernetes 发布时，我们将：
- 用四周之内的冒烟测试结果更新此页面。
- 如果我们预计在发布新版本支持时会延迟，我们将在大约八周内更新此页面。
当安装代理时，使用与您 Kubernetes 版本相兼容的 Helm 版本。其他的 Helm 版本可能不能正常工作。对于兼容版本的列表，可以查看 Helm 版本支持政策。
当我们不再支持仅支持已弃用 API 的 Kubernetes 版本时，就可以从极狐GitLab 代码库中移除对已弃用 API 的支持。
有一些极狐GitLab 功能可能在未列出的版本上工作。
Kubernetes 部署工作流
您可以从两种主要工作流中选择。但是推荐 GitOps 工作流。
GitOps 工作流
极狐GitLab 推荐使用 Flux 实践 GitOps。要想开始，可查阅 Flux 实践 GitOps 教程。
这个工作流完全由 Git 驱动，被认为是基于拉取的流程，因为集群正在从极狐GitLab 仓库中提取更新。
极狐GitLab CI/CD 工作流
在一个 CI/CD 工作流中，您可以配置极狐GitLab CI/CD 通过使用 Kubernetes API 来查询和更新您的集群。
此工作流被认为是基于推送的流程，因为极狐GitLab 正在将来自极狐GitLab CI/CD 的请求推送到您的集群。
在以下情况，使用此工作流：
- 当您有大量面向流水线的流程时。
- 当您需要迁移到代理但 GitOps 工作流无法支持您需要的用例时。
此工作流的安全模型较弱，不建议用于生产部署。
代理连接的详细信息
代理打开与 KAS 的双向通道进行通信。该通道用于代理和 KAS 之间的所有通信：
- 每个代理最多可以维护 500 个逻辑 gRPC 流，包括活跃的流和空闲的流。
- gRPC 流使用的 TCP 连接数量由 gRPC 本身决定。
- 每个连接的最长生命周期为两小时，并有一小时的宽限期。
- KAS 前面的代理可能会影响连接的最长生命周期。在 JihuLab.com 上，是两个小时。宽限期为最长生命周期的 50%。
有关通道路由的详细信息，请参阅在代理中路由 KAS 请求。
Kubernetes 集成术语
此部分提供了与极狐GitLab Kubernetes 集成相关的术语定义。
| 术语 | 定义 | 范围 |
|---|---|---|
| 极狐GitLab Kubernetes 代理 | 所有版本都有，包括相关的额功能和 component 和 kas 下面的组件。 |
GitLab, Kubernetes, Flux |
agentk |
Kubernets 集群侧的组件，用来维护极狐GitLab 和 Kubernetes 之间的安全连接，并实现部署自动化。 | GitLab |
极狐GitLab Kubernetes 代理服务器 (kas) |
极狐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 | 涉及在云平台和 Kubernetes 资源的管理和自动化中使用 Git 版本控制和协作的最佳实践。 | DevOps, Kubernetes |
| Kubernetes 命名空间 | Kubernetes 集群中的逻辑部分，用来在多个用户或环境间提供集群资源。 | Kubernetes |