felix 日志级别通过 logseverityscreen 字段修改，取值为 emergency/alert/critical/Error/warning/notice/info/debug（大小写敏感），需更新 felix 配置文件（如 configmap 中的 felixconfiguration）并重启 calico-node 容器；bpf 模式下 debug 级别会高频输出 bpf: 前缀日志，属正常行为。
如何修改 Felix 的日志级别（logSeverityScreen）
Felix 默认日志级别是 Info，但 BPF 模式下高频事件（如连接跟踪更新、策略匹配）会大量刷屏，实际调试时往往需要调高到 Debug 或压低到 Warning。修改必须通过 Felix 配置文件（通常是 /etc/calico/felix.cfg 或 ConfigMap 中的 felixConfiguration 资源），不能靠重启容器时传参覆盖。
-
logSeverityScreen是唯一控制终端输出级别的字段，取值为Emergency/Alert/Critical/Error/Warning/Notice/Info/Debug（注意大小写敏感） - 改完后必须重启
calico-node容器，仅 reload 不生效；用kubectl rollout restart daemonset/calico-node最稳妥 - 如果启用了 BPF dataplane，
Debug级别下会频繁打印bpf: map lookup failed类日志——这不是错误，是 BPF 程序主动跳过非本机流量的正常行为，别误判为故障
BPF dataplane 启用的三个硬性前提
Calico 3.22+ 的 BPF 模式不是开关一开就跑，它依赖底层内核能力、CNI 配置和 Felix 自身状态三者同时满足，缺一不可。
- 内核版本 ≥
5.8（推荐 ≥5.10），且需启用CONFIG_BPF_JIT和CONFIG_CGROUP_BPF；用zcat /proc/config.gz | grep -E "(BPF_JIT|CGROUP_BPF)"快速验证 - Felix 配置中
bpfEnabled: true必须显式设置，且dataplaneDriver: "bpf"（旧版叫bpfLogLevel，已废弃） - CNI 配置（
/etc/cni/net.d/10-calico.conflist）里"type": "calico"的"mode"字段必须为"bird"或"none"，不能是"ipam"单独存在；BPF 模式不兼容纯 IPAM 插件
为什么 bpfLogLevel 不再起作用
Calico 3.20 起彻底移除了 bpfLogLevel 配置项，所有 BPF 相关日志统一由 logSeverityScreen 控制。继续在配置里写它不会报错，但会被 Felix 忽略——你看到的日志量没变，不是配置没生效，而是这个字段本身已失效。
- 旧文档或迁移脚本里残留的
bpfLogLevel: "Debug"建议直接删掉，避免误导 - BPF 程序内部调试信息（如 map 更新细节）只在
logSeverityScreen: Debug下输出，且前缀固定为bpf:，搜索日志时认准这个前缀比翻配置更可靠 - 线上环境慎用
Debug：BPF map 操作每秒可达数千次，日志写入可能拖慢节点，尤其在高连接数场景下
验证 BPF dataplane 是否真正在运行
光看 Felix 启动日志说 Starting BPF dataplane 不够，得确认 eBPF 程序已加载且接管流量。
- 执行
bpftool prog list | grep calico，应看到至少calico_ingress和calico_egress两个程序，状态为running - 检查
calico-node容器内是否有/sys/fs/bpf/tc/globals/目录，且里面包含calico_policy_map等 map 文件 - 用
tc Filter show dev cali+查看是否挂载了bpf类型的 tc 过滤器；若显示u32或空，说明仍在 iptables 模式
BPF 模式下最易被忽略的是 cgroup v2 强依赖——如果节点启用了 cgroup v1（systemd.unified_cgroup_hierarchy=0），即使其他条件全满足，BPF dataplane 也会静默退回到 iptables 模式，且 Felix 日志里几乎不提示这点。