我需要管理K8S部署的建议。我需要使用 gitops 进行蓝/绿部署，这给我留下了基本上两个选择：
1. 使用单个命名空间。
这将需要使用helm来管理删除资源等，并通过代理通过helm管理蓝/绿，这反过来又需要创建重复的部署模板(用于绿色和蓝色(。
优点：由 helm 管理，将删除已删除的资源;似乎是一般做法。
缺点：由 helm 管理，可能会搞砸一些东西，尤其是在多次失败的部署中; 如果有人快速修复/添加一些资源并且不会提交存储库，则可以创建雪花命名空间;
2. 每个部署使用一个命名空间
只需将每个修订部署到它的命名空间，如web-front-2142，检查，提升为入口，然后删除所有其他web-front-[\d]我仍然可以使用 helm 模板引擎，但没有舵柄。无需依赖 tilner 管理资源 - 命名空间将在生产命名空间升级后删除。
我需要为入口创建单独的命名空间，因为它是单一资源，但这将是一个非常简单的命名空间，类似于web-front-ingress。
优点：没有雪花，每个部署都是完全从存储库创建的;如果它有效 - 它有效;不以任何方式依赖以前的部署，如果以前的部署完全是foobar编辑的，没关系。
缺点：为入口等单一资源提供单独的命名空间;似乎不是k8s的设计方式，可能会导致不可预见的后果;包括Spinnaker在内的所有部署工具都围绕着单个命名空间部署。
需要一些建议和最佳实践！ :)
官方文档提到了以下内容：
命名空间旨在用于具有许多用户分布在多个团队或项目中的环境。对于具有几到几十个用户的集群，根本不需要创建或考虑命名空间。当您需要命名空间提供的功能时，开始使用它们。
没有必要仅仅为了分隔略有不同的资源而使用多个命名空间，例如同一软件的不同版本：使用标签来区分同一命名空间中的资源。
Kubernetes 命名空间：用例和见解"一文详细介绍了使用命名空间的最佳方法。 不建议对软件使用不同的命名空间：
对于 Kubernetes 命名空间，一个容易掌握的反模式是版本控制。您不应该使用命名空间来消除 Kubernetes 资源版本的歧义。容器和容器注册表以及 Kubernetes 部署资源中都存在对版本控制的支持。多个版本应利用 Kubernetes 容器模型共存，该模型还提供具有部署的版本之间的自动迁移。此外，版本范围命名空间将导致集群内命名空间的大量扩散，使其难以管理。
其他资源(例如 GCPB(描述了命名空间的用法，主要用于分离各个阶段、团队、项目、客户端的 Kubernetes 对象.
因此，您可以假设使用单独的命名空间进行蓝绿部署或金丝雀部署不是一种非常常见的方法。
所以，基本上我已经确定了一个答案 - 单数命名空间是一种方式。主要是因为无法在命名空间之间共享的单一资源(如 PVC(。
但主要的顿悟是你不必使用舵柄！您仍然可以使用头盔模板，K8S 标签就是您所需要的！例如，我使用 jenkins 作为构建器和版本控制器。它设置了managed_by: jenkins和version: <build_number>等标签，所以我在部署时所要做的就是找到所有具有相同name和版本低于当前资源并修补它们，然后添加新资源，并删除所有资源managed_by: jenkins不再存在(按其name(。我已经构建了一个简单的案例，它似乎工作得很好。