Kubernetes 中每个部署的命名空间

Question

我需要有关在 K8S 中管理部署的建议。我需要使用 gitops 进行蓝/绿部署，这基本上给我留下了两个选择：

1。使用单一命名空间。

这将需要使用 helm 来管理移除资源等，并通过 helm 代理管理蓝/绿，这反过来将需要创建重复部署模板（用于绿色和蓝色）。

优点：由 helm 管理，将删除已移除的资源；似乎是一般做法。

缺点：由 helm 管理，可能会搞砸一些事情，especially in multiple failed deployments；如果有人快速修复/添加一些资源并且不会提交 repo，则可以创建雪花命名空间；

2。每个部署使用一个命名空间

只需将每个修订版部署到它的命名空间，如 web-front-2142，检查，提升到入口，然后删除所有其他 web-front-[\d] 我仍然可以使用 helm 模板引擎，但没有分蘖。无需依赖 tiller 管理资源 - 生产命名空间升级后命名空间将被删除。

我需要为入口创建单独的命名空间，因为它是单一资源，但这将是一个非常简单的命名空间，类似于 web-front-ingress。

优点：没有雪花，每个部署都是完全从 repo 创建的；如果它有效 - 它有效；不以任何方式依赖以前的部署，如果以前的部署完全是 foobar-ed，那没关系。

缺点：单一资源（如入口）的单独命名空间；似乎不是 k8s 的设计方式，可能会导致无法预料的后果；包括 spinnaker 在内的所有部署工具都围绕单个命名空间部署。

---

需要一些建议和最佳实践！ :)

Answer 1

官方documentation提到以下几点：

命名空间适用于有许多用户分布在多个团队或项目中的环境。对于有几个到几十个用户的集群，您根本不需要创建或考虑命名空间。当您需要命名空间提供的功能时开始使用它们。

不一定要使用多个命名空间来分隔略有不同的资源，例如同一软件的不同版本：使用标签来区分同一命名空间内的资源。

Kubernetes Namespaces: use cases and insights" 文章告诉我们更多关于使用命名空间的最佳方法。 不建议为版本控制软件使用不同的命名空间：

Kubernetes 命名空间的一个易于掌握的反模式是版本控制。您不应该使用命名空间来消除 Kubernetes 资源版本的歧义。容器和容器注册表以及 Kubernetes 部署资源中都支持版本控制。多个版本应该通过利用 Kubernetes 容器模型共存，该模型还提供版本之间的自动迁移和部署。此外，版本范围命名空间将导致集群内命名空间的大量扩散，从而难以管理。

其他资源（例如GCPB）描述了命名空间的使用，主要用于为各个阶段、团队、项目、客户分离 Kubernetes 对象。
因此，您可以假设为蓝绿部署或金丝雀部署使用单独的命名空间并不是一种非常常见的方法。

Answer 2

所以，基本上我已经确定了一个答案 - 单一名称空间是一种方法。主要是因为单一资源（例如 PVC）无法在命名空间之间共享。

但主要的顿悟是您不必使用分蘖！你仍然可以使用 helm 模板，而 K8S 标签就是你所需要的！例如，我使用 jenkins 作为构建器和版本器。它设置了managed_by: jenkins和version: <build_number>之类的标签，所以我在部署时要做的就是找到所有具有相同name且版本低于当前版本的资源并修补它们，然后添加新资源，并删除所有资源managed_by: jenkins 不再存在（由他们的name）。我已经构建了一个简单的案例，它似乎工作得很好。