【Falco】部署与 driver.kind：Helm、auto 回退与 least-privileged
内容提要
本文介绍Falco 0.44.1部署中modern_ebpf与kmod引擎的选择。常见误区包括误用auto回退、将least-privileged能力集套用于kmod，以及异构节点静默回退后错误排障。部署时需按节点核对实际引擎，强制单一引擎应显式指定，避免静默分叉。least-privileged仅适用于modern_ebpf，kmod需完整特权。排障以进程侧Driver证据为准，而非全局配置。
延伸解读
auto 回退的运维代价
driver.kind=auto 在异构集群中会按节点探测能力，导致不同节点运行不同引擎。这种静默分叉是预期行为，但若未核对节点级 Driver 行，排障时容易用错权限模型。强制单一引擎虽会让不兼容节点启动失败，但失败可见，优于静默分叉带来的隐性风险。
least-privileged 的适用范围
least-privileged 能力集仅适用于 modern_ebpf，kmod 需要完整特权加载 .ko。将同一 securityContext 套用到 kmod 路径属于配置错误，可能导致模块加载失败或容器仍以 privileged 运行。部署时需根据实际引擎选择正确的特权模型。
排障以进程侧证据为准
部署配置（如 Helm values）与实际生效的引擎可能不一致，排障时应以进程侧 Driver 行为准。若 Pod 就绪但引擎非预期，先检查 driver.kind 和节点 Driver 行，而非修改规则。回退到 kmod 的节点应改用完整特权模型排查，避免继续按 CAP 列表分析。
Q&A
Falco 0.44.1 中 driver.kind 有哪些可选值？
driver.kind 可选值为 auto、modern_ebpf 和 kmod。auto 是默认值，会先尝试 modern_ebpf，若 BPF 特性不足则回退到 kmod。
Falco 的 least-privileged 能力集适用于哪种驱动？
least-privileged 仅适用于 modern_ebpf 驱动。kmod 需要完整特权，不能使用 least-privileged 能力集。
在 Kubernetes 中部署 Falco 时，如何强制使用 modern_ebpf 或 kmod？
在 Helm chart 中显式设置 driver.kind 为 modern_ebpf 或 kmod，而不是依赖 auto 回退。这样不兼容的节点会启动失败，但避免了静默分叉。
Falco 的 auto 回退机制有什么优缺点？
auto 回退的优点是异构节点无需手动配置，缺点是可能静默切换引擎，导致排障时使用错误的权限模型。因此需要按节点核对实际引擎。
Falco 部署后，如何确认节点实际使用的引擎？
通过查看进程侧的 Driver 行或节点上的 engine.kind 配置，而不是依赖全局 values。以进程侧证据为准。
Falco 的 modern_ebpf 驱动需要哪些 Linux capabilities？
modern_ebpf 需要 CAP_SYS_BPF、CAP_SYS_PERFMON、CAP_SYS_RESOURCE、CAP_SYS_PTRACE。在支持细粒度能力的系统上，这些可替代 CAP_SYS_ADMIN。
如果集群中部分节点不支持 modern_ebpf，会发生什么？
在 auto 模式下，这些节点会回退到 kmod，导致不同节点使用不同引擎。这是预期行为，但排障时需按节点核对实际引擎，并采用相应的特权模型。
