1. 引言为什么需要资源限制在 Kubernetes 集群中节点资源CPU、内存、存储等是有限的。如果没有资源限制机制可能会出现以下问题“吵闹的邻居”一个 Pod 的无限制内存使用可能导致节点 OOMOut of Memory进而触发内核杀死关键系统进程或其他 Pod。资源分配不均开发测试环境可能因为某个 Bug 耗尽所有 CPU导致生产服务响应缓慢。调度混乱调度器无法基于准确的资源需求进行决策导致节点负载过高。因此Kubernetes 提供了一套多层次的资源管理机制从Pod/Container粒度的资源声明到Namespace粒度的配额控制再到QoS保障的驱逐优先级帮助集群管理员和开发者实现资源的精细化管控。2. Kubernetes 资源模型核心概念2.1 可压缩资源与不可压缩资源Kubernetes 将资源分为两类类型定义代表资源超限行为可压缩资源资源超限时进程只会被节流Throttle不会被杀死CPUCPU 使用超过 Limits 时内核 Cgroups 限制其时间片进程运行变慢不可压缩资源资源超限时进程可能会被终止内存、磁盘内存使用超过 Limits 时触发 OOM Kill超过 Requests 但低于 Limits 时面临被驱逐风险2.2 Requests 与 Limits 的定义Requests请求Pod 调度时调度器会确保节点上有满足所有 Pod Requests 总和的可分配资源。它代表“保证使用量”。Limits限制Pod 运行时Cgroups 允许使用的资源上限。它代表“最大使用量”。关系解读如果只设置 Limits 未设置 RequestsKubernetes 默认将 Requests 设置为 Limits 的值若存在 LimitRange 则另论。如果只设置 Requests 未设置 LimitsPod 理论上可以使用节点上所有空闲资源但在资源紧张时可能被驱逐。2.3 资源单位详解CPU单位m(millicores)1代表 1 个 CPU 核心或一个 vCPU / 一个 Hyperthread500m代表 0.5 个 CPU 核心最小精度1m(某些环境支持更精细但不推荐)Memory单位Ki(Kibibytes),Mi(Mebibytes),Gi(Gibibytes)例如512Mi2Gi注意使用MMegabyte与Mi的区别Kubernetes 中默认使用二进制单位Mi。3. 第一层防线Pod 与 Container 级别3.1 Container 资源定义每个 Container 是资源消耗的最小单元。在 Pod Spec 中通过resources字段定义yamlapiVersion: v1 kind: Pod metadata: name: resource-demo spec: containers: - name: app image: nginx resources: requests: memory: 64Mi cpu: 250m limits: memory: 128Mi cpu: 500m关键点调度依据调度器仅检查requests。如果节点剩余可分配资源Allocatable小于 Pod 的requestsPod 将保持 Pending 状态。运行时强制limits由 Cgroups 强制实施。如果内存超过limitsContainer 会被 OOMKilled如果 CPU 超过limits会被 Throttled。3.2 Pod 级别聚合与 Init Container 特殊处理Pod 总资源Pod 的资源需求是其所有 Container Requests/Limits 的总和。Init Container初始化容器调度时调度器会选择满足所有 Init Container 中最大 Requests的节点因为 Init Container 是串行执行且执行完即释放资源。资源计算示例Init Container A: CPU 请求 1 核Init Container B: CPU 请求 2 核主容器: CPU 请求 0.5 核调度时的节点需求取 Init Container 最大值2 核 所有主容器总和0.5 核 2.5 核。4. 第二层防线Namespace 级别ResourceQuotaResourceQuota 限制了 Namespace 内所有 Pod 的资源总和防止某个 Namespace 过度消耗集群资源。4.1 ResourceQuota 核心配置yamlapiVersion: v1 kind: ResourceQuota metadata: name: compute-quota namespace: team-a spec: hard: requests.cpu: 8 # 所有 Pod Requests CPU 总和 8核 requests.memory: 16Gi # 所有 Pod Requests 内存总和 16Gi limits.cpu: 16 # 所有 Pod Limits CPU 总和 16核 limits.memory: 32Gi # 所有 Pod Limits 内存总和 32Gi persistentvolumeclaims: 5 # PVC 数量限制 pods: 20 # Pod 数量限制注意如果 Namespace 启用了 ResourceQuota所有 Pod 必须设置 Resource Requests/Limits除非同时配置了 LimitRange 提供默认值。创建 Pod 时如果累计总和超过 QuotaAPI Server 会返回403 Forbidden。4.2 动态扩容与 ScopeSelectorScopeSelector允许你根据 Pod 的状态如Terminating、NotTerminating或 QoS 等级来设置不同的配额。yamlspec: scopes: - Terminating # 仅统计正在终止的 Pod - NotTerminating # 仅统计非终止 Pod scopeSelector: matchExpressions: - operator: In scopeName: PriorityClass values: [high-priority]最佳实践通常将 Quota 分为两类计算型 Quota限制requests.cpu/memory和limits.cpu/memory。对象型 Quota限制pods、services、configmaps数量。4.3 配额计算与耗尽处理ResourceQuota 的计算是基于Pod 当前状态的乐观并发控制。当 Pod 处于Pending状态时就会占用配额。如果配额不足kubectl describe quota会显示Used和Hard字段。集群管理员需要增加配额或等待其他资源释放Pod 删除。5. 第三层防线Namespace 级别LimitRangeLimitRange 为 Namespace 内的资源声明提供默认值和约束范围防止用户创建过小浪费调度资源或过大影响稳定性的 Pod。5.1 默认请求与限制很多开发者嫌麻烦只写镜像不写资源LimitRange 可以注入默认值。yamlapiVersion: v1 kind: LimitRange metadata: name: default-limits namespace: team-a spec: limits: - type: Container default: # 如果未定义 Limits使用此值 cpu: 500m memory: 1Gi defaultRequest: # 如果未定义 Requests使用此值 cpu: 200m memory: 256Mi max: cpu: 2 memory: 4Gi min: cpu: 100m memory: 128Mi5.2 最小/最大约束min和max强制了 Pod 的资源范围。例如如果用户试图创建一个memory request64Mi的 Pod会被拒绝因为低于min: 128Mi。5.3 与 ResourceQuota 的协同LimitRange解决的是“个体合规”问题每个 Pod 不能太大或太小必须有默认值。ResourceQuota解决的是“总量控制”问题所有 Pod 总和不能超标。典型生产配置流程创建 Namespace。应用 LimitRange保证每个 Pod 都有资源声明且符合最小规格。应用 ResourceQuota限制该团队总消耗。6. 应用层抽象Deployment 中的资源配置虽然 Pod 是基础但在生产环境中我们通常通过 Deployment 管理 Pod。6.1 模板内资源声明在 Deployment 的spec.template.spec.containers中声明资源与独立 Pod 写法一致。yamlapiVersion: apps/v1 kind: Deployment metadata: name: my-app spec: replicas: 3 strategy: type: RollingUpdate rollingUpdate: maxSurge: 1 maxUnavailable: 0 template: metadata: labels: app: my-app spec: containers: - name: app image: myapp:v1 resources: requests: cpu: 500m memory: 1Gi limits: cpu: 1 memory: 2Gi6.2 滚动更新与资源预留在滚动更新期间新旧 Pod 会短暂共存。这要求 Namespace 的 ResourceQuota 必须预留足够的余量否则更新可能失败。公式Quota 剩余 (maxSurge * Pod 资源需求)如果 Quota 不足新 Pod 无法创建滚动更新会卡住。6.3 HPA水平自动伸缩与资源指标的联动HPA 通常基于cpu或memory利用率进行扩缩容。yamlapiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: my-app-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: my-app minReplicas: 2 maxReplicas: 10 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 70关键HPA 依赖requests来计算利用率。利用率 (当前使用量 / requests) * 100%如果requests设置过低HPA 会过早扩容设置过高则可能永远无法扩容。7. 深度机制QoS服务质量等级Kubernetes 根据 Pod 的 Requests 和 Limits 配置自动为 Pod 分配 QoS 等级Guaranteed / Burstable / BestEffort。QoS 决定了在资源紧张时节点压力驱逐Pod 被驱逐的优先级。7.1 Guaranteed最高优先级最后被驱逐条件每个 Container 都设置了内存和 CPU 的requests和limits。每个 Container 的requests等于limits内存和 CPU 分别相等。特征只要不超限几乎不会被驱逐。是生产环境核心服务如数据库、网关的理想选择。7.2 Burstable中等优先级条件至少有一个 Container 设置了requests或limits但不满足 Guaranteed 条件。特征允许 Pod 在空闲时使用超出 Requests 的资源但不超过 Limits。在资源紧张时可能会被驱逐先于 Guaranteed。7.3 BestEffort最低优先级最先被驱逐条件Pod 中所有 Container 都没有设置requests和limits。特征无资源保障节点资源紧张时最先被杀死。适合批处理任务或测试环境。7.4 驱逐策略与 OOM Score节点压力驱逐当节点的memory.available、nodefs.available等资源低于阈值时kubelet 开始驱逐 Pod。驱逐顺序为BestEffort - Burstable - Guaranteed。OOM ScoreLinux 内核在内存耗尽时会计算每个进程的 OOM Score-1000 到 1000。Guaranteed 通常得分为 -998极低概率被杀。BestEffort 通常得分为 1000最高概率被杀。8. 实践场景组合策略与生产建议8.1 多租户隔离场景假设集群中存在多个业务部门A、B、C需要严格隔离资源。策略为每个部门创建独立的 Namespace。应用ResourceQuota限制总资源yamlhard: requests.cpu: 20 requests.memory: 40Gi limits.cpu: 30 limits.memory: 60Gi pods: 100应用LimitRange强制最小规格例如min: cpu:100m, memory:128Mi防止大量小 Pod 耗尽 API 资源。对于核心业务在 Deployment 中使用GuaranteedQoS。8.2 批处理任务场景对于 Job 或 CronJob如大数据分析资源消耗波动大。策略使用BurstablePodRequests 设为平均值Limits 设为峰值上限。设置activeDeadlineSeconds防止僵尸任务。在 ResourceQuota 中单独分配一个 Namespace防止任务挤占在线业务资源。8.3 有状态应用场景对于 StatefulSet如 Elasticsearch、Kafka资源稳定性至关重要。策略必须使用 Guaranteed QoSrequests limits。合理设置resources.limits.memory防止 OOM。使用Local SSD或高性能存储并在 Pod 层面配置ephemeral-storage限制避免日志写满磁盘导致节点压力。9. 故障排查与监控9.1 常见错误现象可能原因解决方法Pod Status: OOMKilled内存使用超过 Limits或被内核 OOM Killer 杀死增加内存 Limits或排查内存泄漏查看kubectl describe pod中的ReasonPod Status: Evicted节点资源不足内存、磁盘kubelet 驱逐了该 Pod检查节点资源减少 Pod Requests 或增加节点Pod Status: Pending(Insufficient cpu/memory)调度器发现节点资源不足扩容节点或释放低优先级 Pod检查 ResourceQuota 是否耗尽Error: exceeded quota创建资源时Namespace 的 ResourceQuota 不足kubectl edit quota增加配额或删除无用资源9.2 诊断命令bash# 查看 Namespace 资源配额使用情况 kubectl describe quota -n namespace # 查看 Pod 真实资源使用情况需 metrics-server kubectl top pod -n namespace # 查看节点可分配资源 kubectl describe node node | grep -A 5 Allocated resources # 查看 Pod 的 QoS 等级 kubectl get pod -o jsonpath{.items[*].status.qosClass} # 查看 Pod 被驱逐原因 kubectl describe pod pod-name | grep -i Status\|Message9.3 Prometheus 监控指标生产环境中建议通过 Prometheus 监控以下指标kube_pod_container_resource_requests/kube_pod_container_resource_limitskube_resourcequota相关指标container_memory_working_set_bytes与container_cpu_usage_seconds_total对比 Limitskubelet_evictions事件10. 总结与最佳实践清单明确基准值所有生产环境的 Pod 必须设置requests和limits禁止使用 BestEffort。遵循最小权限原则使用 ResourceQuota 限制每个 Namespace 的总消耗。设置默认值通过 LimitRange 强制开发者在忘记配置时有兜底值。核心服务用 Guaranteed确保数据库、中间件等关键服务不受驱逐影响。滚动更新留有余量确保 ResourceQuota 有 20%~30% 的缓冲空间以适应滚动更新时的双倍资源占用。监控与告警对OOMKilled、Evicted、接近 Quota 阈值设置告警。定期审查使用kubectl top定期分析实际利用率优化requests设置避免资源浪费或不足。
Kubernetes 资源限制管理：从基础到生产级实践
1. 引言为什么需要资源限制在 Kubernetes 集群中节点资源CPU、内存、存储等是有限的。如果没有资源限制机制可能会出现以下问题“吵闹的邻居”一个 Pod 的无限制内存使用可能导致节点 OOMOut of Memory进而触发内核杀死关键系统进程或其他 Pod。资源分配不均开发测试环境可能因为某个 Bug 耗尽所有 CPU导致生产服务响应缓慢。调度混乱调度器无法基于准确的资源需求进行决策导致节点负载过高。因此Kubernetes 提供了一套多层次的资源管理机制从Pod/Container粒度的资源声明到Namespace粒度的配额控制再到QoS保障的驱逐优先级帮助集群管理员和开发者实现资源的精细化管控。2. Kubernetes 资源模型核心概念2.1 可压缩资源与不可压缩资源Kubernetes 将资源分为两类类型定义代表资源超限行为可压缩资源资源超限时进程只会被节流Throttle不会被杀死CPUCPU 使用超过 Limits 时内核 Cgroups 限制其时间片进程运行变慢不可压缩资源资源超限时进程可能会被终止内存、磁盘内存使用超过 Limits 时触发 OOM Kill超过 Requests 但低于 Limits 时面临被驱逐风险2.2 Requests 与 Limits 的定义Requests请求Pod 调度时调度器会确保节点上有满足所有 Pod Requests 总和的可分配资源。它代表“保证使用量”。Limits限制Pod 运行时Cgroups 允许使用的资源上限。它代表“最大使用量”。关系解读如果只设置 Limits 未设置 RequestsKubernetes 默认将 Requests 设置为 Limits 的值若存在 LimitRange 则另论。如果只设置 Requests 未设置 LimitsPod 理论上可以使用节点上所有空闲资源但在资源紧张时可能被驱逐。2.3 资源单位详解CPU单位m(millicores)1代表 1 个 CPU 核心或一个 vCPU / 一个 Hyperthread500m代表 0.5 个 CPU 核心最小精度1m(某些环境支持更精细但不推荐)Memory单位Ki(Kibibytes),Mi(Mebibytes),Gi(Gibibytes)例如512Mi2Gi注意使用MMegabyte与Mi的区别Kubernetes 中默认使用二进制单位Mi。3. 第一层防线Pod 与 Container 级别3.1 Container 资源定义每个 Container 是资源消耗的最小单元。在 Pod Spec 中通过resources字段定义yamlapiVersion: v1 kind: Pod metadata: name: resource-demo spec: containers: - name: app image: nginx resources: requests: memory: 64Mi cpu: 250m limits: memory: 128Mi cpu: 500m关键点调度依据调度器仅检查requests。如果节点剩余可分配资源Allocatable小于 Pod 的requestsPod 将保持 Pending 状态。运行时强制limits由 Cgroups 强制实施。如果内存超过limitsContainer 会被 OOMKilled如果 CPU 超过limits会被 Throttled。3.2 Pod 级别聚合与 Init Container 特殊处理Pod 总资源Pod 的资源需求是其所有 Container Requests/Limits 的总和。Init Container初始化容器调度时调度器会选择满足所有 Init Container 中最大 Requests的节点因为 Init Container 是串行执行且执行完即释放资源。资源计算示例Init Container A: CPU 请求 1 核Init Container B: CPU 请求 2 核主容器: CPU 请求 0.5 核调度时的节点需求取 Init Container 最大值2 核 所有主容器总和0.5 核 2.5 核。4. 第二层防线Namespace 级别ResourceQuotaResourceQuota 限制了 Namespace 内所有 Pod 的资源总和防止某个 Namespace 过度消耗集群资源。4.1 ResourceQuota 核心配置yamlapiVersion: v1 kind: ResourceQuota metadata: name: compute-quota namespace: team-a spec: hard: requests.cpu: 8 # 所有 Pod Requests CPU 总和 8核 requests.memory: 16Gi # 所有 Pod Requests 内存总和 16Gi limits.cpu: 16 # 所有 Pod Limits CPU 总和 16核 limits.memory: 32Gi # 所有 Pod Limits 内存总和 32Gi persistentvolumeclaims: 5 # PVC 数量限制 pods: 20 # Pod 数量限制注意如果 Namespace 启用了 ResourceQuota所有 Pod 必须设置 Resource Requests/Limits除非同时配置了 LimitRange 提供默认值。创建 Pod 时如果累计总和超过 QuotaAPI Server 会返回403 Forbidden。4.2 动态扩容与 ScopeSelectorScopeSelector允许你根据 Pod 的状态如Terminating、NotTerminating或 QoS 等级来设置不同的配额。yamlspec: scopes: - Terminating # 仅统计正在终止的 Pod - NotTerminating # 仅统计非终止 Pod scopeSelector: matchExpressions: - operator: In scopeName: PriorityClass values: [high-priority]最佳实践通常将 Quota 分为两类计算型 Quota限制requests.cpu/memory和limits.cpu/memory。对象型 Quota限制pods、services、configmaps数量。4.3 配额计算与耗尽处理ResourceQuota 的计算是基于Pod 当前状态的乐观并发控制。当 Pod 处于Pending状态时就会占用配额。如果配额不足kubectl describe quota会显示Used和Hard字段。集群管理员需要增加配额或等待其他资源释放Pod 删除。5. 第三层防线Namespace 级别LimitRangeLimitRange 为 Namespace 内的资源声明提供默认值和约束范围防止用户创建过小浪费调度资源或过大影响稳定性的 Pod。5.1 默认请求与限制很多开发者嫌麻烦只写镜像不写资源LimitRange 可以注入默认值。yamlapiVersion: v1 kind: LimitRange metadata: name: default-limits namespace: team-a spec: limits: - type: Container default: # 如果未定义 Limits使用此值 cpu: 500m memory: 1Gi defaultRequest: # 如果未定义 Requests使用此值 cpu: 200m memory: 256Mi max: cpu: 2 memory: 4Gi min: cpu: 100m memory: 128Mi5.2 最小/最大约束min和max强制了 Pod 的资源范围。例如如果用户试图创建一个memory request64Mi的 Pod会被拒绝因为低于min: 128Mi。5.3 与 ResourceQuota 的协同LimitRange解决的是“个体合规”问题每个 Pod 不能太大或太小必须有默认值。ResourceQuota解决的是“总量控制”问题所有 Pod 总和不能超标。典型生产配置流程创建 Namespace。应用 LimitRange保证每个 Pod 都有资源声明且符合最小规格。应用 ResourceQuota限制该团队总消耗。6. 应用层抽象Deployment 中的资源配置虽然 Pod 是基础但在生产环境中我们通常通过 Deployment 管理 Pod。6.1 模板内资源声明在 Deployment 的spec.template.spec.containers中声明资源与独立 Pod 写法一致。yamlapiVersion: apps/v1 kind: Deployment metadata: name: my-app spec: replicas: 3 strategy: type: RollingUpdate rollingUpdate: maxSurge: 1 maxUnavailable: 0 template: metadata: labels: app: my-app spec: containers: - name: app image: myapp:v1 resources: requests: cpu: 500m memory: 1Gi limits: cpu: 1 memory: 2Gi6.2 滚动更新与资源预留在滚动更新期间新旧 Pod 会短暂共存。这要求 Namespace 的 ResourceQuota 必须预留足够的余量否则更新可能失败。公式Quota 剩余 (maxSurge * Pod 资源需求)如果 Quota 不足新 Pod 无法创建滚动更新会卡住。6.3 HPA水平自动伸缩与资源指标的联动HPA 通常基于cpu或memory利用率进行扩缩容。yamlapiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: my-app-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: my-app minReplicas: 2 maxReplicas: 10 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 70关键HPA 依赖requests来计算利用率。利用率 (当前使用量 / requests) * 100%如果requests设置过低HPA 会过早扩容设置过高则可能永远无法扩容。7. 深度机制QoS服务质量等级Kubernetes 根据 Pod 的 Requests 和 Limits 配置自动为 Pod 分配 QoS 等级Guaranteed / Burstable / BestEffort。QoS 决定了在资源紧张时节点压力驱逐Pod 被驱逐的优先级。7.1 Guaranteed最高优先级最后被驱逐条件每个 Container 都设置了内存和 CPU 的requests和limits。每个 Container 的requests等于limits内存和 CPU 分别相等。特征只要不超限几乎不会被驱逐。是生产环境核心服务如数据库、网关的理想选择。7.2 Burstable中等优先级条件至少有一个 Container 设置了requests或limits但不满足 Guaranteed 条件。特征允许 Pod 在空闲时使用超出 Requests 的资源但不超过 Limits。在资源紧张时可能会被驱逐先于 Guaranteed。7.3 BestEffort最低优先级最先被驱逐条件Pod 中所有 Container 都没有设置requests和limits。特征无资源保障节点资源紧张时最先被杀死。适合批处理任务或测试环境。7.4 驱逐策略与 OOM Score节点压力驱逐当节点的memory.available、nodefs.available等资源低于阈值时kubelet 开始驱逐 Pod。驱逐顺序为BestEffort - Burstable - Guaranteed。OOM ScoreLinux 内核在内存耗尽时会计算每个进程的 OOM Score-1000 到 1000。Guaranteed 通常得分为 -998极低概率被杀。BestEffort 通常得分为 1000最高概率被杀。8. 实践场景组合策略与生产建议8.1 多租户隔离场景假设集群中存在多个业务部门A、B、C需要严格隔离资源。策略为每个部门创建独立的 Namespace。应用ResourceQuota限制总资源yamlhard: requests.cpu: 20 requests.memory: 40Gi limits.cpu: 30 limits.memory: 60Gi pods: 100应用LimitRange强制最小规格例如min: cpu:100m, memory:128Mi防止大量小 Pod 耗尽 API 资源。对于核心业务在 Deployment 中使用GuaranteedQoS。8.2 批处理任务场景对于 Job 或 CronJob如大数据分析资源消耗波动大。策略使用BurstablePodRequests 设为平均值Limits 设为峰值上限。设置activeDeadlineSeconds防止僵尸任务。在 ResourceQuota 中单独分配一个 Namespace防止任务挤占在线业务资源。8.3 有状态应用场景对于 StatefulSet如 Elasticsearch、Kafka资源稳定性至关重要。策略必须使用 Guaranteed QoSrequests limits。合理设置resources.limits.memory防止 OOM。使用Local SSD或高性能存储并在 Pod 层面配置ephemeral-storage限制避免日志写满磁盘导致节点压力。9. 故障排查与监控9.1 常见错误现象可能原因解决方法Pod Status: OOMKilled内存使用超过 Limits或被内核 OOM Killer 杀死增加内存 Limits或排查内存泄漏查看kubectl describe pod中的ReasonPod Status: Evicted节点资源不足内存、磁盘kubelet 驱逐了该 Pod检查节点资源减少 Pod Requests 或增加节点Pod Status: Pending(Insufficient cpu/memory)调度器发现节点资源不足扩容节点或释放低优先级 Pod检查 ResourceQuota 是否耗尽Error: exceeded quota创建资源时Namespace 的 ResourceQuota 不足kubectl edit quota增加配额或删除无用资源9.2 诊断命令bash# 查看 Namespace 资源配额使用情况 kubectl describe quota -n namespace # 查看 Pod 真实资源使用情况需 metrics-server kubectl top pod -n namespace # 查看节点可分配资源 kubectl describe node node | grep -A 5 Allocated resources # 查看 Pod 的 QoS 等级 kubectl get pod -o jsonpath{.items[*].status.qosClass} # 查看 Pod 被驱逐原因 kubectl describe pod pod-name | grep -i Status\|Message9.3 Prometheus 监控指标生产环境中建议通过 Prometheus 监控以下指标kube_pod_container_resource_requests/kube_pod_container_resource_limitskube_resourcequota相关指标container_memory_working_set_bytes与container_cpu_usage_seconds_total对比 Limitskubelet_evictions事件10. 总结与最佳实践清单明确基准值所有生产环境的 Pod 必须设置requests和limits禁止使用 BestEffort。遵循最小权限原则使用 ResourceQuota 限制每个 Namespace 的总消耗。设置默认值通过 LimitRange 强制开发者在忘记配置时有兜底值。核心服务用 Guaranteed确保数据库、中间件等关键服务不受驱逐影响。滚动更新留有余量确保 ResourceQuota 有 20%~30% 的缓冲空间以适应滚动更新时的双倍资源占用。监控与告警对OOMKilled、Evicted、接近 Quota 阈值设置告警。定期审查使用kubectl top定期分析实际利用率优化requests设置避免资源浪费或不足。
