使用 GitLab 与 Kubernetes 集成的最佳实践

Kubernetes Agent 和 Flux 结合使用时，通过 GitOps 部署到 Kubernetes 可以获得最佳体验。 GitLab 建议使用 GitOps（也称为基于拉取的部署）进行部署。 然而，您的公司可能无法过渡到 GitOps，或者您可能有某些（通常是非生产环境）原因需要使用基于管道的方法。 本文档描述了企业使用 GitOps 的最佳实践，并包含一些基于管道部署的注意事项。

有关 GitOps 优势的描述，请参阅 OpenGitOps 计划。

GitOps

• 尽管开始将 Kubernetes 集群连接到 GitLab 展示了如何使用 Flux CLI 安装 Flux，但要扩展和自动化 Flux 部署，您应该执行以下任一操作：
  • 使用 Flux Operator。
  • 使用 Terraform 或 OpenTofu 安装。
• 使用多租户锁定配置 Flux。
• 对于扩展，Flux 支持垂直扩展和水平分片。
• 有关 Flux 的特定指导，请参阅 Flux 文档中的 Flux 指南。
• 为简化维护，您应该每个集群只运行一个 GitLab Kubernetes Agent 安装。您可以通过模拟功能在整个 GitLab 域内共享代理连接。
• 考虑使用 Flux 的 OCIRepository 来存储和检索清单。 您可以使用 GitLab 管道构建和推送 OCI 镜像到容器注册表。
• 为缩短反馈循环，从相关的 GitLab 管道触发即时的 GitOps 协调。
• 您应该对生成的 OCI 镜像进行签名，并且只部署经过 Flux 签名和验证的镜像。
• 确保定期轮换 Flux 用于访问清单的密钥。您还应该定期轮换您的代理注册令牌。

OCI 容器

当您使用 OCI 容器而不是 Git 仓库时，清单的真相来源仍然是 Git 仓库。 您可以将 OCI 容器视为 Git 仓库和集群之间的缓存层。

使用 OCI 容器有几个好处：

• OCI 是为可扩展性而设计的。虽然 GitLab Git 仓库扩展性很好，但它们并非为此用例而设计。
• 一个 Git 仓库可以是多个 OCI 容器的来源，每个容器打包一小部分清单。 这样，如果您需要检索一组清单，就不需要下载整个 Git 仓库。
• OCI 仓库可以遵循众所周知的版本控制方案，Flux 可以配置为自动遵循该方案更新。 例如，如果您使用语义版本控制，Flux 可以自动部署所有次要版本和补丁版本更改，而主要版本需要手动更新。
• OCI 镜像可以签名，并且 Flux 可以验证该签名。
• OCI 仓库可以在镜像构建后由容器注册表进行扫描。
• 构建 OCI 容器的作业可以使用常规 GitOps 工具不支持的知名发布管理功能，如受保护的环境、部署审批和部署冻结窗口。

基于管道的部署

如果您需要使用基于管道的部署，请遵循以下最佳实践：

• 为减少每个集群部署的代理数量，请在您的组和项目之间共享代理连接。 如果可能，每个集群只使用一个代理部署。
• 使用模拟功能，并使用常规的 Kubernetes RBAC 最小化集群中的 CI/CD 作业访问权限。