kubernetes - Kubernetes 中每个部署的命名空间

Question

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

1. 使用单一命名空间。

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

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

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

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

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

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

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

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

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

Answer 1

官方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 对象。
因此，您可以假设为蓝绿部署或金丝雀部署使用单独的命名空间并不是一种非常常见的方法。