企业官网建设流程全解析

1. 为什么 Namespace 和 ResourceQuota 不是“配角”，而是集群稳定运行的底层锚点

你刚在某公司接手一个跑着二十多个微服务的 Kubernetes 集群，运维同事交接时只说了一句：“资源够用，别乱动 namespace。”结果三天后，测试环境突然所有 Pod 都卡在 Pending 状态，日志里反复刷着exceeded quota。你翻遍 Deployment YAML，发现 limit 设置得挺合理；查节点资源，kubectl top nodes显示 CPU 使用率才 35%。问题出在哪？——不是资源不够，是“账本”被算爆了。

Namespace 在 Kubernetes 里根本不是简单的“文件夹”或“命名前缀”。它是一套独立的逻辑边界，自带三重隔离机制：对象可见性隔离（A 命名空间里的 Service 无法直接被 B 命名空间的 Pod 解析）、策略作用域隔离（NetworkPolicy、RBAC 规则只在本命名空间内生效）、资源计量隔离（ResourceQuota 统计的是每个命名空间内部的总消耗）。这就像一栋写字楼，每层楼（Namespace）有自己独立的电表、水表、门禁系统和消防通道，物业（K8s 控制平面）只按楼层收管理费，不看整栋楼总用电量。

而 ResourceQuota 和 LimitRange 是这套隔离体系的“财务审计员”和“采购审批员”。ResourceQuota 管的是“总额度”——比如开发组 namespace 最多只能用 20 个 CPU 核、40Gi 内存、100 个 Pod；LimitRange 管的是“单笔限额”——比如该命名空间里每个容器默认必须设置 request=500m CPU、limit=1000m CPU，否则创建失败。很多人以为设了 LimitRange 就万事大吉，实则不然：如果没配 ResourceQuota，用户可以无限创建符合 LimitRange 的 Pod，最终把整个节点资源耗尽，导致其他命名空间的服务也被挤占。反过来，只配 ResourceQuota 不配 LimitRange，用户可能提交一个 request=10m、limit=64Gi 的 Pod，调度器会把它塞进任意节点，但实际运行时几乎必然 OOM 被杀——因为 10m 的 request 让调度器误判节点还有大量空闲资源。

我见过最典型的误操作是在 CI/CD 流水线里，自动化脚本每次构建都新建一个临时 namespace（如ci-build-20240520-123456），跑完却忘了清理。两周后集群里堆了 300+ 个空 namespace，每个都挂着默认 LimitRange，虽然没 Pod，但 ResourceQuota 对象本身也占 etcd 存储。更糟的是，某些旧版 K8s 的 controller-manager 在同步大量 namespace 时 CPU 持续飙高，API Server 响应延迟从 100ms 涨到 2s。这不是理论风险，是我在某电商大促前夜真实踩过的坑——当时紧急写了个 CronJob，每天凌晨扫描并删除 7 天前无 Pod 的 namespace，才把 API Server 拉回正常水位。

所以，当你看到标题里把 Namespace 和 ResourceQuota、LimitRange 并列，千万别当成三个孤立概念。它们是同一枚硬币的正反面：Namespace 定义“谁管哪块地”，ResourceQuota 划定“这块地能种多少粮”，LimitRange 规定“每粒种子必须带多少养分”。缺一不可，错配即崩。

2. Namespace 的深层设计与实战避坑指南

2.1 Namespace 的本质：不止是名字前缀，而是 API Server 的“租户路由表”

Kubernetes API Server 在处理请求时，并非先解析 YAML 再决定往哪存。它有一套严格的路径解析规则：所有资源请求都走/api/v1/namespaces/{namespace}/{resource}这个模式。当你执行kubectl get pods -n default，客户端实际发出的 HTTP 请求是GET /api/v1/namespaces/default/pods。API Server 收到后，第一步不是查 etcd，而是检查default这个 namespace 是否存在、是否处于 Active 状态。如果 namespace 状态是 Terminating（正在删除中），哪怕里面还有 100 个 Pod，所有针对它的读写请求都会被立即拒绝，返回404 Not Found或409 Conflict。

这就引出了第一个致命误区：认为 namespace 删除是原子操作。实际上，kubectl delete ns xxx只是把 namespace 对象标记为 Terminating，然后由 namespace controller 异步清理其下所有资源。这个过程可能长达数分钟——尤其当 namespace 里有 StatefulSet、PersistentVolumeClaim 或自定义 CRD 时。我曾在一个金融客户集群里遇到过：运维误删了生产 namespace，等发现时 controller 已经开始逐个删除 Pod，但某个数据库 Pod 因 PVC 卷被其他节点挂载而卡在 Terminating 状态，导致整个 namespace 卡死。最后不得不手动 patch namespace 的 finalizers 字段强行清除，才恢复服务。

第二个误区是滥用default命名空间。很多教程教新手直接kubectl apply -f app.yaml，殊不知这等于把所有应用扔进公共大澡堂。问题在于：defaultnamespace 默认没有任何 ResourceQuota，也没有 NetworkPolicy，默认允许所有 Pod 互相通信。某次灰度发布时，测试团队在 default 下部署了一个调试用的 Nginx，配置了hostNetwork: true，结果它监听了宿主机 80 端口，把线上网关的流量全劫走了。后来我们强制规定：所有新项目必须使用project-{name}命名空间，default仅用于集群基础组件（如 metrics-server），且通过 RBAC 锁死普通用户对 default 的写权限。

第三个易忽略点是 namespace 的 label 和 annotation。它们不只是元数据，而是策略控制器的输入源。比如 Calico 的 NetworkPolicy、Open Policy Agent 的策略引擎，都可以基于kubernetes.io/metadata.name或自定义 label（如env=prod）做精细化控制。我们给所有命名空间统一加了team: backend、billing-code: B2024这类 label，这样财务系统就能自动抓取每个命名空间的资源消耗，生成部门级成本报表。而 annotationk8s.kubeflow.org/owner-email: dev@company.com则被内部告警系统读取，当该 namespace 出现高 CPU 报警时，自动邮件通知对应负责人。

2.2 ResourceQuota：不是“防贼”，而是“防误操作”的财务沙盒

ResourceQuota 的核心价值，从来不是防止恶意用户耗尽资源，而是防止团队协作中的“无意识超支”。想象一个 5 人前端团队共用frontend-prod命名空间，每人负责一个微前端模块。A 同学上线时写了resources.limits.memory: 8Gi，B 同学觉得不够，改成12Gi，C 同学又加了个监控 Sidecar，再加4Gi……没人盯着总量，直到某天集群整体内存使用率突破 95%，调度器开始驱逐低优先级 Pod。

ResourceQuota 的设计哲学是“声明式预算管理”。它不干预单个 Pod 的创建，只在创建后检查总量是否超标。具体流程是：当用户提交 Pod 创建请求，API Server 先校验该 Pod 是否符合命名空间的 LimitRange（如有），然后创建 Pod 对象；接着，ResourceQuota Controller 作为后台协程，扫描该命名空间下所有 Pod、PVC、ConfigMap 等资源，累加其 request/limit 值，与 ResourceQuota 中定义的hard字段比对。一旦发现used > hard，Controller 会更新 ResourceQuota 对象的status.used字段，并在事件中记录ExceededQuota。

这里有个关键细节：ResourceQuota 统计的是request 值之和，不是 limit。因为 request 是调度器分配资源的依据，也是 kube-scheduler 决定 Pod 能否调度到某节点的核心参数。limit 只是运行时的上限，不影响调度。所以你的 ResourceQuota 必须按 request 来设，否则会出现“quota 显示充足，但 Pod 就是调度不了”的诡异现象。

我们线上集群的 ResourceQuota 配置遵循“三层水位线”原则：

• 警戒线（80%）：当used > 0.8 * hard时，Prometheus 告警触发，通知团队负责人核查资源使用；
• 熔断线（95%）：当used > 0.95 * hard时，CI/CD 流水线自动拒绝新镜像部署，除非人工审批；
• 硬上限（100%）：used == hard时，任何新 Pod 创建请求都会被 API Server 直接拒绝，返回Forbidden: exceeded quota。

这种设计让资源管理从“事后救火”变成“事前预警”。去年双十一大促前，我们把订单服务命名空间的 CPU request 预算从 16 核提高到 24 核，但 ResourceQuota 的 hard 值只设到 20 核。结果压测时发现峰值 request 达到 19.8 核，离熔断线只剩 0.2 核余量，立刻叫停扩容，转而优化 Java 应用的 GC 参数，最终节省了 4 核物理 CPU 的采购成本。

2.3 LimitRange：那个默默帮你填坑的“默认采购员”

LimitRange 常被误解为“限制资源上限”，其实它干的是两件事：设置默认值（default）和强制约束（min/max）。它的真正威力，在于解决开发者“懒得写资源声明”的惯性。

Kubernetes 官方文档明确写着：“If you do not specify a value for resources, the container is scheduled with no resource constraints.” 意思是，如果你的 Pod YAML 里完全没写resources字段，那这个容器就是裸奔状态——没有 request，没有 limit，调度器认为它不占资源，但它运行时可能吃光整个节点内存。LimitRange 的default字段，就是给这种裸奔容器自动套上缰绳。

我们线上 LimitRange 的典型配置如下：

apiVersion: v1 kind: LimitRange metadata: name: cpu-memory-defaults namespace: frontend-prod spec: limits: - default: memory: 512Mi cpu: 500m defaultRequest: memory: 256Mi cpu: 250m max: memory: 4Gi cpu: 2000m min: memory: 64Mi cpu: 100m type: Container

这段配置意味着：

• 任何没写resources的容器，会被自动注入requests.cpu=250m, requests.memory=256Mi, limits.cpu=500m, limits.memory=512Mi；
• 如果开发者写了limits.memory=8Gi，会被拒绝，因为超出了max.memory=4Gi；
• 如果写了requests.cpu=50m，也会被拒绝，因为低于min.cpu=100m；
• 所有容器的requests必须 ≤limits，这是 K8s 内置校验，LimitRange 不参与。

这里有个血泪教训：某次升级 Spring Boot 应用，新版本默认启用了 JVM 的 G1GC，并设置了-XX:MaxRAMPercentage=75.0。开发者没改容器资源限制，结果 JVM 自动把内存拉到 3Gi，远超 LimitRange 的max.memory=2Gi，Pod 启动就 OOMKilled。后来我们在 LimitRange 里加了minLimitRatio（需 K8s 1.24+），要求limits.memory / requests.memory >= 1.5，强制开发者预留足够 buffer。

提示：LimitRange 的type: Container只影响容器，type: Pod则约束整个 Pod 的资源总和（如 Pod 内多个容器 request 总和不能超 4Gi）。我们生产环境对有 Sidecar 的服务（如 Istio 注入）必须配type: Pod，否则 Envoy Sidecar 和主容器的 request 可能分别合规，但加起来超限。

3. ResourceQuota 与 LimitRange 的协同作战：从零搭建企业级资源管控体系

3.1 设计原则：先画“资源地图”，再定“管控红线”

搭建资源管控体系，绝不能上来就写 YAML。我们团队的标准流程是“三步走”：

第一步：绘制资源热力图
用 Prometheus + Grafana 抓取过去 30 天各命名空间的container_cpu_usage_seconds_total和container_memory_usage_bytes，按小时聚合，生成热力图。重点看三个指标：

• 峰均比：最高 request / 日均 request。若 > 3，说明业务有强周期性（如报表系统凌晨跑批），需单独设 quota；
• 碎片率：(sum(requests) - sum(used)) / sum(requests)。若 > 40%，说明资源申请过于保守，要推动团队调低 request；
• 超限频次：count by (namespace) (rate(kube_resourcequota_exceeded_total[1h]))。高频超限的命名空间，优先排查 LimitRange 是否过严。

第二步：划分资源责任田
我们按业务线+环境维度划分命名空间，例如：

• backend-prod：核心后端服务（订单、支付）
• backend-staging：预发环境
• ml-training-dev：算法团队训练任务（GPU 资源独占）
• shared-infra：Redis、Kafka 等中间件（只读权限开放给其他命名空间）

每个命名空间的 ResourceQuota 预算，不是拍脑袋定的。我们用公式：
quota = (日均 peak request × 1.5) + (突发 buffer)
其中突发 buffer 按业务 SLA 确定：支付类服务 buffer=300%，营销活动类 buffer=500%。

第三步：编写可审计的 YAML 模板
所有 ResourceQuota 和 LimitRange 必须通过 GitOps 管理。我们用 Kustomize 生成不同环境的配置，核心模板如下：

# base/resource-quota.yaml apiVersion: v1 kind: ResourceQuota metadata: name: team-quota annotations: quota-policy: "auto-generated-by-kustomize" spec: hard: # CPU request 总量 requests.cpu: "${CPU_REQUEST_QUOTA}" # 内存 request 总量 requests.memory: "${MEM_REQUEST_QUOTA}" # Pod 数量上限 pods: "${POD_QUOTA}" # 持久卷声明数量 persistentvolumeclaims: "${PVC_QUOTA}" # ConfigMap 数量 configmaps: "50" # Secret 数量 secrets: "30"

变量${CPU_REQUEST_QUOTA}等由 CI 流水线根据热力图分析结果自动注入。这样既保证策略可追溯，又避免人工计算错误。

3.2 实操：手把手配置一个高可用命名空间

以backend-prod命名空间为例，完整配置流程如下：

Step 1：创建命名空间并打标

# 创建命名空间 kubectl create namespace backend-prod # 添加关键 label 和 annotation kubectl label ns backend-prod \ env=prod \ team=backend \ billing-code=B2024 \ owner=backend-lead@company.com kubectl annotate ns backend-prod \ description="Production backend services: order, payment, user" \ k8s.kubeflow.org/owner-email=backend-lead@company.com

Step 2：配置 LimitRange（先于 ResourceQuota）
为什么顺序重要？因为 ResourceQuota 统计的是已存在的资源，如果先建 ResourceQuota，再建 LimitRange，那些没设资源的旧 Pod 会被立即计入 quota，可能导致 quota 瞬间爆满。

# limitrange-backend-prod.yaml apiVersion: v1 kind: LimitRange metadata: name: backend-limits namespace: backend-prod spec: limits: - default: memory: 1Gi cpu: 1000m defaultRequest: memory: 512Mi cpu: 500m max: memory: 8Gi cpu: 4000m min: memory: 128Mi cpu: 200m maxLimitRequestRatio: memory: "2" cpu: "2" type: Container - default: memory: 2Gi cpu: 2000m type: Pod

应用配置：

kubectl apply -f limitrange-backend-prod.yaml

Step 3：配置 ResourceQuota
根据热力图分析，backend-prod过去 30 天 CPU request 峰值为 18.2 核，内存峰值为 32.5Gi，我们按 1.5 倍冗余设 quota：

# resourcequota-backend-prod.yaml apiVersion: v1 kind: ResourceQuota metadata: name: backend-quota namespace: backend-prod spec: hard: requests.cpu: "28" requests.memory: 48Gi limits.cpu: "32" limits.memory: 64Gi pods: "120" persistentvolumeclaims: "20" configmaps: "100" secrets: "80" services: "50" services.loadbalancers: "5" services.nodeports: "10"

注意services.loadbalancers和services.nodeports这两个字段。前者限制 LoadBalancer 类型 Service 数量（云厂商通常收费），后者限制 NodePort 端口占用数（Linux 系统默认只有 30000-32767 可用）。我们曾因没设services.nodeports，导致测试团队创建了 200+ NodePort Service，把端口池占满，新 Service 无法分配端口，报错Failed to allocate node port。

Step 4：验证配置生效
用一个故意超限的测试 Pod 验证：

# test-pod-over-quota.yaml apiVersion: v1 kind: Pod metadata: name: test-over-quota namespace: backend-prod spec: containers: - name: nginx image: nginx:alpine resources: requests: memory: "50Gi" # 远超 quota 的 48Gi cpu: "100" limits: memory: "50Gi" cpu: "100"

执行kubectl apply -f test-pod-over-quota.yaml，会立即返回：

Error from server (Forbidden): error when creating "test-pod-over-quota.yaml": pods "test-over-quota" is forbidden: exceeded quota: backend-quota, requested: requests.memory=50Gi, used: requests.memory=2.1Gi, limited: requests.memory=48Gi

说明 ResourceQuota 生效。再删掉这个测试 Pod，用合规的 Pod 测试：

# test-pod-valid.yaml apiVersion: v1 kind: Pod metadata: name: test-valid namespace: backend-prod spec: containers: - name: nginx image: nginx:alpine resources: requests: memory: "512Mi" cpu: "500m" limits: memory: "1Gi" cpu: "1000m"

kubectl apply -f test-pod-valid.yaml成功后，检查 quota 使用情况：

kubectl describe quota backend-quota -n backend-prod

输出中会显示：

Name: backend-quota Namespace: backend-prod Resource Used Hard -------- ---- ---- configmaps 1 100 cpu 500m 28 memory 512Mi 48Gi pods 1 120 ...

3.3 进阶技巧：用 ResourceQuota 实现“弹性预算池”

ResourceQuota 默认是静态的，但业务需求是动态的。比如大促期间，backend-prod需要临时扩容，但又不想改 YAML 重新 apply（怕误操作）。我们的解法是：用 Operator 动态调整 ResourceQuota。

我们写了一个轻量级的QuotaScalerOperator，监听特定 annotation（如quota-scaler.company.com/enabled: "true"）的 ResourceQuota 对象。当检测到 annotationquota-scaler.company.com/target-cpu: "40"时，Operator 会自动 patch 该 ResourceQuota 的hard.requests.cpu字段为"40"。

实现原理很简单（Go 伪代码）：

// 监听 ResourceQuota 变更 if quota.Annotations["quota-scaler.company.com/enabled"] == "true" { targetCPU := quota.Annotations["quota-scaler.company.com/target-cpu"] // 构造 patch JSON patchData := fmt.Sprintf(`{"spec":{"hard":{"requests.cpu":"%s"}}}`, targetCPU) // 调用 K8s API patch client.ResourceQuotas(quota.Namespace).Patch(context.TODO(), quota.Name, types.StrategicMergePatchType, []byte(patchData), metav1.PatchOptions{}) }

这样，大促值班同学只需执行：

kubectl annotate quota backend-quota \ quota-scaler.company.com/target-cpu="40" \ --overwrite

30 秒内 quota 就会生效，无需重启任何组件。大促结束再把值调回 28，Operator 自动还原。整个过程对业务零感知，这才是真正的弹性。

4. 故障排查与性能调优：那些官方文档不会写的实战经验

4.1 ResourceQuota “假死”诊断：当 quota 显示未超限，但 Pod 却调度失败

现象：kubectl describe pod xxx显示0/3 nodes are available: 1 Insufficient cpu, 2 Insufficient memory.，但kubectl describe quota显示Used < Hard。

原因有三：

1. 调度器缓存未刷新：Kube-scheduler 有 10 秒左右的资源缓存，节点实际资源变化后，调度器可能还在用旧数据。执行kubectl uncordon node-xxx可强制刷新；
2. 节点 taint 未匹配：Pod 的 tolerations 与节点 taint 不匹配，导致调度器认为该节点不可用。检查kubectl describe node node-xxx | grep Taints；
3. ResourceQuota 统计滞后：ResourceQuota Controller 默认 5 分钟同步一次。如果刚创建大量 Pod，quota 的status.used可能还没更新。此时kubectl get quota backend-quota -n backend-prod -o yaml查看status.lastUpdated时间戳，若超过 5 分钟未更新，需检查kube-controller-manager日志是否有failed to sync quota错误。

我们封装了一个诊断脚本check-quota-health.sh：

#!/bin/bash NS=$1 QUOTA_NAME=$2 echo "=== Checking ResourceQuota $QUOTA_NAME in $NS ===" echo "1. Quota status:" kubectl get quota $QUOTA_NAME -n $NS -o wide echo -e "\n2. Last updated time:" kubectl get quota $QUOTA_NAME -n $NS -o jsonpath='{.status.lastUpdated}' echo -e "\n3. Current node resource usage:" kubectl top nodes echo -e "\n4. Pods in Pending state:" kubectl get pods -n $NS --field-selector=status.phase=Pending

4.2 LimitRange “静默失效”场景：为什么有些 Pod 没被注入默认值？

LimitRange 生效有两个前提：

• Pod 必须在 LimitRange 创建后创建：已存在的 Pod 不会 retroactively 被修改；
• Pod 的 namespace 必须与 LimitRange 的 namespace 一致：跨 namespace 无效。

但还有一个隐藏条件：LimitRange 的type字段必须匹配 Pod 结构。如果 LimitRangetype: Container，但你的 Pod YAML 里写了initContainers，那么 initContainer 不会获得默认值！因为initContainers是独立于containers的字段，需要单独配一个type: InitContainer的 LimitRange。

我们曾因此踩坑：一个 Java 应用的 initContainer 用来下载配置，没设 resources，结果它启动时占用了 2Gi 内存，把节点内存吃光，导致主容器无法启动。解决方案是补一个 initContainer 的 LimitRange：

- default: memory: 256Mi cpu: 200m defaultRequest: memory: 128Mi cpu: 100m type: InitContainer

4.3 性能调优：ResourceQuota Controller 的瓶颈与绕行方案

ResourceQuota Controller 在大规模集群（> 5000 Pod）中可能成为性能瓶颈。默认配置下，它每 5 分钟全量扫描所有命名空间的所有资源，对 etcd 造成压力。我们通过以下三招优化：

第一招：调高 resync 间隔
在kube-controller-manager启动参数中添加：

--resource-quota-sync-period=10m

将扫描周期从 5 分钟延长到 10 分钟。实测对业务无感，etcd QPS 降低 35%。

第二招：启用增量更新
K8s 1.22+ 支持--feature-gates=WatchList=true，让 Controller 用 WatchList API 替代 List API 获取资源变更，减少全量扫描。需同时开启：

--watch-list=true --feature-gates=WatchList=true

第三招：拆分高负载命名空间
当某个命名空间 Pod 数量 > 500，我们将其按服务拆分为子命名空间，如backend-prod-order、backend-prod-payment。每个子命名空间配独立 ResourceQuota，分散 Controller 压力。拆分后，单个命名空间的 ResourceQuota Controller 处理时间从 8 秒降至 1.2 秒。

注意：拆分命名空间后，跨命名空间的服务发现需显式配置。比如order服务要调用payment，不能只写payment.default.svc.cluster.local，而要写payment.backend-prod-payment.svc.cluster.local。我们用 Helm 模板的{{ .Values.namespace }}变量自动注入，避免硬编码。

4.4 常见问题速查表

5. 从管控到治理：如何让资源策略真正落地生根

技术方案写得再完美，如果团队不理解、不遵守，就是废纸一张。我们花了半年时间，把 ResourceQuota/LimitRange 从“运维强制要求”变成了“研发自觉习惯”。

第一阶段：可视化驱动认知
我们开发了一个内部 Dashboard，首页就是各命名空间的“资源健康度仪表盘”，用红黄绿三色显示：

• 绿色：used < 70% hard
• 黄色：70% ≤ used < 90% hard
• 红色：used ≥ 90% hard

每个色块点击进去，能看到详细 TopN 消耗者（如pod/order-service-7c8b9d4f5-abcde占了 3.2 核），并附带一键跳转到该 Pod 的 YAML 编辑页。研发同学第一次看到自己写的 Pod 占了命名空间 40% 的 CPU quota，当场就去优化了 JVM 参数。

第二阶段：CI/CD 流水线嵌入校验
在 Jenkins/GitLab CI 的构建阶段，加入资源检查脚本：

# 检查 YAML 中是否缺失 resources yq e '.spec.containers[] | select(has("resources") | not)' deployment.yaml # 检查 resources 是否符合 LimitRange 的 min/max yq e '.spec.containers[].resources.requests.memory | select(test("^[0-9]+Mi$") | not)' deployment.yaml

任何不合规的 YAML，流水线直接失败，并给出修复建议链接。坚持三个月，团队提交的 YAML 合规率从 32% 提升到 98%。

第三阶段：成本分摊与激励
我们把 ResourceQuota 的hard值，直接映射成云厂商的实际账单。比如requests.cpu=1≈ ￥0.12/小时，requests.memory=1Gi≈ ￥0.08/小时。每月初，自动邮件发送各命名空间的成本报表，抄送团队负责人和财务。效果立竿见影：原来大家觉得“资源是免费的”，现在看到自己团队上月花了 ￥23,560，立刻主动找运维要优化方案。

最后分享一个真实案例：某次架构评审会上，一位资深架构师提出“为提升稳定性，所有服务 Pod request 应设为 limit 的 80%”。我当场打开 Dashboard，展示他负责的search-prod命名空间——当前used.requests.cpu / used.limits.cpu = 35%，说明大量资源闲置。我问：“如果把 request 提到 80%，quota 硬上限不变，您打算砍掉多少服务？” 他沉默三秒，说：“我回去重新评估 JVM 参数。” 一周后，他们把 search 服务的 request 从 4 核降到 2.5 核，释放出 1.5 核，够新上两个小服务。

这就是资源治理的终极目标：不是用技术锁死别人，而是用数据和机制，让每个人成为自己资源的精明管家。Namespace、ResourceQuota、LimitRange 这些看似冰冷的 YAML，最终要服务于人的决策，而不是替代人的思考。