我们正在开发利用AWS中的Docker / Kubernetes的CI / CD管道。 Kubernetes CI/CD pipeline已触及此主题。
我们想为每个SCM分支创建（并销毁）一个新环境，因为Git pull请求直到合并。
我们将有一个Kubernetes集群。
在开发团队的原型设计过程中，我们找到了Kubernetes命名空间。它看起来非常合适：对于每个分支，我们创建一个名称空间ns-<issue-id>。
但是这个想法被dev-ops prototyper驳回，没有太多解释，只是声明＆＃34;我们没有这样做，因为它因RBAC而变得复杂＆＃34;。得到一些详细的理由很难。
但是，对于CI / CD目的，我们不需要RBAC - 所有都可以使用无限制权限运行，没有配额，我们只需要为每个环境分离一个网络。
为这样的目的使用命名空间是个好主意吗？阅读Kubernetes docs on namespaces后，我仍然不确定。
如果没有，有更好的方法吗？理想情况下，我们希望避免使用Helm，因为它可能是我们可能不需要的复杂程度。
答案 0 :(得分：1)
我们正在开发一个名为Jenkins X的开源项目，该项目是Jenkins基金会的一个拟议子项目，旨在使用Jenkins和GitOps进行促销，自动化Kubernetes上的CI / CD。
当您提交Pull Request时，我们会自动创建一个预览环境，这正是您所描述的 - 一个临时环境，用于部署拉取请求以进行验证，测试和检测。拉取请求获得批准之前的批准。
我们现在一直使用预览环境有很多原因，并且是他们的忠实粉丝！每个预览环境都在一个单独的命名空间中，因此您可以从Kubernetes获得所有常用的RBAC功能。
如果您对这里的a demo of how to automate CI/CD with multiple environments on Kubernetes using GitOps感兴趣，可以在环境和拉动请求预览环境之间进行推广 - 使用Spring Boot和nodejs应用程序（但我们支持多种语言+框架）。