我正在尝试找出如何为开发集群组织K8s命名空间。现在，我们有多个开发命名空间（每个团队一个）。单个命名空间中有大量的pods（约100-200个）。每个特性分支部署中有1-5个pods。我们使用Helm进行部署。但是有些团队成员表示难以管理。新想法是为每个特性分支部署创建一个命名空间。现在，我认为主要问题在于TLS（和其他）secrets在不同命名空间之间的同步共享。但是可以通过制作CronJob来解决。这种方法有什么优缺点吗？
每个功能分支部署一个新的K8s命名空间是一种好的实践吗？
3
- visortelle
2
3在特性分支中使用命名空间是一个好的想法。如果您在分享机密方面遇到问题，可以使用此工具。它可以在命名空间甚至集群之间同步机密和配置映射。任何更改都几乎是瞬时同步的。
https://appscode.com/products/kubed/0.8.0/guides/config-syncer/intra-cluster/ - Emruz Hossain
1Emruz Hossain，感谢您的回复。 "kubed" 看起来正是我想要的！ - visortelle
2个回答
2
对于限制部署到功能团队，使用命名空间绝对是一个好方法。
但是，如果每个命名空间中有50个以上的pod，特别是如果这些pod包含10个以上的容器，则变得难以管理。因此，您将倾向于为每个部署团队管理50X10 = 500个容器。
每个功能分支部署1-5个pod。
这确实是使用命名空间的好方法，但是当你最初说你有大约100-200个pod时，你仍然需要记住很多命名空间。
希望您在k8s中使用rbac
- Vinod Kumar
0
每个（审核）特性分支的命名空间是正确的选择。
隔离每个部署组使其易于管理...
如果您使用 Kubernetes 仪表板，则命名空间概述将更加清晰明了。
默认情况下同步 secrets 和 configMaps 的想法非常好，如果您确实重复使用它们，并且它们从未真正与命名空间相关。
在命名空间创建时动态生成 secrets 和 configMaps，然后为该命名空间添加它们，而不进行同步，也是一种方法。
秘密和 configMaps 被隔离、特定于命名空间并驻留在特定的命名空间中，这是有原因的。秘密和 configMaps 只能被驻留在相同命名空间中的 pod 引用。
仅仅因为您可以同步并不意味着您应该这样做...
如果您仍然坚持同步，则应该有一个“可同步共享秘密”的组，以及另一个特定于命名空间的组。
https://kubernetes.io/docs/concepts/configuration/secret/#restrictions
https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/#restrictions
- Khalil Gharbaoui
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接