📚 课程目录第4章 Kubernetes资源配额机制

4. Kubernetes 资源配额机制：ResourceQuota 对象、LimitRange 对象、Pod 优先级与抢占、命名空间隔离

在 Cilium 网络拓扑中，资源配额机制是保障多租户环境下网络策略与数据路径稳定性的关键底层设施。本章深入剖析 Kubernetes 原生资源管控的四大核心组件，并分析其在 Cilium 环境下的瓶颈表现。

4.1 ResourceQuota 对象：命名空间级资源硬边界

ResourceQuota 为每个命名空间设置聚合资源上限，防止单个租户耗尽集群资源。在 Cilium 网络拓扑中，ResourceQuota 直接影响 CNI 组件的调度与网络策略代理的可用性。

资源类型	配额字段	Cilium 场景影响
计算资源	requests.cpu / requests.memory limits.cpu / limits.memory	Cilium-agent 与 Envoy 代理的 Pod 资源预留不足时，网络策略处理延迟上升
存储资源	requests.storage / persistentvolumeclaims	Cilium 监控日志与 Hubble 数据持久化受限
对象数量	count/endpoints / count/services / count/secrets	Service 与 Endpoint 数量超限导致 Cilium 服务映射表膨胀，转发性能下降
扩展资源	requests.nvidia.com/gpu	GPU 节点上的 Cilium 网络策略卸载能力受限

  瓶颈分析： 当 ResourceQuota 设置过紧时，Cilium-agent 的 sidecar 或 DaemonSet Pod 可能因资源不足被驱逐，导致该节点上的网络策略失效。建议为 kube-system 命名空间预留独立配额池。

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/endpoints: "5000"
    count/services: "1000"

4.2 LimitRange 对象：Pod 与容器级资源约束

LimitRange 在命名空间级别为每个 Pod 或容器设置默认资源请求/限制以及最小/最大值。在 Cilium 网络拓扑中，LimitRange 直接影响 Init 容器（如 cilium-init）和 sidecar 代理的资源分配。

默认请求（defaultRequest）： 当 Pod 未显式设置资源时，自动注入默认值。Cilium 的 Init 容器若未设置资源，可能被分配过小值导致启动超时。
最大限制（max）： 防止单个 Pod 抢占过多资源，但过小的 max 值可能限制 Cilium-agent 的 BPF map 内存分配。
最小请求（min）： 确保每个 Pod 有基础资源保障，但若 min 值高于 Cilium sidecar 实际需求，会造成资源浪费。
比例约束（maxLimitRequestRatio）： 控制 limit/request 比例，防止突发流量下 Cilium 代理 OOM。

实践建议： 在 Cilium 部署的命名空间中，LimitRange 的 max.memory 不应低于 512Mi，否则 Cilium-agent 的 BPF map 初始化可能失败。建议为 Init 容器单独设置 type: Pod 的 LimitRange。

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

4.3 Pod 优先级与抢占：保障关键网络组件调度

Pod 优先级（PriorityClass）与抢占（Preemption）机制确保高优先级 Pod 在资源竞争时能够驱逐低优先级 Pod。在 Cilium 网络拓扑中，此机制对控制面组件和数据面代理的可用性至关重要。

关键风险： 若 Cilium-agent 的 PriorityClass 未设置为集群最高优先级，当节点资源紧张时，Cilium-agent 可能被低优先级但抢占能力更强的 Pod 驱逐，导致整个节点的网络中断。务必为 kube-system 命名空间中的 Cilium 组件设置 priorityClassName: system-cluster-critical。

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: cilium-critical
value: 1000000
globalDefault: false
description: "Highest priority for Cilium network components"

4.4 命名空间隔离：网络策略与资源配额的协同

命名空间隔离是 Kubernetes 多租户的基础，ResourceQuota 与 LimitRange 在命名空间级别生效，与 Cilium 网络策略（CiliumNetworkPolicy）形成双层防护。

资源隔离： 每个命名空间拥有独立的 ResourceQuota，防止租户 A 的突发流量挤占租户 B 的 Cilium-agent 资源。
网络隔离： CiliumNetworkPolicy 基于命名空间标签实现细粒度流量控制，与 ResourceQuota 的对象数量限制协同工作。
优先级隔离： 不同命名空间可设置不同的 PriorityClass，确保关键租户的网络组件优先调度。
监控隔离： Hubble 在每个命名空间独立采集流量指标，ResourceQuota 的 count/endpoints 限制影响 Hubble 的数据采集范围。

4.5 瓶颈分析总结：Helm 部署中的配额配置策略

在 Helm Chart 中管理 Cilium 资源配额时，需注意以下瓶颈点：

组件	常见瓶颈	Helm 配置建议
ResourceQuota	count/endpoints 过小导致 Cilium 服务映射表溢出	在 values.yaml 中设置 `global.quotas.endpoints: 10000`
LimitRange	Init 容器资源不足导致 Cilium 启动失败	通过 `initContainers.resources` 显式覆盖默认值
PriorityClass	Cilium-agent 被低优先级 Pod 抢占	设置 `priorityClassName: system-cluster-critical`
命名空间隔离	跨命名空间 ResourceQuota 不均衡导致 Cilium 控制面过载	使用 `helm install --namespace` 隔离部署

  核心结论： ResourceQuota 与 LimitRange 是 Cilium 网络拓扑稳定性的“隐形护栏”。在 Helm Chart 中，必须将配额参数暴露为可配置的 values，并在部署前根据节点规模与网络策略复杂度进行预计算。Pod 优先级与抢占机制是最后一道防线，确保 Cilium 控制面组件在资源竞争时不被驱逐。