kubernetes通过securitycontext.oomscoreadj字段实现内存压力下核心服务优先存活，需配合resources.limits.memory使用，数值越低（如-500）越难被oom killer终止，且要求cgroups v2支持。
Kubernetes 本身不直接暴露 Docker 的 --memory-weight 参数，因为 kubelet 管理容器时抽象了底层运行时细节。但你仍能通过 cgroups v2 + 兼容的 Kubernetes 版本 + 正确的 Pod 配置，让核心服务在内存压力下优先存活——关键在于把 Docker 层的 OOM 权重能力“透传”进 Pod。
✅ 确保底层支持：宿主机和 kubelet 必须启用 cgroups v2
这是所有权重策略生效的前提：
- 检查宿主机是否启用统一 cgroup：
cat /proc/sys/fs/cgroup/unified/hybrid # 应输出 0 stat /sys/fs/cgroup -c '%m' # 应显示 unified
- kubelet 启动参数需包含：
--cgroup-driver=systemd（推荐）且内核启动参数含systemd.unified_cgroup_hierarchy=1 - Kubernetes v1.22+ 默认支持 cgroups v2，v1.26+ 已全面适配
⚠️ 若宿主机仍在 cgroups v1 模式，
--memory-weight和oom_score_adj的 v2 行为将不可用或被忽略。
✅ 在 Pod 中设置 OOM 生存优先级的两种可靠方式
方式一：用 oomScoreAdj 字段（推荐，原生 Kubernetes 支持）
Kubernetes v1.20+ 原生支持在容器级别配置 securityContext.oomScoreAdj：
apiVersion: v1
kind: Pod
metadata:
name: redis-core
spec:
containers:
- name: redis
image: redis:7-alpine
resources:
limits:
memory: "2Gi"
securityContext:
oomScoreAdj: -500 # 数值越低，越难被 OOM killer 杀死
- ✅ 该字段会直接写入容器 init 进程（PID 1）的
/proc/1/oom_score_adj - ✅ 不依赖 Docker CLI，kubelet 自动处理，兼容 containerd、CRI-O
- ✅ 必须配合
resources.limits.memory使用，否则无意义（没有内存上限，就不会触发 cgroup OOM）
方式二：用 runtimeClass + annotations 透传 Docker --memory-weight（仅限 containerd + Docker 运行时）
若你坚持用 --memory-weight（比如已有一套基于 weight 的运维脚本），可通过 containerd 的 annotations 透传：
apiVersion: v1
kind: Pod
metadata:
name: nginx-high-weight
annotations:
"io.containerd.runc.v2": '{"memory_weight":800}'
spec:
runtimeClassName: runc-v2
containers:
- name: nginx
image: nginx:alpine
resources:
limits:
memory: "512Mi"
- ⚠️ 要求 containerd 配置启用
runcv2，并且io.containerd.runc.v2注解被正确解析（需验证 containerd 版本 ≥ 1.7） - ❗ 不是 Kubernetes 标准字段，迁移成本高，仅建议过渡期或特殊调度场景使用
✅ 组合加固：软限制 + OOM 优先级双保险
对真正关键的服务（如 etcd、API server、主库），建议三层防护：
-
硬限制：
resources.limits.memory—— 触发 OOM 的边界 -
软保障：
resources.requests.memory—— 影响 kube-scheduler 分配和节点内存回收倾向（Kubelet 在压力下优先驱逐requests 的 Pod） -
生存权：
securityContext.oomScoreAdj: -500—— 内存超限时最后被杀
示例：
resources:
requests:
memory: "1.5Gi" # 保证调度到有足够空闲内存的节点
limits:
memory: "2Gi" # 真正的 OOM 边界
securityContext:
oomScoreAdj: -500
✅ 验证是否生效
Pod 启动后，在对应节点上执行：
# 查看容器 PID
POD_PID=$(kubectl get pod redis-core -o jsonpath='{.status.containerStatuses[0].containerID}' | cut -d'/' -f3)
# 检查 oom_score_adj 是否写入
cat /proc/$POD_PID/oom_score_adj # 应返回 -500
# 查看 cgroup v2 memory.weight（若用 memory-weight 透传）
cat /sys/fs/cgroup/kubepods/pod*/redis/memory.weight
同时观察 OOM 记录：
dmesg -T | grep -i "killed process" | tail -10
重点看被杀进程名是否避开你标记为 -500 的容器。
❌ 明确不推荐的做法
- 单独设
oomScoreAdj却不配limits.memory→ 参数被忽略，OOM 不触发 - 使用
--oom-kill-disable=true（Kubernetes 中对应securityContext.oomKillDisable: true）→ 禁用 OOM Killer，风险极高，可能拖垮整个节点 - 混用
oomScoreAdj和memory-weight→ 语义重叠且行为不可控，优先选前者
Kubernetes 的设计哲学是“声明式优先级”，不是靠 Docker CLI 参数拼凑。用好 oomScoreAdj + resources.limits，就是最简洁、最稳定、最可移植的核心服务保活方案。
