将开发，质量保证和生产等环境映射到kubernetes命名空间似乎是一种好习惯。为了实现“真正的”分离，似乎最好标记专用于那些名称空间之一的节点，并确保仅在那些节点上调度那些环境中的资源。至少这是我们目前的想法。在那些不应该/不得篡改的名称空间中可能会出现一个清单。 Kubernetes似乎不支持将名称空间与开箱即用的节点相关联。 PodNodeSelector准入控制器似乎很接近，但并不是我们所需要的。实现我们想要的唯一选择似乎是here中所述的自定义变异接纳Webhook。
我想其他人以前也曾来过这里，有一种解决方案可以解决我们的主要担忧，即我们不希望在开发环境或质量保证环境中加载负载，从而影响生产性能。
是否有现成的解决方案将名称空间链接到节点？
如果没有，是否有其他方法可确保环境不影响负载/性能？
答案 0 :(得分：1)
我想其他人以前也曾来过这里，有一种解决方案可以解决我们的主要担忧，即我们不希望在开发环境或质量保证环境中加载负载，从而影响生产性能。
在那里，被它烧死了。
在某些情况下，一个集群中的多个环境可能是一个好主意，但是将dev / qa / stage与生产混合在一个集群中会带来麻烦。负载本身可能不是主要问题，特别是如果您通过适当的资源分配来减轻影响，但是任何在kube系统吊舱上的调整，修改和开发过程引起的中断都将直接影响生产。您无法事先测试kubernetes系统组件上的更新，开发上的任何cni问题都可能减慢速度或使生产无法运行，等等。。。我们走了这条路，不建议这样做。
话虽如此，这样的分离相当容易。在我们的一个集群中，我们确实为单个集群中的某些项目保留了dev / qa / stage环境，并用标签分隔了一些资源。严格说来，并不是真正的环境分隔，但是我们确实有专用于elk的节点，覆盖了所有三个环境，单独的gitlab运行器节点，数据库节点等等，但是原理是相同的。我们标记节点，并使用nodeAffinity和nodeSelectorTerms将具有相同标签的节点组用于某些任务/服务（或您所处环境）分离。附带说明，nodeSelector是根据the official documentation来描述的。
答案 1 :(得分：0)
在我看来，在一个集群中拥有多个环境是一个坏主意，原因有很多。
如果您确定要执行此操作，并且不想破坏生产Pod的性能，则可以轻松地将resources附加到部署/ pod。
另一种方法是将标签附加到节点，并使用PodNodeSelector强制特定的pod部署在节点上