多租户集群资源隔离的边界不是一道静态的墙，而是从命名空间、节点池、网络策略到存储卷逐层收紧的切割线；判断边界是否有效，只看一个动作：租户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，这段策略不会生效。
多租户集群资源隔离和单租户对比：哪种边界更划算
多租户共享集群和单租户独立集群的差异不在功能,而在隔离强度、故障域和成本结构，下面这张表可以直接对比：
| 对比维度 | 多租户共享集群 | 单租户独立集群 |
|---|---|---|
| 资源利用率 | 高，闲置资源可复用 | 低，每个集群都有控制面开销 |
| 故障爆炸半径 | 控制面故障影响所有租户 | 局限于单个租户 |
| 安全隔离强度 | 依赖策略配置，弱于物理隔离 | 物理级隔离，强合规友好 |
| 运维成本 | 低，一套控制面多租户分摊 | 高，多个集群独立维护 |
| 升级灵活性 | 所有租户绑在同一K8s版本 | 可按租户独立升级 |
| 适用场景 | 内部团队、测试环境、中小规模SaaS | 金融、医疗、强监管行业 |
从多租户集群资源隔离成本角度看,共享集群通常比独立集群便宜得多，控制面、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版本、独立配置审计策略时，独立集群避免了多租户隔离策略的维护成本和误配风险，一个租户一次安全事件带来的损失，可能远超多租户共享集群省下的那点运维费用。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/641785.html
