在 Kubernetes 中拥有多个命名空间和多个集群有什么区别答案

【问题标题】：What is the difference between having multiple namespace and multiple cluster in Kubernetes在 Kubernetes 中拥有多个命名空间和多个集群有什么区别
【发布时间】：2020-10-18 13:22:21
【问题描述】：

我是一名初学者，正在学习 Kubernetes。

据我了解，命名空间是由同一个物理集群支持的虚拟集群。

我们在哪些用例中使用单独的物理 Kubernetes 集群？

选择命名空间而不是物理 Kubernetes 集群可以节省哪些主要资源？（存在于物理集群的一个命名空间中的 Kubernetes 对象可以被所有其他命名空间共享，比如 kube-system 中的那些？物理 Kubernetes 集群中的节点是否被所有命名空间共享，但不可能在它们之间共享节点多个物理 Kubernetes 集群？）

【问题讨论】：

首先有服务成本差异
这类似于拥有虚拟服务器与专用服务器，成本是主要的选择和效率，因此如果不想提高成本并且您不介意效率，那么虚拟主机就可以了，否则专用主机 IMO跨度>

标签： kubernetes

【解决方案1】：

命名空间在任何意义上都不是“虚拟集群”；这只是将资源组合在一起的一种方式。例如，这些服务是不同的，因为它们位于不同的命名空间中：

kubectl describe service --namespace n1 foo
kubectl describe service --namespace n2 foo

但是n1 中的服务可以调用foo.n2.svc.cluster.local 而无需进行任何特殊设置。

命名空间是 Kubernetes RBAC 设置的自然边界。如果一个对象直接引用另一个对象（例如，一个 pod 挂载一个持久卷声明或从配置映射中获取环境变量），它们通常必须在同一个命名空间中。

在实际集群中，节点是共享的。给定节点可以从任何命名空间运行任何 pod（除非在 pod 级别专门配置）； kubectl describe node 会显示这个。如果 pod 大量使用某些资源（CPU、内存、磁盘 I/O），这可能会影响在同一节点上运行的其他 pod。这完全忽略了命名空间边界。

当您希望将事物实际分离时，您需要不同的集群：当一个环境中的服务不应该能够调用不同环境中的服务时，当需要分离集群级资源（如 NodePort 服务）时，如果你有不同的政策，比如 PersistentVolume 分配。

共享集群意味着您需要更少的一些集群全局进程（Kubernetes 核心、Istio 等服务网格）的副本，并且您可以共享节点。这可能会导致更好地利用大型节点。

例如，您可以将测试环境和生产环境分离到单独的集群中。这些将具有不同的外部 DNS 设置、单独的入口控制器和单独的节点池。不能不小心从外部向测试环境发送请求，测试环境的负载测试不会影响生产环境。

【讨论】：

所以集群中的命名空间和实际物理集群的区别在于节点在命名空间之间共享，但在物理集群的情况下不是，对吧？否则，我们还不如选择一个单独的 Kubernetes 集群，因为我们有资源容量。因此，将专用节点分配给特定的命名空间也可能毫无意义，因为我们不妨设置一个物理集群，唯一需要注意的是我们需要在每个物理集群中再次复制 kubernetes 的内部对象（就像 kube-system 中的那些命名空间），这不是命名空间所必需的。
其次，测试环境和生产环境不应设置为同一物理集群中的命名空间，因为一个命名空间中的服务可以调用同一物理集群中其他命名空间中存在的其他服务？因此，如果公司/企业中有多个团队使用测试环境，那么每个团队都可以有一个单独的命名空间，以便他们可以重用 kubernetes 存在于 kube-system 命名空间中的内部对象，还可以使用通用的企业范围的库通过将它们放在 kube-public 命名空间中
Kubernetes 不允许您将节点分配给命名空间。持久卷和 NodePort 服务同样是集群全局的。
编写脚本或以其他方式自动化初始集群设置是一个好主意，这样可以拥有多个配置相似的集群。每个团队共享一个带有命名空间的测试集群是合理的，但您可能不想共享您的测试和生产环境。

【解决方案2】：

通常需要一个单独的物理集群

满足合规和安全标准，例如PCI DSS、HIPPA 等。
为关键工作负载提供专用物理资源。
用于分隔不同的环境，例如 DEV、TEST、PROD

由许多租户使用自己的命名空间共享的多租户集群有助于节省成本。命名空间分离是合乎逻辑的，所有命名空间的资源仍然驻留在相同的 ETCD 存储中，但具有不同的键。这在单独的专用物理集群中不是问题，因为在这种情况下，集群也会有单独的 ETCD。

跨命名空间的资源访问由 RBAC 通过 kubernetes API Server 控制。但是，如果您可以绕过 API 服务器直接访问 ETCD，则可以访问所有命名空间中的所有内容。

您需要在多租户集群中放置大量最佳实践和保护措施，以使来自不同命名空间的租户不会互相踩踏。在单独的专用物理集群中，这并不是必需的。

【讨论】：