引言

在企业的容器化进程中，多个团队或项目共享同一个Kubernetes集群已成常态。但若缺乏有效的隔离措施，轻则引发资源争抢，重则导致数据泄露甚至服务雪崩。本文将针对网络、存储、资源三个核心维度，深入探讨Kubernetes多租户隔离的实战方案，并通过实际示例演示如何落地实施。

一、网络隔离：用策略守住流量边界

1.1 为什么需要网络隔离？

假设电商平台的订单服务（Team A）与风控系统（Team B）共享同一集群。若未做隔离，Team B的Pod可能意外调用Team A的敏感接口，导致业务逻辑错乱或数据泄露。

1.2 实现方案：NetworkPolicy

技术栈选择：Calico + Kubernetes原生NetworkPolicy

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: tenant-isolation
  namespace: default
spec:
  podSelector: {}  # 匹配当前命名空间所有Pod
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          tenant: team-a  # 仅允许来自team-a命名空间的流量
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          tenant: team-a  # 仅允许流向team-a命名空间

注释说明：

  • podSelector: {} 表示该策略作用于所有Pod
  • namespaceSelector 通过标签匹配租户所在的命名空间
  • 双向策略既限制入站（Ingress）也约束出站（Egress）
1.3 场景与注意事项
  • 适用场景：金融系统分级访问、多部门共享集群
  • 痛点解药：阻止跨租户扫描、未经授权的服务调用
  • 注意陷阱：CNI插件必须支持NetworkPolicy（如Calico/Cilium）

二、存储隔离：从卷权限到数据生命周期管理

2.1 存储泄漏的典型案例

某教育平台两个租户使用同一个存储卷，当租户A误删PVC时，租户B的数据库文件连带被清除，导致教学系统瘫痪8小时。

2.2 实现方案：StorageClass + PVC配额

技术栈组合：Rook Ceph + Kubernetes StorageClass

# 为租户创建专属StorageClass
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ceph-tenant-a
provisioner: rook-ceph.rbd.csi.ceph.com
parameters:
  clusterID: rook-ceph
  pool: tenant-a-pool  # 物理隔离存储池
  # 加密参数（可选）
  encryptionKMSID: "vault://tenant-a-keys"

---
# PVC声明绑定租户专属存储
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mysql-pvc
  namespace: team-a
spec:
  storageClassName: ceph-tenant-a  # 关键隔离点
  resources:
    requests:
      storage: 100Gi

注释亮点：

  • 通过不同StorageClass指向不同的Ceph存储池
  • 可选添加加密参数实现数据静态加密
  • 结合Quota限制PVC总容量（见第三部分）
2.3 高级技巧：数据清理自动化
# 命名空间删除时自动回收存储卷
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ceph-auto-delete
reclaimPolicy: Delete  # 与Retain策略对比

三、资源隔离：配额与限制的双重防线

3.1 CPU争夺引发的事故

某视频处理平台两个团队共享集群，租户A的转码任务耗尽节点CPU，导致租户B的实时推流服务产生卡顿。

3.2 实现方案：ResourceQuota + LimitRange

技术栈：Kubernetes原生资源管理

# 团队A的资源配额
apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-a-quota
  namespace: team-a
spec:
  hard:
    requests.cpu: "20"      # 总CPU请求量不超过20核
    limits.cpu: "40"        # 总CPU上限40核
    requests.memory: 100Gi  # 内存请求量限额
    pods: "200"             # 最大Pod数量

---
# 自动注入默认资源限制
apiVersion: v1
kind: LimitRange
metadata:
  name: default-limits
  namespace: team-a
spec:
  limits:
  - default:        # 默认上限
      cpu: 500m
      memory: 512Mi
    defaultRequest: # 默认请求量
      cpu: 100m
      memory: 128Mi
    type: Container

策略效果：

  • 租户无法绕过资源请求量声明
  • 单容器逃逸不会耗尽节点资源
  • 配额超限时触发实时拦截
3.3 动态资源调控进阶
# 使用Vertical Pod Autoscaler动态调整请求量
kubectl apply -f vpa.yaml --namespace=team-a

四、关联技术深潜：多租户的权限管控

4.1 RBAC授权模型实操
# 租户管理员角色定义
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: team-a
  name: tenant-admin
rules:
- apiGroups: [""]
  resources: ["pods", "services"]
  verbs: ["*"]
- apiGroups: ["networking.k8s.io"]
  resources: ["networkpolicies"]
  verbs: ["create", "delete"]

---
# 角色绑定到具体用户
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: team-a-binding
  namespace: team-a
subjects:
- kind: User
  name: "zhang@company.com"
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: tenant-admin
  apiGroup: rbac.authorization.k8s.io

五、方案全景分析

5.1 典型应用场景
  • 企业多部门共享集群（如研发/测试/预发环境）
  • 云服务商的SaaS产品底层架构
  • 混合云场景下的资源池化管理
5.2 技术选型优缺点
维度 优势 挑战
网络隔离 精确控制东西向流量 策略规则维护成本随规模上升
存储隔离 物理级数据隔离安全性高 存储集群配置复杂度较高
资源隔离 避免Noisy Neighbor问题 静态配额可能导致资源利用率不均
5.3 实施注意事项
  • 灰度发布策略：先在小范围命名空间试运行
  • 监控体系构建：Prometheus+Alertmanager监控配额使用率
  • 定期审计：检查NetworkPolicy的实际生效情况

六、总结

通过NetworkPolicy、StorageClass、ResourceQuota的三重组合拳，我们能够在共享的Kubernetes集群中构建出安全的多租户环境。但需注意：没有银弹方案，隔离粒度的选择需权衡安全与运维成本。建议从核心业务开始试点，逐步迭代完善隔离策略。