📚 课程目录第4章命名空间与资源配额基线

4. 命名空间与资源配额基线：命名空间设计原则、ResourceQuota 配置、LimitRange 配置

在 Kubernetes 多租户或微服务架构中，命名空间（Namespace）是隔离与资源管控的第一道防线。值班基线核验要求平台团队必须为每个业务单元、环境或团队建立清晰的命名空间边界，并配套 ResourceQuota 与 LimitRange 策略，防止单个应用或团队过度消耗集群资源，保障整体稳定性。

4.1 命名空间设计原则

命名空间不应随意创建，而应遵循以下基线原则：

环境隔离：按环境（dev、staging、prod）划分命名空间，避免混用导致配置污染。
团队/业务域边界：每个独立团队或业务线拥有专属命名空间，配合 RBAC 实现权限隔离。
共享服务独立：监控、日志、Ingress Controller 等基础设施组件应部署在独立命名空间（如 kube-system、monitoring、ingress-nginx）。
避免深度嵌套：命名空间是扁平结构，不要试图用命名空间模拟目录树；业务层级通过标签（Label）表达。
标准化命名：采用 <团队>-<环境> 或 <业务>-<阶段> 格式，例如 payment-prod、data-staging。

值班核验要点：巡检时应检查是否存在未绑定 ResourceQuota 的命名空间，以及是否存在长期空置或废弃的命名空间。建议使用 kubectl get ns --show-labels 快速审查。

4.2 ResourceQuota 配置

ResourceQuota 用于限制命名空间级别的总资源消耗，包括 CPU、内存、存储卷数量、对象数量（如 Pod、Service、ConfigMap 等）。值班基线要求每个非基础设施命名空间必须绑定至少一个 ResourceQuota。

4.2.1 核心配置字段

资源类型	字段示例	说明
CPU 总量	`requests.cpu: "8"`	所有 Pod 的 CPU request 总和上限
内存总量	`requests.memory: "16Gi"`	所有 Pod 的内存 request 总和上限
CPU 上限	`limits.cpu: "16"`	所有 Pod 的 CPU limit 总和上限
内存上限	`limits.memory: "32Gi"`	所有 Pod 的内存 limit 总和上限
Pod 数量	`count/pods: "50"`	命名空间内允许的最大 Pod 数量
Service 数量	`count/services: "20"`	命名空间内允许的最大 Service 数量
存储卷声明	`requests.storage: "100Gi"`	所有 PVC 的存储总量上限

4.2.2 典型 ResourceQuota 配置示例

apiVersion: v1
kind: ResourceQuota
metadata:
  name: payment-prod-quota
  namespace: payment-prod
spec:
  hard:
    requests.cpu: "8"
    requests.memory: "16Gi"
    limits.cpu: "16"
    limits.memory: "32Gi"
    count/pods: "50"
    count/services: "20"
    count/configmaps: "30"
    count/secrets: "30"
    requests.storage: "100Gi"
    persistentvolumeclaims: "10"

常见陷阱：仅配置 limits 而不配置 requests 会导致调度器无法准确计算资源压力；建议始终同时设置 requests 和 limits。另外，ResourceQuota 不限制 DaemonSet 或静态 Pod 的资源，需额外关注。

4.3 LimitRange 配置

LimitRange 用于在命名空间级别设置单个 Pod 或容器的默认资源请求/限制以及取值范围。它与 ResourceQuota 配合形成“上限+下限”的双重管控：ResourceQuota 管总量，LimitRange 管个体。

4.3.1 LimitRange 策略类型

策略类型	作用对象	典型用途
`Container`	单个容器	设置容器默认 request/limit，防止未设置资源限制的 Pod 运行
`Pod`	整个 Pod	限制 Pod 内所有容器资源总和的最小/最大值
`PersistentVolumeClaim`	存储卷声明	限制 PVC 的最小/最大存储容量

4.3.2 典型 LimitRange 配置示例

apiVersion: v1
kind: LimitRange
metadata:
  name: payment-prod-limits
  namespace: payment-prod
spec:
  limits:
  - type: Container
    default:
      cpu: "500m"
      memory: "512Mi"
    defaultRequest:
      cpu: "200m"
      memory: "256Mi"
    max:
      cpu: "2"
      memory: "2Gi"
    min:
      cpu: "50m"
      memory: "64Mi"
  - type: PersistentVolumeClaim
    max:
      storage: "50Gi"
    min:
      storage: "1Gi"

  基线核验逻辑：当 Pod 未显式设置资源 request/limit 时，LimitRange 会自动注入默认值。如果 Pod 的资源配置超出 max 或低于 min，API Server 将拒绝创建。值班人员应定期检查 kubectl describe limitrange -n <ns> 确认策略是否生效。

4.4 值班核验清单

值班人员在对命名空间与资源配额进行基线核验时，应逐项确认以下内容：

命名空间清单：使用 kubectl get ns 检查是否存在未标注用途的命名空间。
ResourceQuota 绑定：每个业务命名空间是否至少有一个 ResourceQuota 对象。
LimitRange 配置：是否配置了默认资源限制，防止 Pod 因未设置资源而无限使用。
配额使用率：使用 kubectl describe quota -n <ns> 查看当前使用量是否接近硬限制（建议预留 20% 缓冲）。
异常 Pod 排查：查找因资源配额不足而处于 Pending 状态的 Pod，及时扩容或清理。
存储配额：检查 PVC 数量与存储总量是否在配额范围内，避免存储突增导致集群故障。

快速命令：kubectl get quota --all-namespaces 可一次性查看所有命名空间的配额定义；kubectl describe quota -n <ns> 可查看当前使用量与硬限制的对比。

4.5 常见问题与避坑指南

问题场景	原因	解决方案
Pod 一直 Pending，无事件提示	ResourceQuota 达到上限，但未显示明确错误	执行 `kubectl describe quota` 查看使用量
LimitRange 未生效	Pod 所属命名空间未创建 LimitRange 对象	检查 `kubectl get limitrange -n <ns>`
ResourceQuota 与 LimitRange 冲突	LimitRange 的 max 大于 ResourceQuota 的硬限制	确保 LimitRange 的 max ≤ ResourceQuota 的硬限制
存储配额不足导致 PVC 创建失败	`requests.storage` 或 `persistentvolumeclaims` 达到上限	调整 ResourceQuota 或清理未使用的 PVC

通过以上命名空间设计原则、ResourceQuota 与 LimitRange 的配置实践，平台团队可以构建一套可审计、可预测、可扩展的资源管控基线，有效降低值班期间的故障响应压力。