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

Question

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

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

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

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

Answer 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 设置、单独的入口控制器和单独的节点池。您不会意外地将请求从外部发送到测试环境中，并且在测试环境上进行负载测试不会影响生产环境。