K8s 1.28 节点上 Go 实时采集 sidecar 调度抢占解决方案：cgroup v2 + cpuset 配置全攻略

① 现象或背景

在 8 节点（32C128G，Kubernetes 1.28.4，containerd 1.7.13，内核 5.15.0-91，cgroup v2）生产集群上，部署了一个 Go 1.22 的实时数据采集 sidecar（4C2G，SCHED_FIFO 95，绑核 0-3，配了 2G hugepage，采集周期 1ms，P50 延迟稳定在 180μs）。sidecar 与 Java 主容器共 Pod。

过去两周观察到 sidecar 的 P99 延迟间歇性抖到 35ms+（正常应 <1ms），抖动窗口约 200ms~1s，频率每小时 3~5 次。抖动时段同节点的 Java 主容器正好在做 GC 或大对象分配，CPU 打满。dmesg 无 OOM，/sys/fs/cgroup/cpu.stat 无 throttling 计数。

② 原理或根因分析

cgroup v2 的软限特性

根据 cgroup v2 memory.high 软压力 的分析，memory.high 是软限而非硬限，内核会在该水位下主动回收内存并施加背压。但本场景中，sidecar 的内存分配受主容器 GC 峰值影响，导致 cgroup 层级的资源竞争。

资源预算独立核算

参考 K8s Pod sidecar 抢资源 的结论，K8s 的 resources.requests/limits 是按容器独立核算的，但节点调度看的是容器 requests 之和。sidecar 的 CPU 配额独立于主容器，但实际调度受 cgroup 层级竞争影响。

③ 具体做法

cgroup v2 + cpuset 配置

1. CPU 配额与调度策略

   • /sys/fs/cgroup/cpu,cpuacct/seat-805/cgroup.procs：确保 sidecar 进程 PID 在此文件中
   • /sys/fs/cgroup/cpu,cpuacct/seat-805/cpu.cfs_period_us：设置为 100000（100ms 周期）
   • /sys/fs/cgroup/cpu,cpuacct/seat-805/cpu.cfs_quota_us：设置为 800000（80% 配额）
   • /sys/fs/cgroup/cpu,cpuacct/seat-805/sched.cpu_usage：监控实际 CPU 使用

2. hugepage 挂载方式

   • /etc/default/grub 添加 hugepagesz=2M 并更新 grub 配置
   • mount -t hugetlbfs nodev /dev/hugepages 挂载 2Mi 大页
   • /sys/kernel/mm/hugepages/hugepages-2Mi/free：监控可用 hugepage 数量

3. NUMA 跨节点访问排查

   • 使用 numactl --show 确认 CPU 与内存 NUMA 节点绑定
   • perf stat -e cache-misses,context-switches 抓取抖动窗口数据

④ 踩过的坑

1. hugepage 与 cgroup v2 的兼容性：2G hugepage 在 cgroup v2 下会导致内存统计口径不一致（参考 K3s 内存驱逐阈值 的踩坑记录）
2. context-switches 爆炸式增长：抖动期 context-switches 值暴涨 40 倍，但 cache-misses 变化不大，说明问题源于调度而非缓存
3. SCHED_FIFO 95 的局限性：虽然提升优先级能减少抖动，但无法完全避免因主容器 GC 导致的 CPU 抢占

⑤ 结论与可复用清单

| 项 | 配置 | 备注 | |---|---|---| | CPU 配额 | 80%（800000/100000） | 通过 cpu.cfs_quota_us 设置 | | hugepage | 2Mi 大页 | 挂载到 /dev/hugepages | | NUMA 绑定 | 通过 numactl 配置 | 确保 CPU 与内存节点匹配 | | PSI 监控 | memory.pressure 阈值 | 建议设置为 80% 防止 OOM |

最终方案：将 sidecar 独立为 DaemonSet 并分配独占核，配合 memory.high 软限与 PSI 告警（参考 PSI 预警规则）实现稳态运行。