我应该使用 kubernetes 默认命名空间吗？

Question

我们将通过在客户 kubernetes 环境中部署和运行容器来为客户提供功能。工作完成后，我们将清理容器。目前，计划是使用 k8s 默认命名空间，但我不确定这是否会成为客户关注的问题。我在k8s相关领域没有太多经验。我们应该为客户提供一个选项来指定运行容器的命名空间，还是只使用默认命名空间？我很感激你的建议！

Answer 1

我建议您永远不要使用（！？）默认名称空间。

以下内容更多是发自内心的而非客观的，但它来自 Kubernetes 的多年经验。2016 年，我和一位前同事在博客中讨论了命名空间的使用：

https://kubernetes.io/blog/2016/08/kubernetes-namespaces-use-cases-insights/

请注意，从那时起，添加了 RBAC，它允许安全地强制执行分离。

尽管它作为命名 ( default) 命名空间存在，但它的行为就像不存在（集群具有）命名空间一样。可能（！？）在添加命名空间后它被重新连接到 Kubernetes 中

除非您的上下文被定义为特定的其他命名空间，kubectl ...否则行为与kubectl ... --namespace=default. 因此，一不小心就很容易污染这个命名空间并受到污染的影响。我确信您的团队会为您的基础设施使用代码，但会发生错误，并且“我忘记指定名称空间”很容易完成（并且很少需要）。

使用非默认命名空间变得非常有意、明确​​并且我认为是精确的。例如，您必须（根据 @david-maze 答案）更加关注命名空间资源的 RBAC。

使用命名空间是一种促进多租户的机制，这是分离客户（业务部门、版本等）和客户的需要的。

您无法删除默认命名空间，但可以删除任何非默认命名空间（并因此删除受其约束的所有资源）。

我肯定会想到更多！

更新

• 推论：通常不会将资源限制在namespace规格范围内，而是使用例如kubectl apply --filename=x.yaml --namespace=${NAMESPACE}