边缘节点内存吃紧时，关键低内存网关 Pod 被 K8s 驱逐，request 到底设多大才不浪费又能保命？

结论先行：你这个"低内存但关键"的 Pod，正确做法是 request=256Mi 不动 + 独占边缘节点 + 把驱逐阈值从默认 100Mi 调到 50Mi + 给它 Guaranteed QoS（request=limit=384Mi），而不是把 request 拉到 1Gi。下面逐项展开。

一、request 按什么标准设——别拍脑袋，用 RSS 分位数

你的 C++ 服务裸机跑 3 年 RSS 稳定 120MB，这本身就是最好的基线。量化公式：

request = ceil(P999_RSS × 1.5)    # 1.5 覆盖瞬时 malloc 尖峰
limit   = ceil(P99_RSS × 2.0)     # 留 2× 余量防 OOMKill

你的数据：P999 RSS ≈ 120MB（3 年稳定），所以：

• request = 120 × 1.5 ≈ 180Mi → 取整 256Mi（K8s 最小粒度 1Mi，256Mi 完全合理）
• limit = 120 × 2.0 ≈ 240Mi → 取整 384Mi

如果担心"偶尔冲到 600MB"——先确认那 600MB 是不是包含 page cache（cat /proc/<pid>/status 里 RSS 和 VmSize 差异）。C++ 服务如果 RSS 真冲到 600MB，大概率是内存泄漏或大 buffer 分配，该修的是代码，不是把 limit 拉到 1Gi 掩盖问题。建议先加一条 Prometheus 告警：container_memory_working_set_bytes{pod=~"edge-gw.*"} > 300Mi 持续 5min 就告警，跑两周看真实分布再定 limit。

二、priorityClass 对 eviction 到底有没有用

没有用，你的判断是对的。 边界如下：

| 场景 | priorityClass 是否生效 | |------|----------------------| | 调度抢占（preemption）：新高优 Pod 来了要踢低优 Pod | ✅ 生效 | | kubelet 驱逐（eviction）：节点内存压力超阈值，按 QoS 排序驱逐 | ❌ 不生效 | | OOMKill（cgroup OOM）：超出 limit 被内核杀 | ❌ 不生效 |

kubelet 驱逐排序只看 QoS class（Guaranteed > Burstable > BestEffort） 和 内存超额量（memory.current - memory.request），跟 priorityClass 完全无关。所以你的 priorityClass=1000000 对驱逐场景是无效的。

三、Guaranteed QoS 在这里的利与弊

利：驱逐排序时 Guaranteed 永远最后被踢（同节点所有 Guaranteed Pod 按内存超额量排序，超额最少的先被踢，但 BestEffort/Burstable 一定先于 Guaranteed）。你 120MB RSS、request 256Mi，超额量≈0，在 Guaranteed 组里几乎不可能被驱逐。

弊：limit=384Mi 意味着如果真出现内存泄漏飙到 400MB，会被 cgroup OOMKill，而不是被驱逐后在其他节点重建。

建议：对这种"三年没崩、RSS 极稳定"的 C++ 服务，Guaranteed 是正确的选择。OOMKill 比驱逐好——因为驱逐意味着 Pod 消失、流量切换、边缘网关断连，而 OOMKill 后 kubelet 立刻原地重启，如果内存泄漏修了就不会再触发。配置：

resources:
  requests:
    memory: "256Mi"
    cpu: "250m"
  limits:
    memory: "384Mi"
    cpu: "500m"

request=limit 对 memory 是 Guaranteed 的必要条件，但 CPU 可以 request≠limit（CPU 软限，超了只是 throttle 不会 OOMKill）。

四、不靠拉高 request 降低被驱逐概率——组合拳

4.1 独占边缘节点（首选，成本最低）

你 4C8G 节点上混部了 sidecar 和业务 Pod，驱逐的根因是同节点其他 Pod 把可用内存吃光了。最干净的解法：

# 给边缘网关 Pod 加 nodeSelector
nodeSelector:
  node-role.kubernetes.io/edge-gateway: "true"

在 4C8G 节点上打 label，用 taint + toleration 保证只有这个 Pod 能调度上来：

kubectl taint nodes edge-node-1 dedicated=edge-gateway:NoSchedule

tolerations:
- key: "dedicated"
  operator: "Equal"
  value: "edge-gateway"
  effect: "NoSchedule"

这样其他业务 Pod 不会再调度到这个节点，内存压力从源头消除。4C8G 跑一个 120MB RSS 的 C++ 服务 + 基础系统开销，绰绰有余，不存在浪费。

4.2 驱逐阈值调优（兜底）

如果节点必须混部，把 kubelet 的驱逐阈值调紧，让驱逐更早触发但影响面更小：

# /var/lib/kubelet/config.yaml 或启动参数
--eviction-hard="memory.available<50Mi"
--eviction-soft="memory.available<100Mi"
--eviction-soft-grace-period="memory.available=30s"

默认 memory.available<100Mi，你 8G 节点上 100Mi 阈值意味着可用内存降到 100Mi 才触发驱逐。调到 50Mi 意味着更晚触发（给系统更多缓冲），但同时 soft 阈值 100Mi + 30s 宽限期让你有时间观察和手动干预。

4.3 可观测性（别等驱逐了才看）

# 节点级内存压力实时指标（加到 Prometheus）
node_memory_MemAvailable_bytes
kubelet_evictions_total{node="edge-node-1"}
container_memory_working_set_bytes{pod=~"edge-gw.*"}

# 驱逐前 30s 告警（soft threshold 触发时 kubelet 发 Event）
# 用 kubectl get events 或 Prometheus AlertManager 抓

五、成本账

| 方案 | 内存占用 | 节点数 | 成本 | |------|---------|--------|------| | request=1Gi（你原来的想法） | 1Gi request × N Pod | 需要更多节点 | ❌ 翻倍 | | request=256Mi + 独占节点 + Guaranteed | 256Mi request + 384Mi limit | 1 个 4C8G 节点 | ✅ 不变 | | request=256Mi + 混部（不调优） | 256Mi | 1 个节点 | ⚠️ 有驱逐风险 |

结论：独占节点 + Guaranteed(256/384) + 驱逐阈值 50Mi，是成本最低且最稳的组合。不需要拉 request，不需要 1Gi，不需要跟安全团队吵。