每个功能分支部署的新 K8s 命名空间是一个好习惯吗？答案

【问题标题】：Is new K8s namespace per each feature branch deployment a good practice?每个功能分支部署的新 K8s 命名空间是一个好习惯吗？
【发布时间】：2019-04-20 05:40:20
【问题描述】：

我正在尝试弄清楚如何为开发集群组织 K8s 命名空间。

现在我们有多个开发命名空间（每个团队）。

单个命名空间中有大量 pod（大约 100-200 个）。

每个功能分支部署 1-5 个 pod。

我们使用 Helm 进行部署。但是也有队友说很难驾驭。

新想法是为每个功能分支部署创建一个命名空间。

现在，我发现主要问题在于跨命名空间的 TLS（和其他）机密同步共享。但是可以通过做一个 CronJob 来解决。

这种方法有什么优点或缺点吗？

【问题讨论】：

每个特性分支的命名空间是个好主意。如果您在共享机密时遇到问题，可以使用此工具。它可以在命名空间之间甚至集群之间同步秘密和 configMap。任何更改几乎都是即时同步的。 appscode.com/products/kubed/0.8.0/guides/config-syncer/…
Emruz Hossain，感谢您的回复。 “kubed”看起来正是我想要的！

标签： kubernetes namespaces kubernetes-helm

【解决方案1】：

这绝对是使用命名空间将部署限制为功能团队的好方法。
但是每个命名空间部署 50 多个 pod 变得难以管理，尤其是当 pod 包含 10 多个容器时。因此，您倾向于为每个部署团队管理 50X10=500 个容器。

每个功能分支部署 1-5 个 pod。

这确实是使用命名空间的好方法，但是当您最初说您有大约 100-200 个 pod 时，您仍然需要记住很多很多的命名空间。

希望你在 k8s 中使用 rbac

【讨论】：

【解决方案2】：

每个（审查）功能分支的命名空间是要走的路。

隔离每个部署组使其易于管理......

此外，如果您使用 kubernetes 仪表板，命名空间概览会更有意义。

如果你真的要重用所有这些，默认同步秘密和 configMaps 的想法很棒，而且它们从来都不是特定于命名空间的。

在创建命名空间时动态生成秘密和 configMap，然后为该命名空间添加它们而不同步是另一种方法。

secrets 和 configMaps 是隔离的、特定于命名空间的并驻留在特定的命名空间中是有原因的。 Secrets 和 configMaps 只能被位于同一命名空间中的 pod 引用。

仅仅因为您可以同步并不意味着您应该...

如果您仍然坚持同步，则拥有 1 组“可同步共享秘密”和另一组特定于命名空间的组。

https://kubernetes.io/docs/concepts/configuration/secret/#restrictions

https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/#restrictions

【讨论】：