Ond*_*žka 5 networking namespaces docker kubernetes
我们正在开发利用 AWS 中的 Docker/Kubernetes 的 CI/CD 管道。这个话题在Kubernetes CI/CD 管道中有所涉及。
我们想为每个 SCM 分支创建（并销毁）一个新环境，因为在合并之前有一个 Git 拉取请求。
我们将为此提供一个 Kubernetes 集群。
在开发团队的原型设计过程中，我们想到了 Kubernetes 命名空间。看起来很合适：对于每个分支，我们创建一个 namespace ns-<issue-id>。
但是这个想法被 dev-ops 原型设计师驳回了，没有太多解释，只是说“我们不这样做，因为 RBAC 导致它很复杂”。而且很难得到一些详细的原因。
但是，出于 CI/CD 的目的，我们不需要 RBAC - 所有人都可以无限制地运行，没有配额，我们只需要为每个环境设置一个单独的网络。
出于这种目的使用命名空间是个好主意吗？在阅读了有关 namespaces 的 Kubernetes 文档后，我仍然不确定。
如果没有，有没有更好的方法？理想情况下，我们希望避免使用 Helm，因为它具有我们可能不需要的复杂程度。
我们正在开发一个名为Jenkins X的开源项目，这是 Jenkins 基金会提议的子项目，旨在使用 Jenkins 和 GitOps 来自动化 Kubernetes 上的 CI/CD 进行推广。
当您提交拉取请求时，我们会自动创建一个预览环境，这正是您所描述的 - 一个临时环境，用于在拉取请求获得批准之前部署拉取请求以进行验证、测试和批准。
由于多种原因，我们现在一直使用预览环境，并且是它们的忠实粉丝！每个预览环境都位于单独的命名空间中，因此您可以使用它们从 Kubernetes 获得所有常用的 RBAC 功能。
如果您感兴趣，这里有一个演示，介绍如何使用 GitOps 在 Kubernetes 上的多个环境中实现 CI/CD 自动化，以在环境之间进行升级并在 Pull 请求上预览环境 - 使用 Spring Boot 和 Nodejs 应用程序（但我们支持多种语言 + 框架）。
| 归档时间： |
|
| 查看次数： |
486 次 |
| 最近记录： |