根本原因是Ingress-NGINX Pod所在虚拟机的CPU拓扑与宿主机不一致，必须依据lscpu和/sys/devices/system/cpu/online确认实际逻辑核数及编号（如0-3），再使worker_cpu_affinity掩码组数等于worker_processes、每组位数等于逻辑核总数、LSB对应core 0，严禁照搬宿主机掩码。
在 KVM 虚拟化环境运行的 Kubernetes 集群中，Ingress-NGINX Controller 的 worker_cpu_affinity 绑核失效，根本原因不是配置写错了，而是 Nginx 进程启动时看到的 CPU 拓扑和宿主机不一致——它按虚拟机内部实际逻辑核编号去解析掩码，但你照搬了宿主机的拓扑结构或默认掩码，结果绑定失败、CPU 利用率不均、高并发下响应延迟飙升。
确认 Ingress-NGINX Pod 所在虚拟机的真实 CPU 拓扑
别看宿主机有多少核，要看容器运行的那个虚拟机里到底暴露了几个逻辑 CPU、怎么编号：
- 进到 Ingress-NGINX Pod 所在节点（或直接 exec 进 controller Pod）执行：
lscpu | grep -E "(CPU\(s\)|Socket|Core|Thread)"——重点看 “CPU(s):” 总数，以及 Socket/ Core/ Thread 的组合是否合理（比如 2 socket × 2 core × 1 thread = 4 vCPU） - 再查启用范围：
cat /sys/devices/system/cpu/online——输出如0-3表示逻辑核编号是 0、1、2、3；若为0,2,4,6，说明只启用了偶数编号核，掩码必须严格对齐这些位 - 如果
nproc返回 2，但你配了 4 个 worker，worker_cpu_affinity必然报错 “invalid number of masks”，此时必须同步调低worker_processes
按虚拟拓扑生成合法且对齐的掩码组
掩码不是“越长越好”，必须满足两个硬条件：组数 = worker_processes 值，每组二进制位数 = 虚拟机逻辑 CPU 总数，最低位（LSB）对应编号为 0 的核。
- 例如：Pod 所在 VM 有 4 个逻辑核（编号 0–3），且你设
worker_processes 4→ 配：worker_cpu_affinity 0001 0010 0100 1000; - 若 VM 是 2 socket × 2 core，但编号仍是 0–3（KVM 默认顺序映射），掩码不变；不要因为有 “socket” 就误以为要跨掩码高位分组
- 若只有 2 核（
cpu/online显示0,1），则必须设worker_processes 2，再配：worker_cpu_affinity 01 10;—— 不能写成0001 0010
避免 KVM 虚拟化专属陷阱
很多高并发性能问题，其实卡在部署初期就被埋下了：
- 禁用
worker_processes auto+ 手动worker_cpu_affinity组合。Nginx 无法自动推导组数，会静默降级或启动失败 - 不要在 KVM VM 中复用宿主机的 64 位掩码（如
00000001 00000010 …）。VM 只有 4 核，却给 64 位掩码，Nginx 截断后只剩前 4 位，导致所有 worker 全绑到核 0 - 检查 KVM XML 配置是否开启
cpu mode='host-passthrough'和显式<topology sockets="2" cores="2" threads="1"></topology>。否则 Windows VM 常只识别出 2 个逻辑处理器，Linux 也可能漏识别超线程
验证绑定是否真正生效
配完不等于跑对。上线前必须实测验证：
- 在 Ingress-NGINX Pod 内执行：
ps aux | grep nginx | grep -v grep | awk '{print $2}' | xargs -I{} taskset -cp {}
查看每个 worker 进程实际绑定的 CPU 编号，确认是否与掩码预期一致 - 用
htop -H或pidstat -t -p $(pgrep nginx) 1观察各线程 CPU 占用分布，高并发压测时应呈现均衡而非单核打满 - 若发现多个 worker 绑定到同一核，大概率是掩码位数与
cpu/online不匹配，或worker_processes数量超出可用逻辑核数
