📚 课程目录第3章 Namespace隔离

3. Namespace隔离：Namespace作用、资源配额（ResourceQuota）、LimitRange配置

在多租户Kubernetes集群中，Namespace是隔离的第一道防线。它并非安全边界（不提供网络或节点级隔离），但却是资源配额、访问控制和策略绑定的逻辑单元。本章深入剖析Namespace的核心作用，并重点讲解如何通过ResourceQuota和LimitRange实现租户间的资源公平性与稳定性。

3.1 Namespace的核心作用

Namespace将集群物理资源划分为多个虚拟集群，每个租户或团队拥有独立的命名空间。其核心作用包括：

资源隔离：Pod、Service、ConfigMap等资源在Namespace内名称唯一，不同Namespace可重名。
配额绑定：ResourceQuota和LimitRange必须关联到特定Namespace，实现租户级资源上限。
策略作用域：NetworkPolicy、PodSecurityPolicy（或PSA）可限定在Namespace内生效。
访问控制：RBAC Role/ClusterRole可精确控制用户对Namespace的读写权限。

最佳实践： 生产环境建议为每个租户创建独立的Namespace，命名规范如 tenant-{name}-{env}，并配合标签（如 tenant: acme）便于审计和自动化管理。

3.2 ResourceQuota：硬性资源上限

ResourceQuota为Namespace设置累计资源消耗上限，防止单个租户耗尽集群资源。支持对计算资源（CPU/内存）、存储资源（PVC容量/数量）和对象数量（Pod/Service/ConfigMap等）进行限制。

3.2.1 核心配置字段

资源类型	字段示例	说明
CPU（请求）	`requests.cpu`	所有Pod CPU请求总和上限
CPU（限制）	`limits.cpu`	所有Pod CPU限制总和上限
内存（请求）	`requests.memory`	所有Pod内存请求总和上限
内存（限制）	`limits.memory`	所有Pod内存限制总和上限
存储总量	`requests.storage`	所有PVC存储请求总和上限
PVC数量	`persistentvolumeclaims`	Namespace内PVC最大数量
Pod数量	`pods`	Namespace内活跃Pod最大数量
Service数量	`services`	Namespace内Service最大数量

3.2.2 配置示例

apiVersion: v1
kind: ResourceQuota
metadata:
  name: tenant-quota
  namespace: tenant-acme-prod
spec:
  hard:
    requests.cpu: "4"
    requests.memory: "8Gi"
    limits.cpu: "8"
    limits.memory: "16Gi"
    requests.storage: "50Gi"
    persistentvolumeclaims: "10"
    pods: "20"
    services: "10"
    configmaps: "30"

注意： ResourceQuota仅限制创建时的资源总和。如果Namespace内已有资源超过新设置的Quota，Kubernetes不会自动驱逐已有Pod，但会阻止新Pod创建。建议在租户入驻前预先配置Quota。

3.3 LimitRange：单个Pod的资源约束

ResourceQuota控制总和，而LimitRange控制单个Pod/容器的资源范围。它确保租户内的每个Pod不会申请过大或过小的资源，同时为未显式设置资源请求/限制的Pod提供默认值。

3.3.1 核心配置字段

策略类型	字段	说明
最小资源	`min`	Pod/容器资源请求或限制的最小值
最大资源	`max`	Pod/容器资源请求或限制的最大值
默认请求	`defaultRequest`	容器未设置请求时的默认值
默认限制	`default`	容器未设置限制时的默认值
比例约束	`maxLimitRequestRatio`	限制/请求的最大比例（如CPU 2.0表示限制不能超过请求的2倍）

3.3.2 配置示例

apiVersion: v1
kind: LimitRange
metadata:
  name: tenant-limits
  namespace: tenant-acme-prod
spec:
  limits:
  - max:
      cpu: "2"
      memory: "4Gi"
    min:
      cpu: "100m"
      memory: "128Mi"
    default:
      cpu: "500m"
      memory: "512Mi"
    defaultRequest:
      cpu: "200m"
      memory: "256Mi"
    maxLimitRequestRatio:
      cpu: "4"
    type: Container

  关键行为： LimitRange在Pod创建时强制校验并自动注入默认值。如果Pod的某个容器资源声明超出min/max范围，API Server会拒绝创建。这有效防止了租户内个别Pod“资源暴走”。

3.4 ResourceQuota与LimitRange协同工作流

下图展示了在Namespace内，ResourceQuota和LimitRange如何共同作用于Pod的创建过程：

3.5 多租户场景下的配置策略

在实际多租户集群中，推荐采用分层配额策略：

集群级默认配额：为每个新Namespace自动创建ResourceQuota和LimitRange模板（通过Admission Webhook或Operator实现）。
租户级定制：根据租户SLA调整配额值，例如付费租户获得更高CPU/内存上限。
动态调整：监控Namespace实际使用率，定期调整Quota，避免资源碎片。

  避坑指南：
  ResourceQuota和LimitRange必须同时配置，否则可能出现“Pod无限制但Quota已满”的尴尬局面。
LimitRange的maxLimitRequestRatio可防止租户设置过高的突发资源（如CPU限制=请求的10倍），建议生产环境设置ratio ≤ 4。
存储类（StorageClass）的配额需额外通过requests.storage和persistentvolumeclaims控制，不同存储类可分别设置。

3.6 验证与排障

常用命令一览：

命令	用途
`kubectl get resourcequota -n <ns>`	查看Namespace的ResourceQuota及当前使用量
`kubectl describe resourcequota <name> -n <ns>`	查看配额详细使用情况（Used/Hard）
`kubectl get limitrange -n <ns>`	查看Namespace的LimitRange配置
`kubectl describe limitrange <name> -n <ns>`	查看LimitRange详细约束规则
`kubectl run test-pod --image=busybox --restart=Never -- /bin/sh -c "sleep 10" -n <ns>`	快速测试Pod能否在Namespace内创建（验证Quota/LimitRange）

常见错误： 如果Pod创建失败并提示 exceeded quota 或 forbidden: minimum memory usage，请首先检查Namespace的ResourceQuota和LimitRange配置。使用 kubectl describe quota -n <ns> 查看当前使用量是否已达硬限制。

3.7 小结

Namespace、ResourceQuota和LimitRange构成了多租户Kubernetes集群资源隔离的三驾马车：

Namespace：逻辑隔离单元，资源配额和策略的绑定目标。
ResourceQuota：Namespace级别的资源总和上限，防止租户整体资源滥用。
LimitRange：Pod/容器级别的资源范围约束，防止单个Pod资源异常。