12.2.1 集群层负载隔离
直奔主题，Kubernetes不支持安全的多租户（nulti-tenancy）集群，Kubernetes中唯一的集群级别的安全边界就是集群本身。
对Kubernetes集群进行切分的唯一方式是创建命名空间（namespace）。Kubernetes中的命名空间与Linux内核命名空间是不同的，它仅是Kubernetes集群的逻辑分区。事实上，它更是一种对以下资源进行分组的方式。
●限制（Limit）。
●配额（Quota）。
●RBAC规则。
重点在于，Kubernetes的命名空间，并不能保证某一个命名空间中的Pod不会影响到另一个命名空间中的Pod。因此，我们不应将生产负载和有潜在风险的负载运行在同一个物理集群上。唯一能够确保真正的隔离的方式是将其置于一个独立的集群中运行。
尽管如此，Kubernetes命名空间还是有用的，而且我们应当使用它——只是不要将其作为安全边界来使用。
那么命名空间和“软”多租户与“硬”多租户有什么关系呢？
1.命名空间与“软”多租户
为了便于描述，我们定义“软”多租户为在共享的基础设施上托管多个可信的工作负载。所谓可信，是指工作负载不需要绝对的隔离（一个Pod或容器不能影响另一个）。
举个例子，两个可信的工作负载可以是一个电商应用的Web前端服务和后端推荐服务。两个服务都是同一个电商应用的一部分，因此并无“敌意”，同时可以获得如下好处。
●可以由各自独立的团队负责。
●可以为每个服务配置不同的资源限制和配额。
在这种情况下，推荐的解决方案是，在同一集群中的同一个命名空间下，分别部署前端服务和后端服务。
2.命名空间与“硬”多租户
我们定义“硬”多租户为在同一个基础设施之上托管不可信的或有潜在风险的工作负载。不过，就像前面提到的，目前这并不能基于Kubernetes实现。
这意味着，对安全有强烈要求的工作负载，是需要运行在独立的Kubernetes集群上的！这样的例子包括以下几种。
●在不同的集群上隔离生产和非生产工作负载。
●在不同的集群上隔离不同的用户。
●将敏感项目或业务功能隔离在单独的集群。
类似的例子有很多。如果读者的工作负载对安全性有强烈的需求，那么就将其置于单独的集群上吧。
注：Kubernetes项目中有一个专门的“多租户工作组”，他们正在开发Kubernetes所支持的多租户模型。这意味着K8s未来的版本有可能会支持“硬”多租户。