多租户集群里面资源隔离的边界有哪些，怎么划分？

多租户集群资源隔离的边界不是一道静态的墙，而是从命名空间、节点池、网络策略到存储卷逐层收紧的切割线；判断边界是否有效，只看一个动作：租户A的Pod能不能碰到租户B的数据面，碰不到，边界才闭合。

多租户集群资源隔离怎么做：先划清三条控制线

多租户集群的隔离边界,多数人第一步会想到Namespace，但Namespace只能解决“名字不冲突”，解决不了“流量过不去”，真正要落地，得同时画三条线：控制面权限线、数据面流量线、存储面挂载线。

• 控制面权限线：用RBAC和ResourceQuota，限制每个租户能创建多少资源、能看哪些命名空间。
• 数据面流量线：用NetworkPolicy和节点池，限制Pod之间的东西向流量和调度位置。
• 存储面挂载线：用StorageClass和PV/PVC策略，限制谁能把持久卷挂到自己的Pod里。

先做最基础的一步：创建命名空间并挂上配额。

kubectl create ns tenant-a

apiVersion: v1
kind: ResourceQuota
metadata:
  name: tenant-a-quota
  namespace: tenant-a
spec:
  hard:
    requests.cpu: "10"
    requests.memory: 20Gi
    limits.cpu: "20"
    limits.memory: 40Gi
    persistentvolumeclaims: "10"
    services.loadbalancers: "2"

这条配额把租户A的CPU请求总量压在10核、内存请求总量压在20Gi以内，没有这个边界，一个租户的Pod可以把整个集群的调度资源吃光。

K8s多租户资源隔离边界在哪：Namespace本身不是安全墙

行业共识认为,Namespace只解决逻辑分组，不解决网络隔离，很多刚上多租户的团队会踩这个坑：建了Namespace就以为租户之间互不可见，结果一个Pod用Service名字直接访问了另一个租户的数据库。

默认情况下,Kubernetes集群内所有Pod三层互通，跨命名空间的Service也可以解析，命令如下：

kubectl run test --rm -it --image=busybox -n tenant-a -- wget http://tenant-b-svc.tenant-b.svc.cluster.local

如果这个命令能返回内容,说明隔离边界还没画到网络层，所以K8s多租户资源隔离边界在哪？答案不是Namespace那一层，而是Namespace加上NetworkPolicy之后才算开始有效。

要堵住默认互通,需要给每个租户命名空间打上默认拒绝策略：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
  namespace: tenant-a
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

注意：NetworkPolicy必须由CNI插件实现，据CNCF官方文档，Calico、Cilium、Weave Net等主流CNI支持NetworkPolicy，但Flannel默认不启用该能力，如果集群用的是不支持的CNI，这段策略不会生效。

多租户集群资源隔离和单租户对比：哪种边界更划算

多租户共享集群和单租户独立集群的差异不在功能,而在隔离强度、故障域和成本结构，下面这张表可以直接对比：

从多租户集群资源隔离成本角度看,共享集群通常比独立集群便宜得多，控制面、etcd、监控组件都是摊销的，但便宜的代价是控制面一旦抖动，所有租户都会感受到，所以多数情况下，生产与测试至少分两个集群，测试集群再内部做多租户。

节点池与污点容忍：计算资源边界的实操切法

资源配额只能限制数量和总量,不能阻止两个租户的Pod调度到同一台物理节点上，如果租户B是个高负载批处理，它可能和租户A的在线服务抢CPU，这时候要用节点池和污点。

给租户A专用节点打标签：

kubectl label node worker-1 tenant=a

给租户A的Pod加调度约束：

spec:
  nodeSelector:
    tenant: a

或者更彻底,用污点排斥其他租户：

kubectl taint nodes worker-1 dedicated=tenantA:NoSchedule

租户A的Pod必须带上容忍才能调度上去：

spec:
  tolerations:
  - key: dedicated
    operator: Equal
    value: tenantA
    effect: NoSchedule

这样计算资源边界就从“命名空间级”下沉到了“节点级”，但污点容忍不是安全边界，如果租户的RBAC权限过大，可以自己修改Pod模板加上容忍，所以节点池必须配合RBAC和准入控制一起使用。

网络隔离边界：从默认互通到白名单切割

网络边界是多租户隔离里最容易出问题的地方,很多安全事件不是权限没配，而是Pod之间直接IP互通。

实际操作顺序应该是：

• 第一步,每个租户命名空间创建默认拒绝入站和出站的NetworkPolicy。
• 第二步,只放行同命名空间内部的Pod互访。
• 第三步,按需放行跨命名空间的特定流量，例如统一认证服务。

同命名空间放行示例：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-same-ns
  namespace: tenant-a
spec:
  podSelector: {}
  ingress:
  - from:
    - podSelector: {}
  egress:
  - to:
    - podSelector: {}

如果租户A需要访问租户B的某个API,不建议直接放行Pod IP，而应该通过Ingress或Gateway统一入口，共享Ingress Controller时，可以用不同的IngressClass或证书隔离租户域名，但Ingress Controller本身是集群级组件，它的配置错误会影响所有租户，更严格的隔离需要给高等级租户部署独立的Ingress Controller或Gateway实例。

存储与数据边界：PV/PVC的隔离漏洞怎么堵

PV是集群级资源,PVC是命名空间级资源，这个层级差就是问题源头。

一个常见的误配场景：StorageClass设置了volumeBindingMode: Immediate，并且PV回收策略是Retain，租户A删除PVC后，PV被释放但数据还在，如果PV没有被正确清理，租户B的PVC可能绑定到同一个PV上，读到上一家的数据。

堵法有两个：

• 给StorageClass设置volumeBindingMode: WaitForFirstConsumer，延迟绑定，让PVC只在Pod调度时绑定。
• 使用CSI驱动支持的静态加密,并限制PV的claimRef只能被原命名空间引用。

跨命名空间的数据恢复也要收敛,快照和克隆操作必须在PVC所在命名空间内完成，不允许租户A直接引用租户B的VolumeSnapshot，如果业务上必须跨命名空间复制数据，应当走独立的数据管道，而不是直接挂载同一个底层卷。

多租户集群资源隔离成本与容量边界：别让共享集群变成超卖池

共享集群节省成本的前提是容量边界清晰,没有配额的超卖集群，最后一定演变成租户抢资源、在线服务被打爆。

实操中建议这样控制：

• 用ResourceQuota限制每个租户的requests总量,确保调度器有资源可用。
• 用LimitRange限制单个Pod的requests和limits比值,避免某个Pod无限突发。
• 给高优租户配置PriorityClass,保证调度抢占时在线服务优先。
• 用PodDisruptionBudget限制驱逐速度,避免节点维护时一个租户全部Pod同时挂掉。

北京多租户集群资源隔离方案中,相当一部分团队会把生产集群和测试集群分开，测试集群做多租户超售，生产集群做严格隔离，这样既控制了成本，又避免测试租户的异常负载冲击生产服务。

控制面成本也需要纳入边界,共享集群的etcd和API Server承载所有租户的请求，如果租户数量过多，比如一个集群里塞了几百个命名空间，API Server的LIST请求会明显上升，此时应当设置API Priority and Fairness，限制每个租户的请求速率，避免一个租户的频繁查询拖垮整个控制面。

Q&A：关于多租户集群资源隔离边界的常见疑问

多租户集群资源隔离怎么做才能防止一个租户打爆节点？

给租户命名空间绑定ResourceQuota,限制总CPU和内存请求；再给节点打污点，把高负载租户的Pod限制在专用节点池，同时配置LimitRange约束单个容器最大资源，并用PriorityClass保证核心服务抢占时不被打爆。

K8s多租户资源隔离边界在哪一层最容易出现“假隔离”？

最容易出现在Namespace层,很多团队创建了Namespace就以为租户之间互不访问，但默认网络互通，跨命名空间的Service也可以解析，真正的隔离必须叠加NetworkPolicy、节点池、RBAC和存储策略，单靠Namespace是假隔离。

多租户集群资源隔离和单租户对比，什么情况下独立集群反而更省钱？

当租户数量少但安全合规要求高,或者需要独立升级K8s版本、独立配置审计策略时，独立集群避免了多租户隔离策略的维护成本和误配风险，一个租户一次安全事件带来的损失，可能远超多租户共享集群省下的那点运维费用。