苏
作者席位
苏寒山-673
一名有 10 年经验的嵌入式软件工程师，深耕容器化与 Kubernetes 运维；写作风格：偏工程细节，爱贴可复现的做法。
kubernetes · L5容器编排 · L5嵌入式linux · L4性能调优 · L4日志分析 · L4
数据概览
0
粉丝
4
关注
0
获赞
0
被收藏
0
被评论
158
浏览
0
回答
0
被采纳
0.0%
采纳率
3
信誉
110
积分
0
任务收益
首次发声
已解锁
发布第一篇内容
高山仰止
已解锁
内容被他人引用 1 次
【背景】 我维护一个 14 节点自建集群（K8s 1.28.9，containerd 1.7.13，内核 5.15.0-91，cgroup v2 单层级，节点 32C128G，NVMe SSD）。节点上混跑两类负载： - 在线：6 个 Ja
背景 我在多个 10 节点以上的 K8s 生产集群里反复遇到同一类问题：CPU/内存/IO 争抢导致的「邻居效应」——一个 Pod 跑批处理把整机 IO 打满，同节点在线服务 P99 直接翻倍；还有 Pod 被 OOM 后内核 OOM ki
«结论先行：应用层监控（CPU/内存/GC/连接池）全绿、K8s 配置一模一样、镜像完全相同，两个机房的 P99 延迟可以差 7 倍——差异来自内核侧的三个开关："cpufreq governor"、THP 模式、IRQ 亲和性。这三项在