4. 资源边界概念：Namespace资源配额、LimitRange、Pod资源请求/限制、节点资源拓扑
在Kubernetes集群中，资源边界是保障多租户隔离、防止“吵闹邻居”效应、确保Operator控制面在SLO违约后仍能稳定运行的核心机制。本章将系统梳理从Namespace级到Pod级、再到节点级的资源边界定义与拓扑关系。
4.1 资源边界分层模型
Kubernetes的资源边界自顶向下分为四层：Namespace配额层、LimitRange默认值层、Pod资源请求/限制层、节点资源拓扑层。每一层都承担不同的职责，共同构成完整的资源管控体系。
核心原则：上层边界是下层边界的“硬天花板”，下层边界是上层边界的“实际消耗”。Namespace配额不能超过集群总容量，Pod的requests不能超过Namespace剩余配额。
4.2 Namespace资源配额（ResourceQuota）
ResourceQuota是Namespace级别的资源总量限制，用于防止单个Namespace耗尽集群资源。当Operator控制面发生SLO违约时，配额机制可以阻止异常Pod无限扩张。
| 配额类型 | 资源名称 | 说明 |
|---|---|---|
| 计算资源 | requests.cpu / requests.memory |
所有Pod的requests总和上限 |
limits.cpu / limits.memory |
所有Pod的limits总和上限 | |
| 存储资源 | requests.storage |
所有PVC的存储请求总和上限 |
persistentvolumeclaims |
PVC数量上限 | |
| 对象数量 | pods / services / configmaps |
各类K8s对象数量上限 |
最佳实践：Operator控制面Namespace应设置严格的ResourceQuota，特别是
limits.cpu和limits.memory，防止Operator Pod内存泄漏导致集群级故障。
ResourceQuota示例
apiVersion: v1
kind: ResourceQuota
metadata:
name: operator-control-quota
namespace: operator-system
spec:
hard:
requests.cpu: "8"
requests.memory: "16Gi"
limits.cpu: "16"
limits.memory: "32Gi"
pods: "20"
persistentvolumeclaims: "5"
configmaps: "50"4.3 LimitRange：默认值与边界约束
LimitRange在Namespace级别为Pod和Container设置资源默认值及最小/最大边界。当Pod未显式设置资源请求/限制时，LimitRange会自动注入默认值；同时，LimitRange会拒绝超出边界的Pod创建请求。
| LimitRange类型 | 作用范围 | 关键字段 |
|---|---|---|
| Container | 单个容器 | default / defaultRequest / min / max |
| Pod | Pod内所有容器总和 | min / max（作用于Pod级别） |
| PersistentVolumeClaim | 存储请求 | min / max（存储容量） |
LimitRange示例
apiVersion: v1
kind: LimitRange
metadata:
name: operator-limit-range
namespace: operator-system
spec:
limits:
- type: Container
default:
cpu: "1"
memory: "2Gi"
defaultRequest:
cpu: "500m"
memory: "1Gi"
min:
cpu: "100m"
memory: "256Mi"
max:
cpu: "4"
memory: "8Gi"
- type: PersistentVolumeClaim
min:
storage: "1Gi"
max:
storage: "100Gi"
注意：LimitRange的
min/max是硬边界，超出范围的Pod创建请求会被API Server直接拒绝。Operator在SLO违约后尝试扩容时，必须确保新Pod的资源声明在LimitRange范围内。
4.4 Pod资源请求/限制与QoS模型
Pod的资源请求（requests）和限制（limits）决定了调度决策、资源竞争时的优先级以及QoS（服务质量）等级。Kubernetes根据requests和limits的配置关系，将Pod划分为三种QoS等级：
- Guaranteed：所有容器requests == limits，且至少设置一种资源。优先级最高，不会被OOM Killer优先杀死。
- Burstable：至少一个容器requests < limits，或只设置了requests。中等优先级。
- BestEffort：所有容器均未设置requests和limits。优先级最低，节点资源紧张时最先被驱逐。
| QoS等级 | 配置条件 | 资源保障 | 驱逐优先级 |
|---|---|---|---|
| Guaranteed | requests == limits（所有容器） | 完全保障 | 最低（最后被驱逐） |
| Burstable | requests < limits 或仅设置requests | 部分保障 | 中等 |
| BestEffort | 未设置requests和limits | 无保障 | 最高（最先被驱逐） |
Operator控制面建议：核心Operator Pod应配置为Guaranteed QoS等级，确保在节点资源竞争时不会被优先驱逐。非关键辅助Pod可配置为Burstable，以平衡资源利用率和稳定性。
4.5 节点资源拓扑
节点资源拓扑描述了集群中每个节点的资源容量、已分配资源、可分配资源以及资源碎片情况。在SLO违约后的资源边界处置中，节点拓扑信息用于判断是否可以通过节点内资源重调度来恢复SLO，还是必须触发节点级或集群级扩缩容。
4.6 资源边界综合对比
| 边界层级 | 作用范围 | 强制执行时机 | SLO违约时的作用 |
|---|---|---|---|
| ResourceQuota | Namespace | Pod创建/更新时 | 阻止Namespace内资源超限，防止故障扩散 |
| LimitRange | Namespace | Pod创建/更新时 | 确保Pod资源声明在合理范围内，避免极端配置 |
| Pod requests/limits | Pod/Container | 调度时 + 运行时 | 决定QoS等级和驱逐优先级，保障关键Pod |
| 节点资源拓扑 | Node | 调度时 + 运行时 | 提供资源视图，指导重调度或扩缩容决策 |