如何在 Kubernetes 中隔离 CI 管道每个分支环境？

Question

我们正在利用 AWS 中的 Docker/Kubernetes 开发 CI/CD 管道。这个话题在Kubernetes CI/CD pipeline中涉及到。

我们想为每个 SCM 分支创建（和销毁）一个新环境，因为 Git 拉取请求直到合并。

我们将为此提供一个 Kubernetes 集群。

在开发团队进行原型设计期间，我们提出了 Kubernetes 命名空间。看起来很合适：为每个分支创建一个命名空间ns-<issue-id>。

但是这个想法被 dev-ops Prototyper 驳回了，没有太多解释，只是说“我们不这样做是因为它由于 RBAC 而变得复杂”。并且很难得到一些详细的原因。

但是，出于 CI/CD 的目的，我们不需要 RBAC - 所有人都可以以无限权限和无配额运行，我们只需要为每个环境提供一个单独的网络。

为这些目的使用命名空间是个好主意吗？看完Kubernetes docs on namespaces我还是不确定。

如果没有，有没有更好的方法？理想情况下，我们希望避免使用 Helm，因为它的复杂程度我们可能不需要。

Answer 1

我们正在开发一个名为 Jenkins X 的开源项目，这是 Jenkins 基金会提出的一个子项目，旨在使用 Jenkins 和 GitOps 在 Kubernetes 上自动化 CI/CD 以进行推广。

当您提交拉取请求时，我们会自动创建一个 预览环境，这正是您所描述的 - 一个临时环境，用于在拉取请求之前部署拉取请求以进行验证、测试和批准被批准。

我们现在一直使用预览环境有很多原因，并且是它们的忠实拥护者！每个预览环境都位于一个单独的命名空间中，因此您可以从 Kubernetes 中获得所有常用的 RBAC 功能。

如果您有兴趣，这里是 a demo of how to automate CI/CD with multiple environments on Kubernetes using GitOps，用于在拉取请求上的环境和预览环境之间进行推广 - 使用 Spring Boot 和 nodejs 应用程序（但我们支持多种语言 + 框架）。