我需要有关管理 K8S 部署的建议。我需要使用 gitops 进行蓝/绿部署，这基本上给我留下了两个选择:
1。使用单一命名空间。
这将需要使用 helm 来管理删除资源等，并通过代理通过 helm 管理蓝色/绿色，而这又需要创建重复的部署模板(针对绿色和蓝色)。
优点:由helm管理，会删除已删除的资源；似乎是普遍做法。
缺点:由 helm 管理，可能会弄乱一些东西，especially in multiple failed deployments ;如果有人快速修复/添加一些资源并且不会提交到存储库，则可以创建雪花命名空间；
2。每个部署使用一个命名空间
只需将每个修订版本部署到它的命名空间，如web-front-2142，检查，提升到入口，然后删除所有其他web-front-[\d]仍然可以使用 helm 模板引擎，但没有耕耘机。无需依赖tiller管理资源 - 生产命名空间升级后命名空间将被删除。
我需要为入口创建单独的命名空间，因为它是单一资源，但这将是一个非常简单的命名空间，类似于web-front-ingress。
优点:没有雪花，每个部署都是完全从存储库创建的；如果它有效-它有效；不以任何方式依赖于以前的部署，如果以前的部署完全是 foobar-ed，那也没关系。
缺点:单独的命名空间用于单一资源，例如入口；似乎不是 k8s 的设计方式，可能会导致不可预见的后果；包括 spinnaker 在内的所有部署工具都围绕单一命名空间部署。
需要一些建议和最佳实践! :)
最佳答案
官方documentation提到以下内容:
Namespaces are intended for use in environments with many users spread across multiple teams, or projects. For clusters with a few to tens of users, you should not need to create or think about namespaces at all. Start using namespaces when you need the features they provide.
It is not necessary to use multiple namespaces just to separate slightly different resources, such as different versions of the same software: use labels to distinguish resources within the same namespace.
Kubernetes Namespaces: use cases and insights"文章告诉我们更多有关使用命名空间的最佳方法。 不建议对软件版本使用不同的命名空间:
An easy to grasp anti-pattern for Kubernetes namespaces is versioning. You should not use Namespaces as a way to disambiguate versions of your Kubernetes resources. Support for versioning is present in the containers and container registries as well as in Kubernetes Deployment resource. Multiple versions should coexist by utilizing the Kubernetes container model which also provides for auto migration between versions with deployments. Furthermore versions scope namespaces will cause massive proliferation of namespaces within a cluster making it hard to manage.
其他资源(例如 GCPB )描述了命名空间的用法，主要用于分隔各个阶段、团队、项目、客户端的 Kubernetes 对象。
因此，您可以假设使用单独的命名空间进行蓝绿部署或金丝雀部署并不是一种非常常见的方法。
关于kubernetes - kubernetes 中每个部署的命名空间，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/51178158/