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

背景 我在做边缘网关，核心是一个 C++ 控制/桥接服务，裸机跑 4C8G 工控机时 RSS 稳定在 120MB 左右，三年没崩过。今年统一容器化，落到一个 4C8G 的边缘 K8s 节点（1.28.9，containerd 1.7.13，cgroup v2）上，同节点还混部了几个日志/采集类 sidecar 和别的业务 Pod。

现象 平时没事，一旦节点内存压力上来（node 可用内存跌破 15%），kubelet 直接触发 memory pressure 驱逐，我这个 RSS 才 120MB 的关键 Pod 反而经常排在驱逐名单前面——因为它 request 只写了 256Mi，被驱逐打分机制当成"低优先级"先踢。可如果我把 request 硬拉到 1Gi 甚至 2Gi 来"买安全"，4C8G 的节点塞不下几个 Pod，成本直接翻倍，这违背我们边缘端省资源的初衷。

已尝试的排查与结果

1. 把 request 从 256Mi 调到 512Mi，驱逐频率降了一些但没根治，压力峰值时仍被踢；
2. 给它加了 priorityClass（value=1000000）+ preemption，但发现驱逐（eviction）走的是 kubelet 的 memory 阈值，跟 preemption 不是一回事，preempt 挡不住 eviction，这条思路好像没走对；
3. 想设 memory 的 QoS 到 Guaranteed（request=limit=512Mi），但担心 limit 卡死，真实峰值偶尔冲到 600MB 会不会反而被 OOMKilled，不敢全量上。

期望得到的答案形态 想请各位给一套可落地的组合拳：(1) 这种"低内存占用但关键"的 Pod，request 到底按什么标准设（P99？P999？加多少余量），怎么量化而不是一味拉高；(2) priorityClass 对 eviction 到底有没有用，还是只能管 preempt，两者边界在哪；(3) Guaranteed QoS 在这里的利与弊，limit 设多少安全；(4) 有没有不靠"加大 request"就能降低被驱逐概率的办法（比如独占节点 + nodeSelector/亲和、eviction 阈值调优、或把它拆到独立边缘节点）。最好能给具体数值/配置示例，让我能在 4C8G 节点上算清楚成本账。