📚 课程目录第3章 Cilium网络架构

3. Kubernetes 资源配额机制：ResourceQuota、LimitRange 与命名空间级别资源管控

在 Kubernetes 集群中，资源配额机制是保障多租户隔离、防止资源争抢的核心手段。对于运行 Cilium 网络拓扑的生产环境，合理的资源配额配置直接影响网络组件（如 cilium-agent、cilium-operator）的稳定性与性能。本节深入剖析 ResourceQuota、LimitRange 以及命名空间级别的资源管控策略。

3.1 ResourceQuota：硬性资源边界

ResourceQuota 对象为命名空间设定聚合资源上限，包括计算资源（CPU、内存）、存储资源（PVC 数量、总存储容量）以及对象数量（Pod、Service、ConfigMap 等）。当命名空间内资源使用量超过配额时，Kubernetes API Server 会拒绝后续创建请求。

资源类型	示例字段	说明
计算资源	`requests.cpu`, `limits.memory`	所有 Pod 的请求/限制总和上限
存储资源	`requests.storage`, `persistentvolumeclaims`	PVC 总容量与数量上限
对象数量	`count/pods`, `count/services`	命名空间内各类对象的最大数量
扩展资源	`requests.nvidia.com/gpu`	自定义扩展资源配额

  关键实践： 在 Cilium 网络拓扑中，务必为 kube-system 命名空间设置独立的 ResourceQuota，防止用户命名空间过度占用资源导致 cilium-agent Pod 因资源不足被驱逐。

apiVersion: v1
kind: ResourceQuota
metadata:
  name: cilium-critical-quota
  namespace: kube-system
spec:
  hard:
    requests.cpu: "4"
    requests.memory: "8Gi"
    limits.cpu: "8"
    limits.memory: "16Gi"
    count/pods: "50"
    count/services: "20"
    count/configmaps: "30"

3.2 LimitRange：默认资源约束与边界

LimitRange 对象在命名空间级别为 Pod 和容器设置默认资源请求/限制，以及最小/最大资源边界。它解决了两个关键问题：

默认值注入： 当用户未在 Pod Spec 中显式设置资源请求/限制时，LimitRange 自动注入默认值。
边界校验： 阻止创建超出最小/最大范围的容器，避免单个 Pod 耗尽命名空间配额。

LimitRange 类型	作用范围	典型配置
`Container`	单个容器	`default: { cpu: 500m, memory: 512Mi }`
`Pod`	整个 Pod	`max: { cpu: 2, memory: 4Gi }`
`PersistentVolumeClaim`	PVC 存储	`min: { storage: 1Gi }`

Cilium 适配建议： 为运行 Cilium 组件的命名空间设置 LimitRange 时，default 值应参考 Cilium 官方推荐的资源基线（如 cilium-agent 默认 request 为 100m CPU / 128Mi 内存），避免因默认值过低导致网络性能下降。

apiVersion: v1
kind: LimitRange
metadata:
  name: cilium-resource-limits
  namespace: kube-system
spec:
  limits:
  - max:
      cpu: "2"
      memory: "4Gi"
    min:
      cpu: "50m"
      memory: "64Mi"
    default:
      cpu: "500m"
      memory: "512Mi"
    defaultRequest:
      cpu: "100m"
      memory: "128Mi"
    type: Container

3.3 命名空间级别资源管控架构

下图展示了 ResourceQuota 与 LimitRange 在命名空间内的协同工作流程，以及它们如何影响 Cilium 网络组件的资源分配。

3.4 资源配额与 Cilium 网络拓扑的瓶颈分析

在 Cilium 网络拓扑中，资源配额配置不当会引发以下典型瓶颈：

cilium-agent 资源不足： 若 kube-system 命名空间 ResourceQuota 设置过小，cilium-agent DaemonSet 可能无法在所有节点上正常启动，导致网络连通性中断。
LimitRange 默认值冲突： 当 LimitRange 的 default 值高于 Cilium 组件实际需求时，会造成资源浪费；反之，若低于最低需求，则 Pod 启动失败。
对象数量配额限制： Cilium 使用大量 EndpointSlice、Service 和 ConfigMap 对象。若 count/services 或 count/endpointslices 配额不足，Cilium 将无法正确同步网络策略。

生产环境警告： 切勿在未评估 Cilium 组件资源基线的情况下，对 kube-system 命名空间施加过于严格的 ResourceQuota。建议先通过 kubectl top pod -n kube-system 观察实际资源消耗，再设定配额阈值（通常保留 20%-30% 的缓冲余量）。

3.5 多租户场景下的资源管控策略

对于多租户集群，推荐采用分层资源管控策略：

层级	管控对象	策略说明
集群级别	全局 ResourceQuota	限制所有命名空间的总资源使用量，防止单个租户影响全局
命名空间级别	命名空间 ResourceQuota + LimitRange	为每个租户命名空间设定独立配额与默认值
Pod 级别	Pod Spec 资源声明	用户显式设置 requests/limits，覆盖 LimitRange 默认值

  Helm 集成实践： 在 Helm Chart 的 values.yaml 中，将 ResourceQuota 和 LimitRange 作为可配置的子 Chart 或模板片段，通过 .Values.global.resourceQuota 和 .Values.global.limitRange 参数化，实现不同环境的差异化部署。

# Helm values.yaml 示例
global:
  resourceQuota:
    enabled: true
    hard:
      requests.cpu: "4"
      requests.memory: "8Gi"
      limits.cpu: "8"
      limits.memory: "16Gi"
  limitRange:
    enabled: true
    default:
      cpu: "500m"
      memory: "512Mi"
    defaultRequest:
      cpu: "100m"
      memory: "128Mi"