Kubernetes资源配额管理与多租户隔离方案

为什么Kubernetes资源配额管理不可忽视

Kubernetes集群在没有资源配额约束的情况下，单个命名空间的工作负载可以无限制占用CPU、内存和存储资源，导致邻居Pod被驱逐（Evicted）、节点OOM Killer触发、甚至整个节点NotReady。多租户场景下这个问题尤为严重——一个团队的压测任务可能直接打挂共享集群上的所有服务。

资源配额管理涉及三个层次：Request/Limit定义单个Pod的资源边界，LimitRange定义命名空间的默认值和极值，ResourceQuota定义命名空间的总资源上限。三层配合才能实现完整的资源隔离。

ResourceQuota配置与限制维度

ResourceQuota在命名空间维度限制资源总量，支持计算资源、存储资源、对象数量三个大类：

apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-frontend-quota
  namespace: team-frontend
spec:
  hard:
    requests.cpu: "16"
    requests.memory: 32Gi
    limits.cpu: "24"
    limits.memory: 48Gi
    requests.storage: 500Gi
    persistentvolumeclaims: "20"
    pods: "50"
    services: "10"
    secrets: "30"
    configmaps: "30"
    requests.nvidia.com/gpu: "4"

超出Quota的创建请求会被API Server直接拒绝（HTTP 403 Forbidden），不会进入调度流程。这意味着如果团队的CPU配额已经用满，新Pod无法创建，错误信息为exceeded quota。

LimitRange设置默认值与约束

LimitRange为命名空间中的Pod提供默认的Request/Limit值，防止开发者创建1m CPU / 16Gi内存这种畸形配置，同时也限制单个容器可申请的最大资源：

apiVersion: v1
kind: LimitRange
metadata:
  name: team-frontend-limits
  namespace: team-frontend
spec:
  limits:
  - type: Container
    default:
      cpu: "1"
      memory: 2Gi
    defaultRequest:
      cpu: 200m
      memory: 256Mi
    max:
      cpu: "4"
      memory: 8Gi
    min:
      cpu: 100m
      memory: 128Mi
    maxLimitRequestRatio:
      cpu: "5"
      memory: "3"

LimitRange和ResourceQuota的交互规则：当Pod未指定resources时，LimitRange的default值会被自动填充，同时该值计入ResourceQuota的已用配额。因此修改LimitRange的default值前必须评估对Quota余量的影响。

多租户隔离的三种架构模式

模式一：命名空间隔离（Soft Multi-tenancy）

不同团队使用不同命名空间，通过ResourceQuota和NetworkPolicy实现资源隔离和网络隔离。优点是管理简单，缺点是共享内核和容器运行时，安全性有限。

模式二：节点池隔离（Hard Multi-tenancy）

为高安全要求的租户分配专用节点池，通过Node Selector和Taint/Toleration确保只有该租户的Pod调度到对应节点。成本更高但隔离级别达到物理级别。

# 为安全租户标记专用节点
kubectl taint nodes node-pool-sec-01 tenant=secure:NoSchedule
kubectl label nodes node-pool-sec-01 tenant=secure-team

# 租户Pod配置容忍和亲和
spec:
  tolerations:
  - key: tenant
    operator: Equal
    value: secure
    effect: NoSchedule
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: tenant
            operator: In
            values: ["secure-team"]

模式三：虚拟集群隔离（Virtual Cluster）

使用vCluster等工具在每个命名空间中运行独立的虚拟Kubernetes控制平面，租户拥有完整的集群管理权限，但底层仍共享物理集群的资源。适合SaaS平台场景。

Pod优先级与抢占机制

当集群资源不足时，低优先级Pod会被抢占以释放资源给高优先级Pod。这是保证关键服务SLA的核心机制：

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: critical-service
value: 1000000
globalDefault: false
description: "生产核心服务，可抢占任意低优先级Pod"
preemptionPolicy: PreemptLowerPriority
---
apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: batch-job
value: 100
globalDefault: false
description: "离线批处理任务，可被任意高优先级Pod抢占"
preemptionPolicy: PreemptLowerPriority

抢占流程：调度器发现高优先级Pod无法调度，遍历所有节点寻找可抢占的低优先级Pod组合，选择影响最小的抢占方案，删除被抢占的Pod，调度高优先级Pod。被抢占的Pod会收到SIGTERM信号，有优雅终止期（默认30秒）。

资源配额审计与告警

配额管理的闭环是持续的审计和告警：

– 配额利用率监控：通过kube-resourcequota Exporter将ResourceQuota的使用率暴露给Prometheus，设置80%阈值告警

– 配额审计报表：定期统计各命名空间的实际资源消耗与Quota的比值，识别浪费或过度分配

– LimitRange违规检测：通过Kyverno或OPA Gatekeeper策略引擎，拒绝创建超出LimitRange约束的工作负载，并输出违规报告

运维友好的做法是为每个命名空间打上team和cost-center标签，配合Kubecost实现按团队的成本分摊和资源效率分析。